Apache Superset SECRET_KEY Vulnerability

[Critical] Unauthenticated Administrative Access via Weak Apache Superset SECRET_KEY
Apache Superset can expose an entire Business Intelligence (BI) platform when its Flask session signing key is weak or predictable. A security assessment of an Apache Superset 2.2.0 instance demonstrated that a weak SECRET_KEY could allow an unauthenticated attacker to forge an administrator session and access privileged application functionality without knowing the administrator's username or password.
The issue is particularly serious because a forged administrator session can provide access to dashboards, charts, datasets, configured data sources, and SQL Lab functionality, depending on the permissions of the connected systems.
In this security assessment, the vulnerability was validated by confirming administrator-level authentication through the Superset API and performing a harmless SQL query.
Let's examine the vulnerability, its technical details, the proof of concept, the demonstrated impact, and the recommended remediation steps.

---

🔍 Vulnerability Overview​

Property	Details
Vulnerability	Weak SECRET_KEY – Session Forgery
Software	Apache Superset
Tested Version	2.2.0
Severity	Critical
CVSS 3.1	9.1
Attack Vector	Network
Attack Complexity	Low
Privileges Required	None
User Interaction	None
Scope	Unchanged
Confidentiality Impact	High
Integrity Impact	High
Availability Impact	None

Affected Asset: https://[REDACTED-HOST]
CVSS 3.1 Vector:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Critical - CVSS 9.1

---

🧩 Understanding the Weak SECRET_KEY Vulnerability​

Apache Superset is an open-source Business Intelligence platform used by organizations to analyze data, build interactive dashboards, create charts, and run SQL queries against connected databases.
It relies on Flask and Flask-Login for user session management.
One of the most important security settings in this architecture is SECRET_KEY.
This key is used to protect session cookies through cryptographic signing. When a user successfully logs in, the application creates a session and signs it using the configured secret key.
The browser then sends the session cookie with subsequent requests, allowing the application to recognize the authenticated user.
The problem occurs when the signing key is weak, predictable, or exposed.
For example, a configuration that uses a simple value such as 123456 does not provide adequate cryptographic protection.
If an attacker knows the signing key, they may be able to create a forged session cookie containing another user's identity, including an administrator account.
The application may then accept the forged cookie as a legitimate session.
The security consequence: Authentication can be bypassed without obtaining the administrator's actual password.

---

⚙️ Technical Details: How Session Forgery Works​

The vulnerability is related to the trust Apache Superset places in correctly signed session cookies.
Under normal conditions, the authentication process works as follows:

1. A user submits valid login credentials.
2. Apache Superset authenticates the user.
3. Flask creates the user's session.
4. The session is signed using the application's SECRET_KEY.
5. The browser receives the session cookie.
6. Subsequent requests include the cookie.
7. The application verifies the signature before accepting the session.

When the signing key is weak or known to an attacker, the integrity protection can be defeated.
An attacker who possesses the key may be able to construct a session containing an administrator's user identity and produce a valid cryptographic signature.
This is known as Session Forgery.
It is important to understand that HTTPS does not solve this problem. HTTPS protects communication between the browser and server, but it cannot protect a session-signing mechanism that uses a compromised secret.

---

🔥 Security Assessment and Proof of Concept​

The assessment demonstrated that the affected Apache Superset instance accepted a forged administrator-level session without requiring valid application credentials.
The original weak signing key was verified offline against a session cookie issued by the application's login endpoint.
The assessment then confirmed that a forged session could be recognized as belonging to the administrator account.

1. Session Validation​

An initial session cookie was obtained from:
GET /login/
The weak signing key was then verified against the issued cookie.
This established that the application's session-signing mechanism relied on predictable secret material.

2. Administrator Session Impersonation​

The assessment demonstrated that an administrator session could be associated with User ID 1.
The important finding was that the application accepted the forged session without requiring the administrator's actual password.
The resulting session provided administrator-level access to the application.

3. Proof of Concept: API Authentication Validation​

