Live › vulnerability › CVE-2023-27524
Go to dashboardApache Superset ships with a default SECRET_KEY in its install instructions, and installations that kept that default let an attacker forge valid sessions. The attacker can authenticate and reach resources they should not see.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC, 3h before NVD. All times on this page are UTC.
Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| Apache Superset | vendor | – | – |
| apache superset | vendor | <= 2.0.1 | – |
Check superset_config.py or the SUPERSET_SECRET_KEY environment variable and confirm it is not the documented default value.
Set a unique, long random SECRET_KEY (or SUPERSET_SECRET_KEY) in the deployment config and restart Superset.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Session Validation attacks in Apache Superset versions up to and including 2.0.1. Installations that have not altered the default configured SECRET_KEY according to installation instructions allow for an attacker to authenticate and access unauthorized resources. This does not affect Superset administrators who have changed the default value for SECRET_KEY config.
All superset installations should always set a unique secure random SECRET_KEY. Your SECRET_KEY is used to securely sign all session cookies and encrypting sensitive information on the database.
Add a strong SECRET_KEY to your superset_config.py file like:
SECRET_KEY = <YOUR_OWN_RANDOM_GENERATED_SECRET_KEY>
Alternatively you can set it with SUPERSET_SECRET_KEY environment variable.
This page as .md · .json · in your agent: get_signal("CVE-2023-27524")
CISA KEV catalog, Creative Commons 0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.