CVE-2023-27524: Apache Superset default SECRET_KEY authentication bypass, actively exploited
The short version: Apache Superset signs its session cookies with a SECRET_KEY, and installs that never changed it from the shipped default let an attacker forge a valid cookie and authenticate as any user — including an administrator. From there, Superset's database features often lead to full compromise. It's in CISA's KEV catalog. Set a strong SECRET_KEY and upgrade. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — trivial account takeover on default installs; climbs toward Critical when it leads to RCE |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| CVSS (GitHub Security Advisory) | 8.9 — High · AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L |
| EPSS | ~97.41% · 99.89th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2024-01-29 |
| Known exploited? | Yes — CISA-listed; thousands of internet-facing instances found on default keys |
| Vulnerability type | CWE-1188 insecure default initialization (default SECRET_KEY) → session forgery → authentication bypass |
| Requires authenticated session? | No — the attacker forges their own session |
| Affected | Apache Superset up to and including 2.0.1 (installs using a default SECRET_KEY) |
| Fixed in | Apache Superset 2.1.0 (refuses to start with a default SECRET_KEY) |
What you need to know
Apache Superset is a web-based data-exploration and dashboarding platform. It uses a Flask SECRET_KEY to cryptographically sign the session cookies that keep users logged in. CVE-2023-27524 is the consequence of leaving that key at its shipped default: if an attacker knows the default key — and it's public — they can forge and sign their own session cookie, then present it to authenticate as any user, up to and including an admin.
Why it matters:
- It's an authentication bypass, not a guess. No brute force and no credentials — the attacker mints a valid session.
- It was staggeringly common. Research found thousands of internet-facing Superset instances running on default keys, which is why CISA added it to KEV.
- Admin access is a springboard. Superset's database-connection and charting features mean an admin session frequently becomes a path to code or data-source compromise.
How serious we see it
High — with genuine upside risk toward Critical.
NVD scores it 9.8 and the vendor's GitHub advisory 8.9; the gap reflects how much weight you put on the default-key precondition. We land on High because the flaw only bites installs still using a default SECRET_KEY — but on those installs it's a trivial, unauthenticated takeover, and where the resulting admin access leads to code execution it behaves like a Critical. The reassuring part is that the fix is entirely in your hands: set a strong, unique key and Superset 2.1.0+ won't even start on a default.
Recommendations
Straight from the Apache Superset advisory and CISA:
- Set a strong, unique SECRET_KEY now. Configure a random
SECRET_KEYinsuperset_config.py(or via theSUPERSET_SECRET_KEYenvironment variable) — do not use any shipped default, including container/helm defaults likeTEST_NON_DEV_SECRET. - Rotate it properly. Rotating the key invalidates existing sessions — plan for it, and rotate anyway if you suspect prior exposure.
- Upgrade. Move to Apache Superset 2.1.0 or later, which refuses to start with a default key.
- Change default admin credentials. Ensure
admin/adminand similar defaults are gone. - Confirm your exposure first. Verify whether any internet-facing Superset instance is on a default SECRET_KEY.
How BreachRisk sees it
BreachRisk discovers internet-facing Superset instances from little more than your domain, fingerprints the version, and flags exposure tied to KEV-listed vulnerabilities like this one — surfaced at the top of your results because it's in KEV.
That outside-in view is exactly what a default-configuration flaw needs: the exposed Superset login is mapped and ranked, so you can set a real key and upgrade before someone forges their way in.