The following sanitized HTTP request was used to verify the authenticated identity:

GET /api/v1/me/ HTTP/1.1
Host: [REDACTED-HOST]
Cookie: session=<forged-session>

The API returned an administrator-level user profile.
Sanitized response:

{
"result": {
"email": "[REDACTED-ADMIN-EMAIL]",
"first_name": "[REDACTED]",
"id": 1,
"is_active": true,
"is_anonymous": false,
"last_name": "[REDACTED]",
"username": "[REDACTED-ADMIN-USER]"
}
}

The response confirmed the following:

• id: 1 identified the administrator account used during testing.
• is_active: true confirmed that the account was active.
• is_anonymous: false confirmed that the session was associated with an authenticated user.
• The returned profile identified the administrator account.

Result: The API accepted the forged session as an authenticated administrator session.
This was the central proof that the authentication weakness was exploitable.

4. Access to Dashboards, Charts, and Datasets​

Using the same session, the assessment verified read-only access to the following resources:

• 📊 [REDACTED] dashboards.
• 📈 [REDACTED] charts.
• 🗂️ [REDACTED] datasets.
• 🔌 [REDACTED] data-source connections across multiple business systems.

This demonstrated that the issue was not limited to accessing the user profile API.
The forged session provided access to additional BI resources associated with administrator privileges.
The assessment did not retrieve customer records, database table contents, or stored credentials.

5. SQL Lab Execution Validation​

The next step was to determine whether the administrator-level session could reach SQL Lab execution functionality.
A harmless constant query was used:

SELECT 1 AS security_validation_probe;

The relevant endpoint was:
POST /api/v1/sqllab/execute/
The application returned the following response:

{
"status": "success",
"data": [
{
"security_validation_probe": 1
}
]
}

<badge color="success">HTTP 200 OK</badge>
This confirmed that the forged administrator session could reach SQL Lab and successfully execute the test query.
No database table rows were accessed.
No credentials, user lists, or customer data were retrieved.
No write operations or application state changes were performed.
The only SQL statement executed was SELECT 1.

---

🧪 Reproduction and Validation​

The original assessment established the following reproduction sequence:

1. Obtain a session cookie issued by the application's login endpoint.
2. Verify the weak signing key against the issued session cookie.
3. Validate the session-signing weakness in an authorized test environment.
4. Confirm whether the application accepts an unauthorized administrator identity.
5. Verify the authenticated identity through the user profile API.
6. Obtain a CSRF token when testing an authorized state-changing or protected API operation.
7. Validate SQL Lab access using a harmless constant query.

The following API endpoints were involved in the assessment:
User profile validation:

GET /api/v1/me/

CSRF token endpoint:

GET /api/v1/security/csrf_token/

SQL Lab execution endpoint:

POST /api/v1/sqllab/execute/

The original report also documented a sanitized cURL request for validating the authenticated session:

curl -sk 'https://[REDACTED-HOST]/api/v1/me/'
-H "Cookie: session=<forged-session>"

The expected validation result was an administrator profile returned without normal authentication.
The complete reproduction described in the original assessment included a Python session-forging proof of concept and browser verification steps. The session-forging implementation itself is not reproduced here because it could directly enable unauthorized administrator impersonation.

---

💥 Security Impact​

The impact of this vulnerability extends beyond bypassing the login page.
An unauthenticated attacker who knows the weak signing key may obtain a fully privileged administrator session.
Depending on the connected database permissions and Superset configuration, the consequences may include:

1. Unauthorized Access to Business Intelligence Resources​

An attacker may gain access to dashboards, charts, and datasets that contain sensitive organizational information.

2. Exposure of Connected Data Sources​

Superset installations frequently connect to multiple business databases and analytical systems.
Administrator-level access may expose information about these configured connections and the resources available through them.

3. SQL Execution Through SQL Lab​

An attacker may be able to execute SQL queries through SQL Lab.
The actual impact depends on the permissions of the database account used by each configured connection.
A compromised Superset administrator session does not automatically grant unrestricted operating-system or database-server access.

