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


##########
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 or container hooks raise an 
exception during unpacking. Superset does not configure custom map key 
validators or container hooks; the vulnerable extension code path is never 
triggered in standard deployment. |

Review Comment:
   Thanks @sadpandajoe! Completely agreed, leaving `GHSA-j586-36cw-2gc2` in the 
suppression template would provide false assurance since `msgpack.loads` in 
`superset/views/utils.py` runs with default `strict_map_key=True` on 
results-backend payloads.
   
   In commit `dfe79db0b3`, I have dropped `GHSA-j586-36cw-2gc2` entirely from 
the `.trivyignore` template and added an explicit note explaining that 
operators should remediate by upgrading to `msgpack>=1.2.3` via Option A rather 
than ignoring the advisory.



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