Daniel Gaspar

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions prior to 6.0.0 **Description** A sensitive data exposure issue exists in Apache Superset that allows authenticated users to retrieve sensitive user information. The `'/api/v1/tag'` API endpoint, when enabled, improperly serializes and returns sensitive fields associated with user objects, including password hashes (pbkdf2), email addresses, and login statistics. Users with low privileges, such as those with the Gamma role, can view this sensitive authentication data. **Recommendations** Upgrade to version 6.0.0, which resolves the issue. Ensure `TAGGING SYSTEM` is set to False, as this is the default configuration for Apache Superset.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions prior to 6.0.0 **Description** An improper authorization issue exists in Apache Superset that allows a low-privileged user to bypass data access controls. Specifically, an authenticated attacker with permissions to write datasets and read charts can bypass permission checks by overwriting the SQL query of an existing dataset when creating a dataset. This allows unauthorized data access. **Recommendations** Upgrade to version 6.0.0 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions prior to 4.1.2 **Description** Apache Superset uses a configurable dictionary, `DISALLOWED SQL FUNCTIONS`, to limit the execution of potentially sensitive SQL functions in SQL Lab and charts. A flaw exists because the default list for the ClickHouse engine was not comprehensive, allowing potentially harmful SQL functions to be executed. **Recommendations** Upgrade to version 4.1.2 to resolve the issue.

Name of the Vulnerable Software and Affected Versions: Apache Superset versions prior to 4.1.3 Description: A guest user accessing a chart in Apache Superset receives an API response from the `/chart/data` endpoint that includes a `query` field. This field improperly discloses database schema information, such as table names, to the low-privileged guest user. Recommendations: Upgrade to version 4.1.3.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions through 4.1.1 **Description** The issue is related to improper authorization, allowing authenticated users with read permissions to take ownership of dashboards, charts, or datasets. **Recommendations** For Apache Superset versions through 4.1.1, upgrade to version 4.1.2 or above to fix the issue.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions prior to 4.1.0 **Description** The issue is related to improper authorization in Apache Superset, specifically affecting Postgres analytic databases. An attacker with access to SQLLab can craft a specially designed SQL DML statement that is incorrectly identified as a read-only query, allowing its execution and potentially enabling unauthorized write access. Non-Postgres analytics database connections and Postgres analytics database connections set with a readonly user are not vulnerable. **Recommendations** To resolve the issue, users are recommended to upgrade to version 4.1.0, which fixes the problem. As a temporary workaround, consider restricting access to SQLLab or setting up Postgres analytics database connections with a readonly user to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: Apache Superset versions prior to 4.1.0 Description: The issue is related to an SQL Injection vulnerability due to improper neutralization of special elements used in SQL commands. Specifically, certain engine-specific functions are not checked, allowing attackers to bypass SQL authorization. The affected functions include `query to xml and xmlschema`, `table to xml`, and `table to xml and xmlschema`. This vulnerability may allow a remote attacker to execute arbitrary SQL code. Recommendations: For versions prior to 4.1.0, upgrade to version 4.1.0 to fix the issue. Alternatively, add the Postgres functions `query to xml and xmlschema`, `table to xml`, and `table to xml and xmlschema` to the config set `DISALLOWED SQL FUNCTIONS` as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions prior to 4.1.0 **Description** The issue is related to the generation of error messages containing analytics metadata information in Apache Superset. This can allow a remote attacker to gain unauthorized access to protected information. Users are recommended to upgrade to a version that fixes the issue. **Recommendations** For versions prior to 4.1.0, upgrade to version 4.1.0 to resolve the issue. As a temporary workaround, consider restricting access to error messages that may contain sensitive analytics metadata information until the upgrade is applied.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions 1.3.0 through 2.0.1 **Description** An authenticated user with specific data permissions could access database connections stored passwords by requesting a specific REST API. **Recommendations** For Apache Superset versions 1.3.0 through 2.0.1, consider restricting access to the REST API endpoint that allows access to database connections stored passwords until a patch is available. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Superset versions 1.5.2 and prior Apache Superset version 2.0.0 **Description** A vulnerability in the SQL Alchemy connector of Apache Superset allows an authenticated user with read access to a specific database to add subqueries to the WHERE and HAVING fields referencing tables on the same database that the user should not have access to, despite the user having the feature flag `ALLOW ADHOC SUBQUERY` disabled. **Recommendations** For Apache Superset versions 1.5.2 and prior, consider disabling the SQL Alchemy connector until a patch is available. For Apache Superset version 2.0.0, consider disabling the SQL Alchemy connector until a patch is available. As a temporary workaround, consider restricting access to the `WHERE` and `HAVING` fields in the SQL Alchemy connector to minimize the risk of exploitation.