4. User and Role Administration​

Administrator privileges may allow unauthorized access to user management and role configuration functionality.
This could enable further privilege changes within the application.

5. Modification or Deletion of BI Resources​

Depending on the available permissions, an attacker may be able to:

• Modify dashboards.
• Delete dashboards.
• Change datasets.
• Modify alerts.
• Delete saved queries.
• Alter application configurations and permissions.

6. Exposure of Sensitive Business Information​

The most serious potential consequence is unauthorized access to business information stored in connected data systems.
This could include financial reports, operational metrics, internal analytics, and other sensitive organizational data.

7. Existing Session Risk​

Existing session cookies should be considered potentially compromised until the signing key has been replaced and the old sessions have been invalidated.
Simply changing the configuration file without properly restarting and validating all application instances is not sufficient.

---

🛡️ Remediation: How to Fix the Weak SECRET_KEY Vulnerability​

Apache Superset administrators should treat this issue as a critical configuration security problem.
The following steps address the main weakness and reduce the risk of session forgery.

1. Replace SECRET_KEY With a Cryptographically Secure Value​

The first priority is to replace the weak signing key with a unique, unpredictable, high-entropy value.
You can generate a secure key using OpenSSL:

openssl rand -base64 42

Alternatively, Python's secrets module can generate a cryptographically secure random value:

import secrets
secret_key = secrets.token_urlsafe(64)
print(secret_key)

Configure the generated key through the appropriate Superset configuration mechanism.
For example, in superset_config.py:

SECRET_KEY = 'YOUR_NEW_RANDOM_SECRET_KEY'

Alternatively, Superset supports configuring the key through the SUPERSET_SECRET_KEY environment variable.
Important security requirements:

• Never use a predictable password as a signing key.
• Never reuse the same key across unrelated Superset installations.
• Do not publish the key in public repositories.
• Store sensitive configuration values in a secure environment or secrets manager.
• Restrict access to the configuration and deployment environment.

2. Restart Superset and Invalidate Existing Sessions​

After changing the signing key, restart the relevant Superset application services.
Sessions signed with the old key will no longer pass normal signature verification when the new key is active.
Administrators should verify that all application instances use the same new key and that existing sessions have been invalidated.
Important: Superset also documents a controlled key-rotation procedure using PREVIOUS_SECRET_KEY and the superset re-encrypt-secrets command when migrating existing installations. Follow the official procedure when encrypted metadata values must be preserved.

3. Review and Rotate FERNET_KEY When Necessary​

Superset uses cryptographic keys to protect sensitive stored configuration values, including database connection passwords.
If FERNET_KEY shares compromised secret material or has otherwise been exposed, it should be rotated carefully.
Before making changes:

• Back up the existing encryption key.
• Identify the encrypted values stored in the metadata database.
• Plan the migration to the replacement key.
• Verify that existing database connection credentials remain readable after migration.

Do not replace an encryption key blindly.
An incorrect rotation can make previously encrypted connection passwords unreadable.

4. Enable Secure Session Cookie Settings​

Review the Flask session cookie security configuration.
The following settings should be enabled:

SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True

These settings provide two important protections:
SESSION_COOKIE_SECURE
Ensures that browsers send the session cookie only over HTTPS connections.
SESSION_COOKIE_HTTPONLY
Prevents normal client-side JavaScript from reading the cookie through browser cookie APIs.
You should also review the SESSION_COOKIE_SAMESITE setting and select an appropriate value for your deployment.
These protections strengthen session security but do not replace a strong SECRET_KEY.

5. Enforce HTTPS and HSTS​

Ensure that all application traffic uses HTTPS.
Configure HTTP Strict Transport Security (HSTS) at the reverse proxy or web server.
This instructs supported browsers to use secure connections when communicating with the application.
Where possible:

• Enforce modern TLS configurations.
• Redirect HTTP traffic to HTTPS.
• Enable HSTS with an appropriate policy.
• Review reverse-proxy headers and trusted proxy settings.

6. Review the Default Administrator Account​

