sadpandajoe commented on code in PR #45186:
URL: https://github.com/apache/superset/pull/45186#discussion_r4285445342
##########
superset-core/pyproject.toml:
##########
@@ -43,7 +43,7 @@ classifiers = [
dependencies = [
"flask-appbuilder>=5.2.0,<6",
"isodate>=0.7.0",
- "pyarrow>=16.0.0",
+ "pyarrow>=25.0.1, <26",
Review Comment:
Moving the core package from `pyarrow>=16.0.0` to `>=25.0.1, <26` means any
extension or integration that pins an older Arrow (for example
`pyarrow==24.0.0`) can no longer install `apache-superset-core`, even though
the advisory's fix landed in 23.0.1 and core only uses
`pa.DataType`/`pa.Table`. The main package and `requirements/base.txt` already
enforce Arrow 25.0.1 at the base commit, so this adds no protection for
container installs. Could core keep a lower floor (and no `<26` ceiling) so
only the application pins the narrow window?
##########
docs/admin_docs/security/dependency-vulnerability-remediation.mdx:
##########
@@ -0,0 +1,97 @@
+---
+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.
Review Comment:
`requirements/base.in` holds version ranges (the new `msgpack>=1.2.3,<1.3.0`
line is one); only the generated `requirements/base.txt` has exact pins. Read
as written, an operator could treat installing from `base.in` as a
reproducible, validated environment. Should this describe `base.in` as resolver
input and `base.txt` as the locked output?
--
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]
