FrancescoCastaldi commented on code in PR #45186:
URL: https://github.com/apache/superset/pull/45186#discussion_r4267919677


##########
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:
   Addressed in commit 15aae17857d83f31b9a977ff69e14bfabe1da252.
   
   Aligned the security comments in `requirements/base.in` with the remediation 
guide:
   - `msgpack`: now documents GHSA-6v7p-g79w-8964 / CVE-2026-57585 
(out-of-bounds read/crash on Unpacker reuse) and GHSA-j586-36cw-2gc2 (C 
extension memory leak on map key validation failure).
   - `pyarrow`: updated to document CVE-2026-25087 as use-after-free in IPC 
file reader with pre-buffering (GHSA-rgxp-2hwp-jwgg).



##########
docs/admin_docs/security/dependency-vulnerability-remediation.mdx:
##########
@@ -0,0 +1,93 @@
+---
+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 (CVE-2026-57585) | HIGH | `1.2.1` | 
`>=1.2.3` | Out-of-bounds read and crash when reusing an Unpacker instance 
after a caught error. Superset uses msgpack exclusively for SQL Lab 
asynchronous query result serialization (`RESULTS_BACKEND_USE_MSGPACK`); the 
Unpacker is never reused across error boundaries in production code paths. |
+| **msgpack** | GHSA-j586-36cw-2gc2 | HIGH | `1.2.3` | `>=1.2.3` | Memory leak 
in the C extension when map key validation raises an exception during unpacking 
(triggers with default `strict_map_key=True` when a map key is not 
`str`/`bytes`). In Superset, msgpack deserialization via 
`msgpack.loads(payload, raw=False)` in `superset/views/utils.py` uses this 
default on cached query results from the results backend, whose provenance is 
internal Celery worker execution rather than direct user input. Operators 
should upgrade to `msgpack>=1.2.3` (Option A) to eliminate the leak path 
directly rather than relying on payload non-reachability. |
+| **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 covering both GHSA-6v7p-g79w-8964, fixed in 1.2.1, and 
GHSA-j586-36cw-2gc2, fixed in 1.2.3).
+   - `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 
specific vulnerable code path is not reachable in the shipped Superset version 
and configuration can be documented and suppressed in `.trivyignore`:
+
+```text
+# CVE-2026-69247: PKCS#7 EnvelopedData decryption is not used by Superset
+CVE-2026-69247
+
+# CVE-2026-69249: Untrusted X.509 certificate path-building is not exposed in 
request processing
+CVE-2026-69249
+
+# CVE-2026-69248: Cryptography X.509 certificate verifier APIs 
(cryptography.x509.verification) are not called by Superset
+CVE-2026-69248
+
+# GHSA-537c-gmf6-5ccf: Wheel-bundled OpenSSL is not directly exposed; upgraded 
via Option A
+GHSA-537c-gmf6-5ccf

Review Comment:
   Addressed in commit 15aae17857d83f31b9a977ff69e14bfabe1da252.
   
   Updated the `.trivyignore` template in Option B to include both CVE and GHSA 
aliases for each multi-identifier advisory (wheel OpenSSL CVE-2026-34180 / 
GHSA-537c-gmf6-5ccf, msgpack Unpacker CVE-2026-57585 / GHSA-6v7p-g79w-8964, and 
pyarrow IPC file reader CVE-2026-25087 / GHSA-rgxp-2hwp-jwgg).
   
   Added an explicit note in the preamble explaining that Trivy requires 
suppression rules to match the exact identifier reported by the scan engine.



-- 
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]

Reply via email to