In general, to fix this kind of problem you should avoid sending raw exception messages or stack traces back to clients. Instead, log the detailed exception information on the server for debugging and observability, and return a generic, user-safe error message in the HTTP response. This preserves developer visibility while preventing attackers from learning about internal implementation details.

In this specific function, the problematic behavior is in the except ValueError as e: block: it logs str(e) (which is fine) and then returns a JSON body whose "error" field is also str(e). To fix this without changing the overall behavior or status codes, we should keep the detailed message in the logs but replace the client-facing error message with a generic description of the problem, such as "Invalid request for flow reset". We should apply the same principle that is already used in the generic Exception handler below, which returns "Internal server error: ..." but should avoid appending str(e) as well (since that also leaks details). However, CodeQL’s alert is specifically for the ValueError block, so we will focus on ensuring that block no longer exposes str(e) and, for consistency and security hardening, also make the generic exception message not include str(e).

Concretely:

• In src/api/flows.py, in reset_flow_endpoint, update the except ValueError as e: clause so that:
  • Logging remains as-is or is slightly improved (it already logs the error string).
  • The JSON response uses a fixed, generic error message instead of str(e).
• In the except Exception as e: clause:
  • Keep logging str(e) on the server.
  • Return a fully generic message like "Internal server error" without interpolating str(e) into the response.
    No new imports or helper methods are required; we only adjust the strings passed to JSONResponse.

In general, to fix information exposure via exceptions, you should avoid returning raw exception messages or stack traces to clients. Instead, log the detailed exception information server-side (including message and stack trace if desired) and return a generic error message to the user. This preserves debuggability for developers while preventing attackers from learning about internals.

For this specific function in src/api/flows.py, the best fix is to stop including str(e) in the JSON response for the generic except Exception as e: block. We should keep logging the error message (and potentially stack trace) using the existing logger, but the response body should contain a generic message like "Internal server error" without any details from e. We can also slightly improve logging by including exc_info=True so the stack trace is captured in logs, but that’s optional and not required for the fix.

Concretely:

• In the except Exception as e: block (lines 52–57), keep or improve the logging call but change the JSONResponse payload so that the "error" field is a static string and does not interpolate str(e).
• Do not change the ValueError handler on lines 49–51, because those messages are generally considered validation/user errors and are already treated as client-facing; the CodeQL alert is specifically about the generic exception handler.
• No new imports or external libraries are needed; we can rely on the existing logger and JSONResponse.

In general, to fix information exposure via exceptions, avoid returning raw exception messages or stack traces to clients. Instead, log the detailed error on the server and return a generic, user-friendly message (optionally with a stable error code) that does not contain internal details.

For this specific case, the best fix without changing functionality is to stop including str(e) in the JSON response at line 91. We should keep logging the detailed exception for debugging (logger.error(...)), but the client-facing message should be generic, such as "Invalid queryData format". This preserves behavior (400 status code and indication of what went wrong at a high level) while removing exposure of the underlying exception message.

Concretely:

• In create_knowledge_filter in src/api/knowledge_filter.py, change the JSONResponse in the except block so that it no longer interpolates e or str(e) into the response.
• No new imports or helper methods are required; we already log the detailed exception.

In general, to fix this issue you should avoid returning raw exception messages to the client. Instead, return a generic, user-safe error message, and log the detailed exception on the server side for debugging. This prevents potential leakage of internal details while preserving observability for developers.

For this specific code, the best fix with minimal functional change is to keep logging the detailed error (logger.error(...)) but change the HTTP response so that it does not interpolate str(e). Replace the current JSONResponse({"error": f"Invalid queryData format: {str(e)}"}, status_code=400) with a response that uses a generic message, such as {"error": "Invalid queryData format"}. No new imports are needed; we keep using the existing logger. The change is confined to src/api/knowledge_filter.py around lines 193–197.

In general, the fix is to avoid sending raw exception data back to the client and instead return a generic, non-sensitive error message while logging detailed information on the server. Stack traces and exception messages should be captured only in server-side logs.

Concretely in src/api/knowledge_filter.py, within knowledge_filter_webhook, we should:

• Keep logging the error (ideally including the traceback) using logger.error.
• Remove the traceback.print_exc() call, which prints to stderr and can leak details in some deployments.
• Change the JSON response to use a generic error message that does not include str(e) or any internal data.

We can achieve this by:

