Skip to main content
Version: Next

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:

PackageFinding IDSeverityUpstream Fixed VersionSuperset Target FloorSuperset Code Path & Exploitability Analysis
cryptographyCVE-2026-69247HIGH50.0.0>=50.0.2Bleichenbacher timing and error decryption oracle in PKCS#7 EnvelopedData. Superset does not consume, parse, or decrypt PKCS#7 or S/MIME enveloped data.
cryptographyCVE-2026-69249HIGH49.0.0>=50.0.2X.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.
cryptographyCVE-2026-69248MEDIUM49.0.0>=50.0.2Wildcard-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.
cryptographyGHSA-537c-gmf6-5ccf (CVE-2026-34180)HIGH48.0.1>=50.0.2Vulnerabilities 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.
msgpackGHSA-6v7p-g79w-8964 (CVE-2026-57585)HIGH1.2.1>=1.2.3Out-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.
msgpackGHSA-j586-36cw-2gc2HIGH1.2.3>=1.2.3Memory 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.
pyarrowCVE-2026-25087HIGH23.0.1>=25.0.1Use-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:

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. Note that Trivy matches suppression rules against the exact identifier reported by the scan engine; both CVE and GHSA aliases are provided below where applicable so rules match regardless of whether your feeds report under CVE or GitHub Advisory Database identifiers:

# 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

# Wheel-bundled OpenSSL: not directly exposed; upgraded via Option A
CVE-2026-34180
GHSA-537c-gmf6-5ccf

# Msgpack Unpacker reuse after error: Unpacker instances are not reused across error boundaries
CVE-2026-57585
GHSA-6v7p-g79w-8964

# CVE-2026-25087 / GHSA-rgxp-2hwp-jwgg: Arrow C++ IPC file reader with pre-buffering is not invoked; Superset calls Parquet for uploads and IPC stream reader for SQL Lab results (remediated in pyarrow>=25.0.1)
CVE-2026-25087
GHSA-rgxp-2hwp-jwgg
note

GHSA-j586-36cw-2gc2 is intentionally omitted from the .trivyignore template above. Because msgpack deserialization via msgpack.loads(..., raw=False) in superset/views/utils.py uses the default strict_map_key=True which can trigger the C extension memory leak on invalid map keys, operators running msgpack==1.2.2 should remediate by upgrading to msgpack>=1.2.3 (Option A) rather than suppressing the finding.

4. Questions & Answers for Security Teams​

Q: Are these findings considered true vulnerabilities in Apache Superset? A: Per the Apache Superset Security Model (documented in SECURITY.md), vulnerabilities in shipped direct dependencies are kept in scope, which is why Superset directly bumps dependency floors to remediated releases. For operators managing legacy container images before upgrades are applied, the exploitability analysis in this guide documents the specific execution paths showing why unpatched intermediate environments are not exposed to remote code execution or authentication bypass.

Q: Why are dependency bounds not completely unpinned? A: Database connectors and analytics engines (e.g., Snowflake, BigQuery, Trino, ClickHouse) impose mutual constraints on foundational packages like PyArrow and Cryptography. Version ranges are carefully calibrated to balance maximum security coverage with multi-database ecosystem stability.