CVE-2023-27524

What it actually does

Apache Superset deployments up to and including 2.0.1 that still use the default SECRET_KEY are vulnerable to session forgery and session validation bypass. The SECRET_KEY is used to cryptographically sign Flask/Superset session cookies and protect sensitive encrypted values; if it is left at the publicly known default, an unauthenticated attacker can craft valid session cookies and impersonate users, potentially including privileged users, to access dashboards, datasets, database connection metadata, and administrative functionality. The flaw is configuration-dependent: installations that replaced the default SECRET_KEY with a strong, unique random value are not affected by this specific issue.

Why it matters to the business

Successful exploitation can give an external attacker unauthorized access to business intelligence data, analytics dashboards, connected data sources, and Superset administrative capabilities. This can lead to data exposure, manipulation of reports or access controls, disruption of analytics operations, and potential pivoting through stored database connections or credentials. The risk is high because exploitation is known in the wild, the EPSS likelihood is very high, and the vulnerability is listed in CISA KEV with a remediation deadline of 2024-01-29, indicating broad operational urgency for any internet-exposed or widely accessible Superset deployment.

How an attack unfolds

An attacker first identifies an Apache Superset instance and determines that it is running an affected version or is likely to have been installed with insecure defaults. Because the default SECRET_KEY is publicly known, the attacker can use it to generate a cryptographically valid session cookie rather than needing to steal a legitimate one. The forged cookie is then sent to the Superset application, which accepts it as authentic if the deployment still uses the default key. Depending on the user identity or session claims embedded in the forged cookie and the Superset authorization configuration, the attacker may gain access to dashboards, charts, datasets, SQL Lab, saved queries, database connection information, or administrative pages. After access is obtained, the attacker may enumerate data assets, export sensitive analytics, alter dashboards or permissions, create persistence through accounts or roles, or use accessible database connections to query underlying data sources. Public exploitation has been observed in the wild under the KEV-tracked Apache Superset insecure default initialization vulnerability, so defenders should assume exposed unremediated systems may have been probed or abused.

How to fix it

Immediately replace any default or weak Apache Superset SECRET_KEY with a unique, high-entropy random value. Set it in superset_config.py using SECRET_KEY = '<strong_random_value>' or through the SUPERSET_SECRET_KEY environment variable, ensuring the value is not committed to source control or reused across environments. After changing the key, restart all Superset application components and workers so the new value is consistently applied. Because changing the key invalidates existing sessions and may affect encrypted secrets, follow Apache Superset guidance for key rotation and secret re-encryption where applicable, including use of PREVIOUS_SECRET_KEY and superset re-encrypt-secrets if needed for stored encrypted values. Upgrade Superset to a currently supported release even though the core exposure is the insecure default configuration; versions up to and including 2.0.1 are identified as affected when defaults are unchanged. Restrict Superset network exposure, enforce SSO/MFA where possible, remove unnecessary public access, rotate database credentials that Superset can access if compromise is suspected, and review roles, users, saved queries, and database connections for unauthorized changes.

How to confirm the fix worked

Confirm that Superset is not using a default, example, placeholder, or shared SECRET_KEY by inspecting the effective runtime configuration, deployment manifests, container environment variables, and superset_config.py. Verify that SUPERSET_SECRET_KEY or SECRET_KEY is set to a unique high-entropy value for each environment and that all web, worker, scheduler, and async components use the same intended value. After rotation, confirm that old session cookies are no longer accepted and that users are required to reauthenticate. Check the deployed Superset version and upgrade status, with special attention to any instance at or below 2.0.1. Review whether encrypted database connection secrets remain accessible after key rotation and complete the documented re-encryption process if required. From an exposure perspective, validate that Superset is not unnecessarily reachable from the internet and that authentication, role mappings, and database permissions enforce least privilege.

Typical attack path

