manpro opened a new issue, #45473:
URL: https://github.com/apache/superset/issues/45473
### Summary
While developing and testing a static-analysis (SAST) tool against current
`master` (commit `4f49d241`, 2026-10-19), a recurring pattern came up that
seems worth a maintainer's triage: several API endpoints catch a **broad
`except Exception`** (or a raw `SQLAlchemyError`) and return the **stringified
exception directly to the client**, e.g.
```python
except Exception as ex: # pylint: disable=broad-except
...
return json_error_response(error_msg_from_exception(ex), 400)
```
and `error_msg_from_exception()` itself ends in `return str(msg) or str(ex)`
(`superset/utils/core.py:578`), so when the exception carries no `message`
attribute the raw exception text goes to the response.
This is the CWE-209 pattern (information exposure through error message).
All of the endpoints below require authentication (`@protect()` /
`@has_access_api`), so the exposure is to *authenticated* users — but in
multi-tenant setups a low-privileged user being able to read raw DB/driver
error text (SQL fragments, host/port details in some drivers) seems worth
avoiding. I found issue #29336 (ClickHouse server IP/port shown in UI) was
previously treated as a security problem, which is why I'm flagging this class
rather than assuming it is intended UX.
To be fully transparent: these are **static-analysis findings verified in
source, not dynamically exploited**. I'm happy to build a concrete repro for
any of them, or to move this to a private security channel if you consider it
security-sensitive — please advise which you prefer.
### Locations (master @ `4f49d241`)
Broad `except Exception` → `str(ex)` / `error_msg_from_exception(ex)` in the
response:
- `superset/datasets/api.py:1246` — `except Exception as ex: return
self.response_500(message=str(ex))`
- `superset/themes/api.py:664, 731, 781, 831` — `except Exception as ex:
return self.response_422(message=str(ex))`
- `superset/views/sql_lab/views.py:108, 130, 167, 204, 235, 279, 316, 339,
364` — `except Exception as ex: return
json_error_response(error_msg_from_exception(ex), 400)`
Raw driver error through the helper:
- `superset/databases/api.py:981` — `except SQLAlchemyError as ex: return
self.response_422(error_msg_from_exception(ex))`
Borderline (still stringified, but the exception text is usually
developer-controlled):
- `superset/datasource/api.py:1098` — `except ValueError as ex: return
self.response(400, message=str(ex))`
- `superset/cachekeys/api.py:83` and
`superset/views/datasource/views.py:345` — `str()` of a marshmallow
`ValidationError`
For contrast, the majority of the codebase already does the right thing —
repo-defined exception classes with static, curated messages
(`SupersetException` et al.) returned via `ex.message`, and
`ValidationError.messages`. The sites above look like the leftovers of that
pattern rather than a deliberate choice.
### Suggested direction (if agreed this is worth fixing)
Return a generic message with a correlation id server-side (most of these
already `logger.exception(...)` the detail), or map the broad catch onto the
existing curated exception types. Happy to contribute a PR for any subset if
that's welcome.
### Environment
- Tested commit: `4f49d24151d1583b225de5df0983e29d8375ca80` (master,
2026-10-19)
- Method: static analysis; findings read and verified in source, not
reproduced at runtime
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
