sadpandajoe commented on code in PR #45186:
URL: https://github.com/apache/superset/pull/45186#discussion_r4260005610
##########
docs/admin_docs/security/dependency-vulnerability-remediation.mdx:
##########
@@ -0,0 +1,90 @@
+---
+title: Dependency Vulnerability Remediation & Scanner Guidance
+sidebar_position: 3
+---
+
+# Dependency Vulnerability Remediation & Container Scanner Guidance
+
+This guide addresses third-party dependency vulnerabilities reported by
container security scanners (such as Trivy, Grype, and Snyk) in Apache Superset
environments, specifically regarding dependency constraint handling for
cryptography, msgpack, and pyarrow (referencing issue #45087).
+
+## 1. Vulnerability Applicability & Risk Assessment
+
+When security scanners evaluate Apache Superset container images, findings
frequently arise in transitive or pinned direct dependencies. The table below
details the applicability and actual exploitability surface of recently
reported findings:
+
+| Package | Finding ID | Severity | Upstream Fixed Version | Superset Target
Floor | Superset Code Path & Exploitability Analysis |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| **cryptography** | CVE-2026-69247 | HIGH | `50.0.0` | `>=50.0.2` |
Bleichenbacher timing and error decryption oracle in PKCS#7 EnvelopedData.
Superset does not consume, parse, or decrypt PKCS#7 or S/MIME enveloped data. |
+| **cryptography** | CVE-2026-69249 | HIGH | `49.0.0` | `>=50.0.2` | X.509
path-building algorithm denial of service with duplicate intermediate
certificates. Superset parses leaf database SSL certificates using
`load_pem_x509_certificate` and does not build untrusted X.509 certification
paths during web request processing. |
+| **cryptography** | CVE-2026-69248 | MEDIUM | `49.0.0` | `>=50.0.2` |
Wildcard-DNS name-constraint bypass in the cryptography X.509 certificate
verifier (`cryptography.x509.verification.PolicyBuilder`). Superset parses leaf
database SSL certificates using `load_pem_x509_certificate` and does not invoke
cryptography's certificate verification or path validation APIs. TLS transport
verification is performed by underlying network and database drivers via
OpenSSL/Python `ssl`. |
+| **cryptography** | GHSA-537c-gmf6-5ccf (CVE-2026-34180) | HIGH | `48.0.1` |
`>=50.0.2` | Vulnerabilities in OpenSSL bundled in binary wheels (remediated in
upstream wheels from 48.0.1 and pinned to 50.0.2 in Superset locked
requirements). In production container deployments following Option A, the
runtime libraries are updated; raw cryptographic primitives are not exposed to
untrusted external callers. |
+| **msgpack** | GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 | HIGH | `1.2.3` |
`>=1.2.3` | Utilized internally for SQL Lab asynchronous query result
serialization (`RESULTS_BACKEND_USE_MSGPACK`). Raw msgpack byte streams are
generated and consumed only within the trusted backend cache boundary.
Exploitability requires full cache store compromise. |
Review Comment:
The msgpack row lists GHSA-6v7p-g79w-8964 with fixed version `1.2.3`, but
that advisory is the Unpacker-reuse out-of-bounds read affecting `<= 1.2.0` and
patched in `1.2.1`, not an extension-type deserialization bug. The same
mismatch shows in the `base.in` comment ("Deserialization vulnerability in
extension types"), `UPDATING.md`, and the "vulnerable 1.0.x through 1.2.2"
wording in section 2; the advisory that 1.2.3 actually fixes is
GHSA-j586-36cw-2gc2 (strict_map_key leak / streaming Unpacker). An operator or
scanner triaging from this table would get the wrong fixed version and impact
for the first ID. Could the IDs, fixed versions and descriptions be split per
advisory and the comments corrected?
##########
docs/admin_docs/security/dependency-vulnerability-remediation.mdx:
##########
@@ -0,0 +1,90 @@
+---
+title: Dependency Vulnerability Remediation & Scanner Guidance
+sidebar_position: 3
+---
+
+# Dependency Vulnerability Remediation & Container Scanner Guidance
+
+This guide addresses third-party dependency vulnerabilities reported by
container security scanners (such as Trivy, Grype, and Snyk) in Apache Superset
environments, specifically regarding dependency constraint handling for
cryptography, msgpack, and pyarrow (referencing issue #45087).
+
+## 1. Vulnerability Applicability & Risk Assessment
+
+When security scanners evaluate Apache Superset container images, findings
frequently arise in transitive or pinned direct dependencies. The table below
details the applicability and actual exploitability surface of recently
reported findings:
+
+| Package | Finding ID | Severity | Upstream Fixed Version | Superset Target
Floor | Superset Code Path & Exploitability Analysis |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| **cryptography** | CVE-2026-69247 | HIGH | `50.0.0` | `>=50.0.2` |
Bleichenbacher timing and error decryption oracle in PKCS#7 EnvelopedData.
Superset does not consume, parse, or decrypt PKCS#7 or S/MIME enveloped data. |
+| **cryptography** | CVE-2026-69249 | HIGH | `49.0.0` | `>=50.0.2` | X.509
path-building algorithm denial of service with duplicate intermediate
certificates. Superset parses leaf database SSL certificates using
`load_pem_x509_certificate` and does not build untrusted X.509 certification
paths during web request processing. |
+| **cryptography** | CVE-2026-69248 | MEDIUM | `49.0.0` | `>=50.0.2` |
Wildcard-DNS name-constraint bypass in the cryptography X.509 certificate
verifier (`cryptography.x509.verification.PolicyBuilder`). Superset parses leaf
database SSL certificates using `load_pem_x509_certificate` and does not invoke
cryptography's certificate verification or path validation APIs. TLS transport
verification is performed by underlying network and database drivers via
OpenSSL/Python `ssl`. |
+| **cryptography** | GHSA-537c-gmf6-5ccf (CVE-2026-34180) | HIGH | `48.0.1` |
`>=50.0.2` | Vulnerabilities in OpenSSL bundled in binary wheels (remediated in
upstream wheels from 48.0.1 and pinned to 50.0.2 in Superset locked
requirements). In production container deployments following Option A, the
runtime libraries are updated; raw cryptographic primitives are not exposed to
untrusted external callers. |
+| **msgpack** | GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 | HIGH | `1.2.3` |
`>=1.2.3` | Utilized internally for SQL Lab asynchronous query result
serialization (`RESULTS_BACKEND_USE_MSGPACK`). Raw msgpack byte streams are
generated and consumed only within the trusted backend cache boundary.
Exploitability requires full cache store compromise. |
+| **pyarrow** | CVE-2026-25087 | HIGH | `23.0.1` | `>=25.0.1` | Use-after-free
in the Arrow C++ IPC file reader with pre-buffering (GHSA-rgxp-2hwp-jwgg).
Superset invokes the Parquet reader for user data uploads and the IPC stream
reader (`RecordBatchStreamReader`) for SQL Lab asynchronous query result
serialization; it does not invoke the IPC file reader (`RecordBatchFileReader`
with pre-buffering). Upstream fixes start at `23.0.1`, with `>=25.0.1` enforced
as Superset target floor in this PR. |
+
+## 2. Dependency Constraint Architecture
+
+Apache Superset manages dependencies across two layers:
+
+1. **Package Declarations (`pyproject.toml` and
`superset-core/pyproject.toml`)**:
+ Specifies flexible semantic version ranges to avoid dependency resolver
conflicts in downstream custom deployments.
+ - `cryptography` (`pyproject.toml`): `>=50.0.2, <51.0.0` (enforces
remediated releases covering PKCS#7, path-building, certificate verification
name constraints, and wheel OpenSSL advisories).
+ - `msgpack` (`pyproject.toml`): `>=1.2.3, <1.3` (enforces remediated
releases while barring vulnerable 1.0.x through 1.2.2 releases).
+ - `pyarrow` (`pyproject.toml` and `superset-core/pyproject.toml`):
`>=25.0.1, <26` (enforces modern non-vulnerable engines in both core and main
packages).
+
+2. **Locked Requirements (`requirements/base.in` and
`requirements/base.txt`)**:
+ Pins exact validated versions for official Docker images and deterministic
continuous integration builds.
+
+## 3. Operator Mitigations & Container Workarounds
+
+If you are running an existing container image where dependency constraints
prevent direct pip upgrades, the following approaches allow immediate
remediation without breaking Superset:
+
+### Option A: Extend Official Docker Image with Patched Dependencies
+
+The official Docker image executes Superset inside a Python virtual
environment located at `/app/.venv`. To ensure upgraded dependencies are
installed directly into Superset runtime rather than the root container system
packages, use `uv pip install --python /app/.venv/bin/python` (or
`/app/.venv/bin/pip install` in environments without `uv`).
+
+When upgrading `cryptography>=50.0.2`, `pyOpenSSL` must also be upgraded to
`>=26.4.0` (matching the version pinned in `requirements/base.txt`). pyOpenSSL
releases prior to 26.4.0 cap `cryptography` below 50 (with 25.x releases also
attempting to access `_lib.GEN_EMAIL` when `OpenSSL.crypto` is imported, which
is no longer exposed in cryptography 50.x). Upgrading pyOpenSSL to `>=26.4.0`
alongside cryptography satisfies the dependency resolver and ensures imports of
`OpenSSL` (used by Snowflake private key authentication and Google Cloud mutual
TLS) succeed without error:
+
+```dockerfile
+FROM apache/superset:latest
+
+USER root
+RUN uv pip install --no-cache-dir --python /app/.venv/bin/python \
+ "cryptography>=50.0.2" \
+ "pyopenssl>=26.4.0" \
+ "msgpack>=1.2.3" \
+ "pyarrow>=25.0.1"
+
+USER superset
+```
+
+### Option B: Scanner Triage and Ignore Rules (`.trivyignore`)
+
+For organizations maintaining automated compliance gates, findings where the
vulnerable code path is unreachably encapsulated behind authentication can be
documented and suppressed in `.trivyignore`:
Review Comment:
This suggests suppressing a finding in `.trivyignore` because the vulnerable
path sits behind authentication. SECURITY.md treats Gamma/Alpha/`sql_lab` users
as untrusted beyond their granted capabilities, so authenticated reachability
(uploads, SQL Lab results) isn't a safe reason to dismiss a dependency finding.
A security team following this criterion could suppress a real, reachable flaw.
Could the criterion be advisory-specific non-reachability for the shipped
version and configuration instead of authentication?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