1. Discover an Apache Superset web interface through internet scanning, search engines, or internal reconnaissance.
2. Fingerprint the application version or infer exposure based on headers, login pages, assets, or known Superset endpoints.
3. Assume or test whether the deployment still uses the default SECRET_KEY from vulnerable Superset configurations.
4. Create a forged Flask/Superset session cookie signed with the default SECRET_KEY.
5. Submit requests to Superset with the forged session cookie to authenticate without valid credentials.
6. Access dashboards, datasets, SQL Lab, saved queries, database connection metadata, or administrative interfaces depending on assigned roles and authorization behavior.
7. Export or query sensitive data, modify analytics content or permissions, create additional access paths, or pivot toward connected data stores.

How to detect it

Investigate Superset application logs, web access logs, reverse proxy logs, container logs, authentication provider logs, and database audit logs for evidence of unauthorized session use. Focus on access that occurred before SECRET_KEY rotation or upgrade, especially requests with valid authenticated behavior but no corresponding identity-provider login event. Look for unusual source IPs, new geographies, unexpected user agents, access outside normal business hours, high-volume dashboard or dataset exports, SQL Lab queries by accounts that do not normally use SQL Lab, and administrative actions such as user, role, database connection, dataset, or dashboard changes. Compare Superset session activity against SSO or IdP authentication logs; forged sessions may appear in Superset without matching IdP sign-in events. Review Flask/Superset logs for session decoding, signature, or deserialization anomalies around the time of probing, although successful forged sessions may not generate obvious errors. Examine metadata database audit trails and Superset event logs for unexpected creation or modification of users, roles, permissions, database connections, saved queries, dashboards, charts, API keys or tokens if present, and exports. Review database server logs for queries initiated by Superset service accounts that are unusual in volume, timing, target schema, or source user context. Because the exploit relies on a known default key rather than dropping malware, durable file or process IOCs are generally not expected; detection is primarily behavioral and log-correlation based.

• SECRET_KEY = 'thisISaSECRET_1234'
• SECRET_KEY='thisISaSECRET_1234'
• SUPERSET_SECRET_KEY=thisISaSECRET_1234
• thisISaSECRET_1234
• GET /superset/welcome/
• GET /superset/dashboard/
• GET /superset/profile/
• GET /superset/sqllab/
• GET /superset/sqllab/history/
• POST /superset/sqllab/execute/
• POST /api/v1/sqllab/execute/
• GET /api/v1/dashboard/
• GET /api/v1/dataset/
• GET /api/v1/database/
• POST /api/v1/security/users/
• POST /api/v1/security/roles/
• POST /api/v1/database/
• superset_config.py

What your security team should do

• Treat this as urgent for any Apache Superset instance exposed to the internet or broadly reachable internally because it is KEV-listed, actively exploited in the wild, and has a very high EPSS score.
• Inventory all Apache Superset deployments, including containers, ephemeral analytics environments, development instances, and managed deployments, and identify any running version up to and including 2.0.1.
• Immediately verify and rotate SECRET_KEY values that are default, sample, weak, reused, or unknown; use a strong randomly generated key stored in a secrets manager.
• Restart all Superset services after key rotation and invalidate existing sessions; follow Superset’s key rotation and secret re-encryption procedure for stored encrypted secrets.
• Upgrade Superset to a supported current version and remove unsupported 2.0.1-and-earlier deployments from production use.
• Review Superset users, roles, permissions, dashboards, datasets, saved queries, SQL Lab activity, and database connection configuration for unauthorized access or changes.
• Rotate credentials for databases and services reachable through Superset if logs indicate suspicious access or if prior SECRET_KEY exposure cannot be ruled out.
• Restrict Superset access with network controls, VPN or private access, SSO, MFA, and least-privilege database accounts.
• Add monitoring for anomalous Superset logins, unexpected session behavior, unusual user agents, large exports, SQL Lab query spikes, and administrative changes.
• Prioritize remediation ahead of or consistent with the CISA KEV due date of 2024-01-29 for regulated or federal-aligned programs.