Administrator accounts should be reviewed after remediation.
Recommended actions include:

• Review the default administrator account.
• Remove unnecessary administrator privileges.
• Disable unused accounts.
• Enforce strong passwords.
• Enable MFA for administrators where supported by the authentication configuration.
• Review user roles and permissions.

MFA is an additional security layer, not a replacement for protecting the session-signing key.

7. Audit Application and Authentication Logs​

After fixing the vulnerability, investigate the application logs and reverse-proxy access logs for suspicious activity.
Pay particular attention to:

• Unexpected requests to /api/v1/me/.
• Unusual access to administrator APIs.
• Unexpected SQL Lab execution requests.
• Unfamiliar administrator sessions.
• Unexpected changes to dashboards or datasets.
• Suspicious user and role administration activity.

If compromise is suspected, investigate the incident and rotate other potentially exposed credentials and secrets.

---

📋 Recommended Security Checklist​

Use this checklist when reviewing an Apache Superset installation:

• Replace weak or predictable SECRET_KEY values.
• Generate a unique cryptographically secure signing key.
• Store secrets in a secure configuration or secrets manager.
• Restart all relevant Superset application instances.
• Invalidate existing sessions.
• Review FERNET_KEY and rotate it if compromised.
• Enable SESSION_COOKIE_SECURE.
• Enable SESSION_COOKIE_HTTPONLY.
• Review the SESSION_COOKIE_SAMESITE configuration.
• Enforce HTTPS and HSTS.
• Review administrator accounts and privileges.
• Enable MFA where supported.
• Audit authentication and administrative API activity.
• Review database connection permissions.
• Update Apache Superset to a supported security-maintained release.

---

📌 Conclusion​

The Apache Superset security assessment demonstrated how a weak Flask session signing key can undermine the application's authentication mechanism.
By exploiting the weak SECRET_KEY, the assessment confirmed that an administrator-level session could be accepted without valid login credentials.
The validation went beyond identifying a weak configuration. It demonstrated administrator identity recognition through /api/v1/me/, access to BI resources, and successful execution of a harmless SQL Lab query.
Although no customer records, credentials, or database table contents were accessed, the demonstrated access level represents a serious security risk.
For Superset administrators, the most important action is to replace weak signing keys immediately, invalidate existing sessions, review other cryptographic secrets, and investigate potentially suspicious activity.
A weak session-signing key can turn an authentication mechanism into a security weakness that exposes an entire BI platform.

---

Frequently Asked Questions​

-------------------

Can Apache Superset be accessed without a username or password?​

Yes. If an attacker knows a weak or compromised session-signing key, they may be able to forge an authenticated session and bypass normal login requirements.

What is the purpose of SECRET_KEY in Apache Superset?​

SECRET_KEY is a critical application secret used by Flask to protect session cookies and by Superset's security configuration to protect sensitive stored information.

Does this vulnerability require administrator interaction?​

No. The assessment demonstrated that an attacker who knows the weak signing key can potentially forge a session without administrator interaction or valid login credentials.

Can HTTPS prevent session forgery?​

No. HTTPS protects communication in transit, but it does not prevent an attacker from generating valid session signatures using a compromised signing key.

Does changing SECRET_KEY invalidate old sessions?​

Sessions signed with the old key will fail signature verification after the new key becomes active. Administrators should follow Superset's documented rotation procedure and verify session invalidation across all application instances.

Can a forged administrator session provide SQL access?​

Potentially, yes. The assessment demonstrated access to SQL Lab and successfully executed SELECT 1. Further database access depends on the permissions of the configured database connections.

Is changing FERNET_KEY also necessary?​

Not automatically. It should be reviewed and rotated if it shares compromised secret material or is otherwise exposed. Rotation must be planned carefully to preserve access to previously encrypted database connection credentials.

---

References​

• Apache Superset – Security Configurations
• Apache Superset – Configuring Superset
• Apache Superset – Production Security Guidance
• NIST National Vulnerability Database – CVE-2023-27524