erroneo.us
Search all guides⌘K

Security Digest · Apr 5, 2023 · Misconfiguration · Other

Apache Superset CVE-2023-27524: Default SECRET_KEY Takeover

Superset 2.0.1 and earlier with a default SECRET_KEY let anyone forge an admin session. 2.1 blocks it; check your key, rotate secrets, hunt admin activity.

Published By erroneo.us Security Desk · Updated 3 min read13 sources

Our verdict

Check exposure

Not a code bug but a shipped default; the version number alone does not prove you are safe, so confirm every Superset instance uses its own random SECRET_KEY, and if one ran on a default key while reachable, treat it and its database credentials as compromised.

Who must act: Anyone running Apache Superset whose SECRET_KEY is, or ever was, a published default, especially Docker Compose or Helm installs and any instance reachable from the internet.

Who can relax: Teams that set a unique random SECRET_KEY from the start and run a current release; Superset 2.1.0 and later refuse to start with the main default key.

Affected
Apache Superset up to and including 2.0.1 left on the default SECRET_KEY (CVE record)
Any version still using a known default key from Docker Compose, Helm or documentation examples (Horizon3, September 2023)
Fixed in
Superset 2.1.0 (Apr 5, 2023) refuses to start with the default SECRET_KEY
The real fix is a unique random key, rotated with superset re-encrypt-secrets
Current stable release: 6.1.0 (May 13, 2026)
CVSS
8.9 (v3.1, CNA)
EPSS
97.4% (percentile 99.9)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
High

What to do

  1. List every Superset instance and record its version and where its SECRET_KEY comes from (superset_config.py or SUPERSET_SECRET_KEY).
  2. Compare the key against the published defaults and replace any default or guessable key with one from openssl rand -base64 42.
  3. Rotate the key the supported way: set PREVIOUS_SECRET_KEY, then run superset re-encrypt-secrets so stored database passwords stay readable.
  4. Upgrade to a current release; 2.1.1 and later also fix the post-login RCE paths Horizon3 described.
  5. If an instance ran on a default key while reachable, rotate every database credential configured in it and review its admin users.
  6. Take Superset off the public internet or put it behind SSO or a VPN.

How to check if you are affected or compromised

  • Run Horizon3's check script against each instance you own to see whether its session cookies are signed with a known default key.
  • Review the Superset action log for database connections added or edited, data exports and unusual SQL Lab queries.
  • Search web server logs for /api/v1/database requests and admin activity from unfamiliar IP addresses.
  • Look for admin activity with no matching login, since a forged cookie skips the login form.

What happened#

Apache Superset, the open-source BI and dashboard tool built on Flask, signs its session cookies with a SECRET_KEY. Superset shipped with a fixed default key, and many deployments never changed it. Anyone who knows the key can forge a cookie that says "I am user 1," which is usually the first administrator. Horizon3.ai reported this to Apache on October 11, 2021, and followed up with new data on February 9, 2023. Superset 2.1.0, released April 5, 2023, refuses to start with the default key. Apache announced CVE-2023-27524 on April 24 for versions up to and including 2.0.1. The CVE record scores it CVSS 3.1 8.9, and NVD scores it 9.8.

Horizon3's write-up found that 2,124 of 3,176 internet-facing instances, about 67%, used one of four default keys. With admin access, an attacker can add database connections, run arbitrary SQL in SQL Lab and harvest stored credentials. Horizon3 found paths to remote code execution, which its September 2023 follow-up described. That post also said the fix was incomplete: Docker Compose and Helm installs could still run with default keys, and about 54% of instances (2,076 of 3,842) still did.

CISA added the CVE to the KEV catalog on January 8, 2024, "based on evidence of active exploitation." CISA published no details. SecurityWeek and The Hacker News both said the attacks were not described. As of Oct 23, 2026, the attackers and campaigns behind the listing have not been disclosed.

Who is affected#

Any Superset instance whose session cookies are signed with a published key. The CVE covers 2.0.1 and earlier. Newer versions are safe only if the key is your own. If a vulnerable instance was ever reachable, the database passwords it stores should be treated as exposed. The key also encrypts those credentials, and Horizon3 calls them reversible.

Do you really need to act?#

Most teams can confirm and move on, so the verdict is check exposure. This is a configuration problem, so a version number does not settle it. A Helm or Compose deployment copied from an old template can carry a default key on any release. Fixing it takes minutes, and a forged admin session reaches every database Superset connects to.

What to do now#

  1. For each instance, find where the key is set: grep -n SECRET_KEY superset_config.py, or check the SUPERSET_SECRET_KEY environment variable in your Compose or Helm values.
  2. Replace any default or guessable key with one from openssl rand -base64 42, as the Superset docs recommend.
  3. Rotate it the supported way: set the old value as PREVIOUS_SECRET_KEY, the new one as SECRET_KEY, then run superset re-encrypt-secrets.
  4. Upgrade to a current release. The latest stable is 6.1.0. Release 2.1.1 and later also fix the post-login RCE paths.
  5. If an instance ran on a default key while reachable, rotate every database credential configured in it and review its admin accounts.

How to tell if you were hit#

  • Run Horizon3's check script against your own instances: python3 CVE-2023-27524.py -u https://superset.example.com.
  • Review Superset's action log for database connections added or changed, data exports and unusual SQL Lab queries, as Horizon3 advises.
  • Search web logs for /api/v1/database calls and admin activity from unfamiliar IP addresses. A forged cookie skips the login form, so admin actions with no matching login are a red flag.

Timeline#

  • — Horizon3 reports the default key to Apache.
  • — Superset 2.1.0 refuses to start with the default key.
  • — Apache announces CVE-2023-27524.
  • — Horizon3 publishes its write-up and check script.
  • — Superset 2.1.1 fixes the follow-on RCE bugs.
  • — Horizon3 reports about 54% of instances still on default keys.
  • — CISA adds the CVE to KEV.
  • — Federal remediation deadline.

Vulnerability records

  • CVE-2023-27524 · KEV 2024-01-08 · Session Validation attacks in Apache Superset versions up to and including 2.0.1.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. Apache Superset — CVE-2023-27524: Session validation vulnerability when using provided default SECRET_KEY lists.apache.org
  2. Apache Superset — Configuring Superset: SECRET_KEY and key rotation superset.apache.org
  3. Apache Superset — Release 2.1.0 github.com
  4. Apache Superset — Release 6.1.0 github.com
  5. CVE record — CVE-2023-27524 cve.org
  6. NVD — CVE-2023-27524 nvd.nist.gov
  7. CISA — Known Exploited Vulnerabilities: CVE-2023-27524 cisa.gov
  8. CISA — CISA Adds Six Known Exploited Vulnerabilities to Catalog (Jan 8, 2024) cisa.gov
  9. Horizon3.ai — CVE-2023-27524: Insecure Default Configuration in Apache Superset Leads to Remote Code Execution horizon3.ai
  10. Horizon3.ai — Apache Superset Part II: RCE, Credential Harvesting and More horizon3.ai
  11. Horizon3.ai — CVE-2023-27524 check script github.com

Coverage and analysis

  1. SecurityWeek — CISA Warns of Apache Superset Vulnerability Exploitation securityweek.com
  2. The Hacker News — CISA Flags 6 Vulnerabilities thehackernews.com