STAC-24966-vex-python-tarfile-cve

index.json

@@ -1,5 +1,5 @@
 {
-  "updated_at": "2026-06-05T15:40:01Z",
+  "updated_at": "2026-06-08T06:50:13Z",
   "packages": [
     {
       "id": "pkg:maven/org.eclipse.jetty/jetty-http",

pkg/oci/quay.io/stackstate/stackstate-k8s-agent/scan.openvex.json

@@ -188,6 +188,27 @@
       "impact_statement": "The image embeds CPython built from the upstream tarball pinned at omnibus/config/software/python3.rb:3 (default_version \"3.13.13\"), which is below the fixed 3.15.0 line, and none of the patches in omnibus/config/patches/python3/ address ftplib (only CVE-2025-6965-sqlite-3.50.4.patch and CVE-2025-8194-tarfile.patch are applied). The vulnerable Lib/ftplib.py:ftpcp ships unmodified in /opt/stackstate-agent/embedded/lib/python3.13/ftplib.py. However, the sink is unreachable from any shipped execute path: a tree-wide grep for `ftplib`, `from ftplib`, `import ftplib`, `FTP_TLS`, `ftplib.`, and `ftpcp` across cmd/, pkg/, omnibus/python-scripts/, rtloader/, Dockerfiles/, and the embedded check wrappers returns zero hits. The single match on the literal string `ftp://` is at omnibus/python-scripts/packages.py:254, where it is a substring filter used to skip URL-style entries while parsing pip requirements files \u2014 no ftplib client is constructed and ftpcp is never invoked. The agent's first-party shipped Python under cmd/agent/dist/checks/ (network_checks.py, winwmi_check.py, prometheus_check/, libs/wmi/sampler.py), Dockerfiles/agent/secrets-helper/readsecret.py, and omnibus/python-scripts/{pre,post,packages}.py do not import ftplib, and the stackstate-agent-integrations bundle pinned at omnibus/config/software/stackstate-agent-integrations-py3.rb:36 (STACKSTATE_INTEGRATIONS_VERSION 7.71.2-3 from stackstate-deps.json:2) is Kubernetes/container/Prometheus-oriented with no FTP-based check. Independent of reachability, the ftpcp() SSRF requires the victim to actively call ftpcp() to relay a file between two attacker-influenced FTP servers (the bug is that ftpcp forwards the source server's PASV response into a PORT command on the target), which is a relay pattern the agent has no functional reason to perform. The image's exposed ports at Dockerfiles/agent/Dockerfile:74 are 8125/udp (DogStatsD) and 8126/tcp (trace-agent APM) \u2014 neither speaks FTP and neither can drive ftplib code. The container also runs non-root as USER 1000:1000 (Dockerfiles/agent/Dockerfile:71), but that is incidental; the determinative fact is that no shipped code path reaches ftpcp.",
       "action_statement": null
     },
+    {
+      "vulnerability": {
+        "name": "CVE-2026-7774"
+      },
+      "products": [
+        {
+          "@id": "pkg:oci/stackstate-k8s-agent",
+          "subcomponents": [
+            {
+              "@id": "pkg:generic/python@3.13.13"
+            }
+          ]
+        }
+      ],
+      "status": "not_affected",
+      "status_notes": "Reviewed quay.io/stackstate/stackstate-k8s-agent:cb4d9ce2 on 2026-06-08. The embedded CPython 3.13.13 tarfile implementation is present, but the supported k8s-agent runtime does not extract attacker-controlled tar archives.",
+      "justification": "vulnerable_code_not_in_execute_path",
+      "impact_statement": "CVE-2026-7774 affects CPython's tarfile.data_filter path traversal protection when extracting crafted tar archives through tarfile.extract(), tarfile.extractall(), or callers such as shutil.unpack_archive(). The image embeds CPython 3.13.13 under /opt/stackstate-agent/embedded/, so the vulnerable standard-library tarfile.py is physically present and Grype's CPE match is expected. Runtime inspection of quay.io/stackstate/stackstate-k8s-agent:cb4d9ce2 found no service startup script, cont-init script, agent entrypoint, or supported agent process that imports tarfile or calls tarfile.extract(), tarfile.extractall(), or shutil.unpack_archive() on external input. The supported agent runtime exposes DogStatsD on 8125/udp and the trace agent on 8126/tcp; neither endpoint accepts tar archives or drives Python archive extraction. The only meaningful extractall() path found in the image is in auxiliary OpenSCAP tooling, /opt/stackstate-agent/embedded/lib/python3.13/site-packages/oscap_docker_python/oscap_docker_util.py, which is reached by the oscap-docker CLI and extracts a tar stream returned by the local Docker daemon for an operator-selected container/image. That tooling is not invoked by the supported Kubernetes agent runtime and requires explicit local/operator execution with Docker access, so it is outside the remote or unauthenticated adversary model for the deployed agent image. Generic packaging/build helpers that also reference extractall() are similarly not part of the running agent service path.",
+      "action_statement": "Defense in depth: remove OpenSCAP/build-time helper tooling from the runtime image if it is not required by supported agent workflows, and re-evaluate this VEX statement when the embedded Python runtime is upgraded or the agent runtime starts invoking tar archive extraction.",
+      "timestamp": "2026-06-08T06:49:39Z"
+    },
     {
       "vulnerability": {
         "name": "CVE-2026-3298"