Apache Superset's Default Session Key: Forging an Admin Cookie on 101,819 Reachable Deployments

Superset sits on top of the warehouse, which means it holds connection strings, service credentials and often enough sampled data to reconstruct a business. CVE-2023-27524 remains the cleanest illustration of how little is needed to reach it: a session cookie can be forged without any credential at all when the application still signs that cookie with a key shipped in its own source tree.

The mechanism

Flask signs its session cookie with a SECRET_KEY. Superset, like many applications derived from a common template, shipped with a hardcoded default and told operators to change it. Plenty did not. CVE-2023-27524 covers releases up to and including 2.0.1 where an unauthenticated attacker who possesses the published default value can construct a valid session cookie for any user identifier, including the first administrative account.
The step-by-step is unglamorous. Visit the login page, receive a cookie signed with the default key, replace the payload with a user id of one, re-sign with the same default key, present it. No brute force, no exploit chain, no timing dependency. The cryptographic integrity check passes precisely because the secret is public.
Two follow-on issues make the outcome worse than an unauthorised dashboard. CVE-2023-37941 covers pickle deserialisation in the metadata database, exploitable in releases from 1.5 through 2.1.0 and fixed in 2.1.1, which turns an authenticated position into code execution when combined with write access to certain internal tables. Separately, CVE-2024-28148 describes an authorisation error where a dashboard-level check could be satisfied by a resource the caller legitimately owned, letting a low-privilege account reach dashboards it should never have seen. Chained, they describe an audit problem rather than a single bug: identity established on a shared secret, authorisation decided by object ownership, and a deserialisation sink one hop away.

Why the exposure persists

A measurement taken for this article on 2026-10-23 returned 101,819 results for the application fingerprint of Apache Superset through ZoomEye. That is not a count of vulnerable hosts, and it must not be read as one. It is a count of internet-facing deployments the fingerprint engine recognises, and it spans every version plus containers, lab instances and reverse-proxied front ends whose headers are copied from the upstream project.
What the number does establish is the population size of a class of system. When a hundred thousand dashboards are reachable, a default key problem stops being a hypothetical. The gap between "the vendor told us to rotate it" and "the estate actually rotated it" is where this vulnerability lives, and that gap is measured in years.
There is a second reason the defect lasted. Rotating SECRET_KEY invalidates every existing session, so on a live deployment the change logs everyone out at once. The change is trivial and the operational cost is visible immediately, which is exactly the profile of a fix that keeps getting deferred.

What establishes whether you are affected

Version alone is not decisive, because an upgraded deployment can retain its old key through configuration. Check the configured value directly.

• Read the SECRET_KEY the application actually runs with, from config.py, superset_config.py or the environment variable that overrides it.
• Compare it against the published default values rather than against your memory of them. Documentation quoting the key verbatim is the check, not an inspection of source control.
• Confirm which account has the lowest identifier. If the deployment was seeded from a template, that account is frequently the administrative one.
• Review authentication logs for sessions that begin without a corresponding login event. A forged cookie appears as an already-authenticated request, so the absence of a login record is the signal.

Remediation order

1. Rotate SECRET_KEY to a high-entropy value stored outside the repository, and expect and communicate the session invalidation.
2. Rotate every database credential referenced by a connection. If a forged session could read a connection string, assume it was read; dashboards render connection metadata to anyone who can open them.
3. Audit the metadata database for unexpected users, roles and saved queries created outside your change process.
4. Move to a release that also carries the authorisation and deserialisation fixes, and treat the version bump as the smaller half of the work.
5. Put the instance behind an authenticating proxy so that a signed cookie is not the only control standing between the internet and the warehouse.

References

• NVD record for CVE-2023-27524, Apache Superset default SECRET_KEY.
• NVD record for CVE-2023-37941, pickle deserialisation in Superset metadata, fixed in 2.1.1.
• NVD record for CVE-2024-28148, incorrect authorisation in Apache Superset.
• Apache Superset security documentation, session signing configuration.
• ZoomEye, measurement performed 2026-10-23 with the Apache Superset application fingerprint; figure reflects reachable fingerprinted deployments, not confirmed vulnerable hosts.