• Importing traceback at the top of the file (instead of inside the handler) and using traceback.format_exc() to capture the stack trace as a string, which we then pass to logger.error as structured data.
• Updating the except block to return something like {"error": "Webhook processing failed"} without interpolating the exception message.

No new functions are required; only modifications within the shown function and an additional import are needed.

In general, to fix this kind of problem you stop sending raw exception messages or stack traces directly to the client. Instead, you log the detailed error (including stack trace) on the server and return a generic, non-sensitive message to the user, optionally with a stable error code they can reference.

For this specific code, the best fix with minimal behavior change is:

• Keep logging str(e) and the traceback as is.
• For the generic 500 case, stop returning {"error": error_msg} and instead return a generic message such as {"error": "An internal error has occurred."}.
• For the special authentication/authorization case, avoid exposing the full raw message. Instead, return a constrained, generic error message (for example, "Authentication failed" or "Access denied") and optionally log the detailed error_msg as is already being done.

Concretely, in src/api/router.py:

• Replace the 403 branch so that it returns a fixed message, not error_msg.
• Replace the 500 branch so that it returns a fixed, generic message.

No new imports or helper functions are required; we only adjust the JSONResponse payloads in the except Exception as e: block at the end of _langflow_upload_ingest_task.

In general, to fix information exposure via exceptions, log the detailed error (and stack trace if desired) on the server, but return only a generic, non-sensitive message to the client. Do not include str(e) or other raw exception data in the API response.

Concretely for this file, we should update all the error-handling branches that currently return responses like {"error": f"...: {str(e)}"} to instead return a constant, generic error message. We will keep the existing logging as-is so that developers still have access to str(e) (and potentially stack traces if configured via logger). This preserves behavior in terms of status codes and high-level semantics while removing sensitive details from the user-visible surface.

Specifically:

• In chat_list_endpoint (around lines 150–152), keep the logger.error call but change the JSON response to something like {"error": "Failed to list conversations"} without interpolating str(e).
• In chat_get_endpoint (around lines 194–196), similarly return a generic "Failed to get conversation" message without str(e).
• In chat_delete_endpoint (around lines 214–216), change the exception handler’s response to a generic "Failed to delete conversation" message.

No new imports or helper methods are required; we only alter the response bodies to remove the embedded exception text.

In general, to fix information exposure through exceptions, you should avoid including raw exception messages or stack traces in responses sent to clients. Instead, log the detailed error on the server (so developers can debug) and return a generic, non-sensitive error message to the client, possibly with a stable error code if needed.

For this specific code, we should keep logging the exception with context (user_id, chat_id) but change the JSONResponse returned in the except block of chat_get_endpoint to no longer embed str(e). It should return a generic error message such as "Failed to get conversation" and a 500 status code. The logging call can remain as-is, because it is server-side and not exposed to users. We will make a minimal change: only update the response body in the except block of chat_get_endpoint (lines 194–196) in src/api/v1/chat.py. No new imports or helper methods are needed.

In general, to fix this kind of problem, avoid sending raw exception details (messages, stack traces) back to the client. Instead, log the full error details on the server (including the exception and optionally the stack trace) and return a generic, user-safe error message and status code in the HTTP response.

For this specific code, the minimal, non-breaking change is to modify the except block in chat_delete_endpoint so that:

• The logger.error call continues to record the detailed error on the server (you may keep str(e) there).
• The JSON response body no longer includes str(e) and instead uses a fixed, generic error message such as "Failed to delete conversation".
• The HTTP status code remains 500 to preserve behavior, while the response body is sanitized.

No new imports or helper methods are strictly required. We only need to change the return statement within the except block in chat_delete_endpoint in src/api/v1/chat.py to remove the interpolation of str(e).

To fix the issue, the user-facing error response should not include str(e) (or any detailed exception message). Instead, return a generic, non-sensitive error message, while ensuring the full details are logged on the server for debugging.

The best way to fix this without changing existing functionality is:

• Keep the logger.error call so that the detailed exception (including its message) is recorded in server logs.
• Change the JSONResponse body so it no longer interpolates str(e) and instead uses a generic string like "Internal server error while retrieving models.".
• Optionally, you could include a generic error code or a correlation ID, but that would require additional context not present in the snippet, so we will not introduce that.

Concretely, in src/api/v1/models.py, within list_models_endpoint, update the except Exception as e: block:

• Leave line 80 (logging) unchanged.
• Change line 81 to remove str(e) from the error message, returning a fixed, generic error message.

No new imports or helper methods are required.