sadpandajoe commented on code in PR #45186: URL: https://github.com/apache/superset/pull/45186#discussion_r4268080916
########## 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: The `.trivyignore` template still carries the old rationale at lines 82-83: the GHSA-j586-36cw-2gc2 entry says custom validators and container hooks are not configured, but the table row now says the leak triggers with the default `strict_map_key=True`. An operator on msgpack 1.2.2 who copies that block would suppress a finding the results-backend `msgpack.loads` path can still hit. Could that comment be reworded to match the table (or the ignore entry dropped in favor of upgrading to `msgpack>=1.2.3`)? -- 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]
