From 9124b60473f433102bb72b9cd8536135a8db30ea Mon Sep 17 00:00:00 2001 From: "SUSE Observability AI (POC)" Date: Sun, 6 Sep 2026 11:17:21 +0000 Subject: [PATCH 1/2] VEX the agent krb5 findings and realign the Python statements to 3.13.15 The daily dev chart scan gates on the agent image, and six of its findings have no compatible fix and no statement that applies. Four krb5 HIGHs (CVE-2007-5894, CVE-2007-3149, CVE-2026-40355, CVE-2026-40356) have no statement at all. krb5 1.21.3 is inside the affected range and upstream has not released the 1.22.3 that fixes the two 2026 defects, so no bump can clear them. The 2007 pair name components this image does not build: the gssftp daemon and sudo. The 2026 pair need a GSS acceptor plus a NegoEx mechanism in /etc/gss/mech, and neither exists here. Two Python statements (CVE-2025-15367, CVE-2026-4360) had gone inert: their subcomponents were pinned to python@3.13.13 and @3.13.14 while the image now ships 3.13.15, which Grype requires to match. Rather than bump the pin mechanically, both premises were re-established against the current image. CVE-2025-15367 holds unchanged. CVE-2026-4360's recorded rationale had gone stale: it cited a bpftool extraction path that this image no longer ships, so the impact statement is restated on what is actually true now, that the shipped tree contains no first-party tarfile.extract() call at all. Every statement is pinned to the analysed component version, so a future krb5 or CPython bump makes it inert rather than silently carrying a reachability claim onto code nobody reviewed. Verified on ff38da51 across both published architectures: Grype moves exactly these six findings to ignoredMatches, activates nothing new, and leaves the three containerd suppressions in place. Refs #38, #34 --- index.json | 2 +- .../stackstate-k8s-agent/scan.openvex.json | 185 +++++++++++++++++- 2 files changed, 177 insertions(+), 10 deletions(-) diff --git a/index.json b/index.json index 462f278..e6b6808 100644 --- a/index.json +++ b/index.json @@ -1,5 +1,5 @@ { - "updated_at": "2026-08-31T13:21:18Z", + "updated_at": "2026-09-06T11:13:42Z", "packages": [ { "id": "pkg:golang/github.com/containerd/containerd", diff --git a/pkg/oci/stackstate-k8s-agent/scan.openvex.json b/pkg/oci/stackstate-k8s-agent/scan.openvex.json index 6a2e5c1..3248b01 100644 --- a/pkg/oci/stackstate-k8s-agent/scan.openvex.json +++ b/pkg/oci/stackstate-k8s-agent/scan.openvex.json @@ -2,7 +2,7 @@ "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://github.com/StackVista/vexhub/pkg/oci/stackstate-k8s-agent/CVE-2026-6100", "author": "SUSE Observability Security Team", - "version": 2, + "version": 3, "statements": [ { "vulnerability": { @@ -177,6 +177,9 @@ }, { "@id": "pkg:generic/python@3.13.14" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] }, @@ -188,6 +191,9 @@ }, { "@id": "pkg:generic/python@3.13.14" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] }, @@ -199,15 +205,19 @@ }, { "@id": "pkg:generic/python@3.13.14" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] } ], "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path", - "impact_statement": "The image embeds a full CPython 3.13.13 interpreter via the omnibus build defined in omnibus/config/software/python3.rb:3 (default_version \"3.13.13\"), shipped with the unmodified standard library, so Lib/poplib.py \u2014 and the vulnerable POP3._putcmd sink \u2014 is present on disk inside /opt/stackstate-agent/embedded/. However, no first-party Go, Python, or shell code in stackstate-agent or stackstate-agent-integrations imports or otherwise references the poplib module: a recursive grep across both trees for `poplib`, `import poplib`, `from poplib`, and `POP3` returns zero matches. There is no agent check, integration, helper script, or entrypoint that opens a POP3 session, so POP3._putcmd is never reached at runtime. The Python interpreter shipped in the image is invoked exclusively by the agent's check loader (rtloader) to execute integrations under conf.d/checks.d, none of which exercise poplib, and CVSS PR:H confirms an attacker would additionally need authenticated control over POP3 command arguments \u2014 a surface this image does not expose (no POP3 client is constructed and no POP3 ports are listened on; the only EXPOSE directives in Dockerfiles/agent/Dockerfile:75 are 8125/udp DogStatsD and 8126/tcp trace-agent). The container also runs as USER 1000:1000 per Dockerfile:71, further reducing residual risk. The 2026-06-30 cve-reporter scan of quay.io/stackstate/stackstate-k8s-agent:5bc56023 reports the same finding against pkg:generic/python@3.13.14 at /opt/stackstate-agent/embedded/bin/python3.13; the source, packaging, and supported-runtime reachability analysis above remains valid for the current 3.13.14 build.", - "status_notes": "Revalidated against quay.io/stackstate/stackstate-k8s-agent:5bc56023 on 2026-06-30; that image reports the embedded interpreter as pkg:generic/python@3.13.14 at /opt/stackstate-agent/embedded/bin/python3.13, and the same SUSE Observability runtime reachability conclusion applies.", - "timestamp": "2026-06-30T15:44:21Z" + "impact_statement": "CVE-2025-15367 is in the POP3._putcmd sink of the CPython standard library module Lib/poplib.py. The image embeds a full CPython interpreter under /opt/stackstate-agent/embedded/, so poplib.py is present on disk, but no shipped first-party code reaches it. A recursive search of the whole shipped tree (/opt/stackstate-agent, including every stackstate_checks integration in site-packages, python-scripts/ and /etc/stackstate-agent) for the tokens poplib and POP3 returns exactly one hit, embedded/lib/python3.13/pydoc_data/module_docs.py, which is inert documentation data rather than executable code; there is no import of poplib, no POP3 object construction and no POP3 session anywhere in shipped code. /etc/stackstate-agent/checks.d is empty, so no additional check code is layered in at build time. The interpreter is invoked only by the agent's rtloader check loader to run the bundled integrations, none of which exercise poplib. The image exposes only 8125/udp (DogStatsD) and 8126/tcp (trace-agent) and no POP3 port, and CVSS PR:H means an attacker would additionally need authenticated control of POP3 command arguments - a surface this image does not present. The container runs as USER 1000:1000.", + "status_notes": "Re-verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521). The embedded interpreter now reports itself as 3.13.15 (sys.version probed in the running image) and Grype reports the finding against pkg:generic/python@3.13.15, so pkg:generic/python@3.13.15 is added to subcomponents; the previously listed 3.13.13 and 3.13.14 pins are retained for images still in support. The reachability premise - no shipped code referencing poplib or POP3 - was re-established on both architectures and is unchanged by the interpreter patch bump.", + "timestamp": "2026-09-06T11:12:13Z", + "action_statement": "This statement is pinned to the interpreter versions listed in subcomponents, so a future CPython patch bump makes it inert rather than silently over-broad; extend subcomponents only after re-confirming that no shipped code references poplib or POP3. Re-review if any agent check, integration or helper script begins opening a POP3 session." }, { "vulnerability": { @@ -799,6 +809,9 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] }, @@ -807,6 +820,9 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] }, @@ -815,16 +831,19 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" + }, + { + "@id": "pkg:generic/python@3.13.15" } ] } ], "status": "not_affected", - "status_notes": "Reviewed quay.io/stackstate/stackstate-k8s-agent:3ce0270e and source commit 3ce0270ebe on 2026-07-20. The only shipped runtime tar extraction path excludes hardlinks before calling tarfile.extract().", + "status_notes": "Re-verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521). The embedded interpreter now reports 3.13.15, and Grype reports the finding against pkg:generic/python@3.13.15, so that PURL is added to subcomponents. The rationale was re-derived from the current image rather than carried over: the previously cited bpftool extraction path is no longer shipped, and the surviving argument is that the shipped tree contains no first-party tarfile.extract() call. Upstream still lists no fixed CPython release for this advisory.", "justification": "vulnerable_code_not_in_execute_path", - "impact_statement": "CVE-2026-4360 affects tarfile.extract() handling of hardlinks. The sole shipped runtime extraction path iterates archive members, accepts only a member for which TarInfo.isfile() is true, renames the selected regular file to the fixed basename bpftool, and extracts only that member. Tar hardlinks have LNKTYPE and do not satisfy isfile(), so the vulnerable hardlink branch cannot be reached. Other repository extraction calls are build or test tooling and are not part of the agent runtime image.", - "action_statement": "Upgrade the embedded CPython runtime when a compatible 3.13.x patch release fixes CVE-2026-4360, then retire this statement. Re-review if shipped agent code adds another tar extraction path or permits hardlink members.", - "timestamp": "2026-07-20T07:19:56Z" + "impact_statement": "CVE-2026-4360 affects hardlink handling in tarfile.extract(). No shipped first-party code in this image calls it. A recursive search of the whole shipped tree for tarfile.extract / extractall, excluding the CPython standard library and the packaging tooling (pip, setuptools, wheel, pkg_resources, build, virtualenv), leaves exactly one tarfile.extract() call on both published architectures: site-packages/dateutil/zoneinfo/rebuild.py:24. That function is dateutil's maintenance utility for regenerating its own bundled zoneinfo tarball. It is unreachable here for three independent reasons: nothing in the shipped tree imports or calls dateutil.zoneinfo.rebuild (the rebuild( matches elsewhere are unrelated methods on dateutil.rrule's internal iterinfo class and on pydantic schema objects); it requires the caller to pass an explicit IANA tz tarball path plus a zonegroups member list, and no caller exists; and it shells out to the zic compiler via subprocess.check_call, which is absent from both architectures, so it would fail before extraction completed. The only other archive extraction in the shipped tree, pyproject_hooks/_in_process/_in_process.py:241, is zipfile.extractall and not tarfile. pynag's SshConfig parser touches tar but uses extractfile() and addfile(), which return file objects and never create filesystem links, so they do not enter the vulnerable hardlink branch; SshConfig is only re-exported by pynag.Parsers and is never instantiated by shipped code, and would additionally require an operator-configured paramiko SSH connection. The bpftool extraction path cited when this statement was first written is not present in this image at all - bpftool appears nowhere in either architecture's filesystem - so the conclusion now rests on there being no first-party tarfile.extract() call rather than on that path filtering hardlinks.", + "action_statement": "Upgrade the embedded CPython runtime when a compatible 3.13.x patch release fixes CVE-2026-4360, then retire this statement. This statement is pinned to the interpreter versions listed in subcomponents, so a future patch bump makes it inert rather than silently over-broad. Re-review if shipped agent code adds any tarfile.extract() or extractall() call, or if dateutil.zoneinfo.rebuild gains a caller and zic is added to the image.", + "timestamp": "2026-09-06T11:12:13Z" }, { "vulnerability": { @@ -969,7 +988,155 @@ "impact_statement": "CVE-2026-53489 affects only github.com/containerd/containerd/v2 versions in the 2.1, 2.2, and 2.3 release lines. The agent binary links github.com/containerd/containerd v1.7.33, whose Go module path does not contain the /v2 major-version suffix. Go major versions two and later use distinct module paths, and the affected /v2 component is not linked into this binary. The Grype finding results from matching the /v2 advisory to the major-v1 module after module-path normalization.", "action_statement": "Retire this statement when scanner matching no longer maps github.com/containerd/containerd/v2 advisories to the major-v1 module. Re-review if the agent starts linking github.com/containerd/containerd/v2 in an affected release line.", "timestamp": "2026-07-21T11:16:37Z" + }, + { + "vulnerability": { + "name": "CVE-2007-5894" + }, + "products": [ + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=quay.io/stackstate/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=registry.rancher.com/suse-observability/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + } + ], + "status": "not_affected", + "justification": "component_not_present", + "impact_statement": "CVE-2007-5894 is an uninitialised length variable in the reply() function of ftpd.c in the gssftp FTP daemon distributed with MIT Kerberos 5. The vulnerable code is that daemon's, not the Kerberos libraries'. The omnibus build installs only Kerberos libraries into this image - libkrb5.so.3.3, libgssapi_krb5.so.2.2, libk5crypto.so.3.1, libgssrpc.so.4.2 and libkrb5support - and builds none of the krb5 applications. A filesystem search of both published architectures finds no ftpd, gssftp, ftp, telnetd, telnet, kadmind, krb5kdc or kpropd binary, so the affected program is not present in the image; the finding arises only because the scanner infers the krb5 version from a shared library. NVD additionally records a vendor dispute: the length variable is only uninitialised when auth_type is neither KERBEROS_V4 nor GSSAPI, a condition the vendor states cannot occur in unmodified source.", + "action_statement": "This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward. Re-review if the image ever ships the gssftp applications or any other krb5 server program.", + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered.", + "timestamp": "2026-09-06T11:12:13Z" + }, + { + "vulnerability": { + "name": "CVE-2007-3149" + }, + "products": [ + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=quay.io/stackstate/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=registry.rancher.com/suse-observability/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + } + ], + "status": "not_affected", + "justification": "component_not_present", + "impact_statement": "CVE-2007-3149 is a flaw in sudo when linked against MIT Kerberos 5: sudo fails to check whether the invoking user can currently authenticate to Kerberos, so certain KRB5_ environment settings let a local user who already has sudo access escalate in a way sudo's model did not intend. The vulnerable code is sudo's, not the Kerberos libraries'. This image ships no sudo binary on either published architecture and sudo is not on PATH, so the affected component is absent and the described attack has no code to execute; the finding arises only because the scanner attributes the CVE to the detected krb5 version. The container also runs as USER 1000:1000 with no setuid sudo present. NVD records a dispute of the issue on the grounds that the attacker must already be able to log in and use sudo.", + "action_statement": "This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward. Re-review if sudo is ever added to the image.", + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered.", + "timestamp": "2026-09-06T11:12:13Z" + }, + { + "vulnerability": { + "name": "CVE-2026-40355" + }, + "products": [ + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=quay.io/stackstate/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=registry.rancher.com/suse-observability/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + } + ], + "status": "not_affected", + "justification": "vulnerable_code_not_in_execute_path", + "impact_statement": "CVE-2026-40355 is a NULL pointer dereference in parse_nego_message. NVD states it is triggerable only if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. Both preconditions the advisory names are unmet in this image, on both published architectures. (1) No GSS mechanism configuration exists: /etc/gss is absent, no mech or mech.d file exists anywhere in the filesystem, and no GSS_MECH_CONFIG or KRB5_ variable is set in the image configuration, so no NegoEx mechanism can be registered and the NegoEx message parsers are never entered. (2) Nothing shipped acts as a GSSAPI acceptor. Resolving the gss_accept_sec_context symbol across every shipped ELF object shows it defined only by embedded/lib/libgssapi_krb5.so.2.2 and left undefined (imported) only by embedded/lib/libgssrpc.so.4.2, the RPC library whose server programs kadmind and krb5kdc are not shipped; no executable or other library in the image imports it. The only source-level reference is pyspnego's spnego/_context.py, whose GSSAPI backend is not installed: gssapi, krb5, kerberos and winkerberos are all absent from site-packages and spnego._gss.HAS_GSSAPI evaluates to False in the running image. The agent uses Kerberos as an initiator only, and exposes just 8125/udp and 8126/tcp.", + "action_statement": "Re-review if any of these stops holding: an /etc/gss mech configuration is added to the image or mounted into the container, GSS_MECH_CONFIG is set, the gssapi, krb5 or kerberos Python bindings are added (which would enable pyspnego's GSSAPI backend), or shipped code begins acting as a GSSAPI acceptor. This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward; retire it once the embedded krb5 reaches 1.22.3 or later, which carries the upstream fix.", + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. NVD scores this CVSS 3.1 5.9 (MEDIUM, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, availability-only); Grype reports it as High from a different severity source.", + "timestamp": "2026-09-06T11:12:13Z" + }, + { + "vulnerability": { + "name": "CVE-2026-40356" + }, + "products": [ + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=quay.io/stackstate/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=registry.rancher.com/suse-observability/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/krb5@1.21.3" + } + ] + } + ], + "status": "not_affected", + "justification": "vulnerable_code_not_in_execute_path", + "impact_statement": "CVE-2026-40356 is an integer underflow and resultant out-of-bounds read in parse_message. NVD states it is triggerable only if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. Both preconditions the advisory names are unmet in this image, on both published architectures. (1) No GSS mechanism configuration exists: /etc/gss is absent, no mech or mech.d file exists anywhere in the filesystem, and no GSS_MECH_CONFIG or KRB5_ variable is set in the image configuration, so no NegoEx mechanism can be registered and the NegoEx message parsers are never entered. (2) Nothing shipped acts as a GSSAPI acceptor. Resolving the gss_accept_sec_context symbol across every shipped ELF object shows it defined only by embedded/lib/libgssapi_krb5.so.2.2 and left undefined (imported) only by embedded/lib/libgssrpc.so.4.2, the RPC library whose server programs kadmind and krb5kdc are not shipped; no executable or other library in the image imports it. The only source-level reference is pyspnego's spnego/_context.py, whose GSSAPI backend is not installed: gssapi, krb5, kerberos and winkerberos are all absent from site-packages and spnego._gss.HAS_GSSAPI evaluates to False in the running image. The agent uses Kerberos as an initiator only, and exposes just 8125/udp and 8126/tcp.", + "action_statement": "Re-review if any of these stops holding: an /etc/gss mech configuration is added to the image or mounted into the container, GSS_MECH_CONFIG is set, the gssapi, krb5 or kerberos Python bindings are added (which would enable pyspnego's GSSAPI backend), or shipped code begins acting as a GSSAPI acceptor. This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward; retire it once the embedded krb5 reaches 1.22.3 or later, which carries the upstream fix.", + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. NVD scores this CVSS 3.1 5.9 (MEDIUM, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, availability-only); Grype reports it as High from a different severity source.", + "timestamp": "2026-09-06T11:12:13Z" } ], - "timestamp": "2026-07-21T11:16:37Z" + "timestamp": "2026-09-06T11:12:13Z" } From 44419e79299cfb8c994321fec15b77537f0080ec Mon Sep 17 00:00:00 2001 From: "SUSE Observability AI (POC)" Date: Sun, 6 Sep 2026 14:48:13 +0000 Subject: [PATCH 2/2] Withdraw the CVE-2026-4360 reachability claim for the shipped 3.13.15 Review found the previous head asserted non-reachability for CVE-2026-4360 against the interpreter the image actually ships, and stated that upstream listed no fixed release. Both were wrong, and a fix outranks a suppression. The PSF CNA record marks CPython 3.13.0 up to but not including 3.13.15 as affected, so 3.13.15 is the 3.13-series release carrying the fix. The fix passes filter_function through to TarFile._extract_one() so the extraction filter reaches hardlink members; it landed on the 3.13 branch in python/cpython PR 152610, whose merge commit eee3ddf0 is an ancestor of tag v3.13.15. Confirmed in the artifact rather than inferred from a version string: the shipped interpreter reports 3.13.15 and the source of TarFile.extract contains the patched call. So pkg:generic/python@3.13.15 moves to its own statement with status fixed and that evidence. The reachability statement stays, scoped to pkg:generic/python@3.13.13, which the same record does place inside the affected range. Checked CVE-2025-15367 for the same error: its CNA record marks everything below 3.15.0a6 affected, so the shipped 3.13.15 is genuinely still affected and that statement's pin is correct as written. Also corrects the krb5 severity attribution. The notes credited 5.9 MEDIUM to NVD; NVD supplies its own primary 7.5 HIGH (AC:L) and the MITRE CNA supplies the secondary 5.9 MEDIUM (AC:H). Grype's High is consistent with the NVD primary rather than an outlier, so the notes no longer lean on low severity - these suppressions rest on the reachability evidence alone. Grype on ff38da51 is unchanged at 7 active / 9 ignored on both published architectures, with CVE-2026-4360 now suppressed via vex-status fixed matching python@3.13.15. Refs #38, #34 --- index.json | 2 +- .../stackstate-k8s-agent/scan.openvex.json | 71 +++++++++++++------ 2 files changed, 51 insertions(+), 22 deletions(-) diff --git a/index.json b/index.json index e6b6808..1967143 100644 --- a/index.json +++ b/index.json @@ -1,5 +1,5 @@ { - "updated_at": "2026-09-06T11:13:42Z", + "updated_at": "2026-09-06T14:44:41Z", "packages": [ { "id": "pkg:golang/github.com/containerd/containerd", diff --git a/pkg/oci/stackstate-k8s-agent/scan.openvex.json b/pkg/oci/stackstate-k8s-agent/scan.openvex.json index 3248b01..a337048 100644 --- a/pkg/oci/stackstate-k8s-agent/scan.openvex.json +++ b/pkg/oci/stackstate-k8s-agent/scan.openvex.json @@ -2,7 +2,7 @@ "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://github.com/StackVista/vexhub/pkg/oci/stackstate-k8s-agent/CVE-2026-6100", "author": "SUSE Observability Security Team", - "version": 3, + "version": 4, "statements": [ { "vulnerability": { @@ -215,8 +215,8 @@ "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2025-15367 is in the POP3._putcmd sink of the CPython standard library module Lib/poplib.py. The image embeds a full CPython interpreter under /opt/stackstate-agent/embedded/, so poplib.py is present on disk, but no shipped first-party code reaches it. A recursive search of the whole shipped tree (/opt/stackstate-agent, including every stackstate_checks integration in site-packages, python-scripts/ and /etc/stackstate-agent) for the tokens poplib and POP3 returns exactly one hit, embedded/lib/python3.13/pydoc_data/module_docs.py, which is inert documentation data rather than executable code; there is no import of poplib, no POP3 object construction and no POP3 session anywhere in shipped code. /etc/stackstate-agent/checks.d is empty, so no additional check code is layered in at build time. The interpreter is invoked only by the agent's rtloader check loader to run the bundled integrations, none of which exercise poplib. The image exposes only 8125/udp (DogStatsD) and 8126/tcp (trace-agent) and no POP3 port, and CVSS PR:H means an attacker would additionally need authenticated control of POP3 command arguments - a surface this image does not present. The container runs as USER 1000:1000.", - "status_notes": "Re-verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521). The embedded interpreter now reports itself as 3.13.15 (sys.version probed in the running image) and Grype reports the finding against pkg:generic/python@3.13.15, so pkg:generic/python@3.13.15 is added to subcomponents; the previously listed 3.13.13 and 3.13.14 pins are retained for images still in support. The reachability premise - no shipped code referencing poplib or POP3 - was re-established on both architectures and is unchanged by the interpreter patch bump.", - "timestamp": "2026-09-06T11:12:13Z", + "status_notes": "Re-verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521). The embedded interpreter now reports itself as 3.13.15 (sys.version probed in the running image) and Grype reports the finding against pkg:generic/python@3.13.15, so pkg:generic/python@3.13.15 is added to subcomponents; the previously listed 3.13.13 and 3.13.14 pins are retained for images still in support. The reachability premise - no shipped code referencing poplib or POP3 - was re-established on both architectures and is unchanged by the interpreter patch bump. Checked against the vendor record on 2026-09-06 for the same error corrected in the CVE-2026-4360 statement: the PSF CNA record for CVE-2025-15367 lists CPython from 0 up to but not including 3.15.0a6 as affected, so the shipped 3.13.15 is inside the affected range and this remains a reachability statement rather than a fix argument. 3.15.0a6 is an alpha of a future minor line and is not a compatible upgrade for the 3.13 series.", + "timestamp": "2026-09-06T14:45:00Z", "action_statement": "This statement is pinned to the interpreter versions listed in subcomponents, so a future CPython patch bump makes it inert rather than silently over-broad; extend subcomponents only after re-confirming that no shipped code references poplib or POP3. Re-review if any agent check, integration or helper script begins opening a POP3 session." }, { @@ -809,9 +809,6 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" - }, - { - "@id": "pkg:generic/python@3.13.15" } ] }, @@ -820,9 +817,6 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" - }, - { - "@id": "pkg:generic/python@3.13.15" } ] }, @@ -831,19 +825,16 @@ "subcomponents": [ { "@id": "pkg:generic/python@3.13.13" - }, - { - "@id": "pkg:generic/python@3.13.15" } ] } ], "status": "not_affected", - "status_notes": "Re-verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521). The embedded interpreter now reports 3.13.15, and Grype reports the finding against pkg:generic/python@3.13.15, so that PURL is added to subcomponents. The rationale was re-derived from the current image rather than carried over: the previously cited bpftool extraction path is no longer shipped, and the surviving argument is that the shipped tree contains no first-party tarfile.extract() call. Upstream still lists no fixed CPython release for this advisory.", + "status_notes": "Corrected 2026-09-06 after review. At head 9124b60 this statement also listed pkg:generic/python@3.13.15, asserting non-reachability for the interpreter the image actually ships and stating that upstream listed no fixed release. Both were wrong: the PSF CNA record for CVE-2026-4360 marks CPython 3.13.0 up to but not including 3.13.15 as affected, so 3.13.15 is the 3.13-series release carrying the fix. pkg:generic/python@3.13.15 has therefore been removed from this statement and is covered by a separate statement with status fixed and direct vendor-fix evidence. What remains here is scoped to pkg:generic/python@3.13.13, which the same CNA record does place inside the affected range, for images still in support. The reachability evidence was re-derived against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521) rather than carried over, because the previously recorded bpftool rationale referenced a path this image no longer ships.", "justification": "vulnerable_code_not_in_execute_path", - "impact_statement": "CVE-2026-4360 affects hardlink handling in tarfile.extract(). No shipped first-party code in this image calls it. A recursive search of the whole shipped tree for tarfile.extract / extractall, excluding the CPython standard library and the packaging tooling (pip, setuptools, wheel, pkg_resources, build, virtualenv), leaves exactly one tarfile.extract() call on both published architectures: site-packages/dateutil/zoneinfo/rebuild.py:24. That function is dateutil's maintenance utility for regenerating its own bundled zoneinfo tarball. It is unreachable here for three independent reasons: nothing in the shipped tree imports or calls dateutil.zoneinfo.rebuild (the rebuild( matches elsewhere are unrelated methods on dateutil.rrule's internal iterinfo class and on pydantic schema objects); it requires the caller to pass an explicit IANA tz tarball path plus a zonegroups member list, and no caller exists; and it shells out to the zic compiler via subprocess.check_call, which is absent from both architectures, so it would fail before extraction completed. The only other archive extraction in the shipped tree, pyproject_hooks/_in_process/_in_process.py:241, is zipfile.extractall and not tarfile. pynag's SshConfig parser touches tar but uses extractfile() and addfile(), which return file objects and never create filesystem links, so they do not enter the vulnerable hardlink branch; SshConfig is only re-exported by pynag.Parsers and is never instantiated by shipped code, and would additionally require an operator-configured paramiko SSH connection. The bpftool extraction path cited when this statement was first written is not present in this image at all - bpftool appears nowhere in either architecture's filesystem - so the conclusion now rests on there being no first-party tarfile.extract() call rather than on that path filtering hardlinks.", - "action_statement": "Upgrade the embedded CPython runtime when a compatible 3.13.x patch release fixes CVE-2026-4360, then retire this statement. This statement is pinned to the interpreter versions listed in subcomponents, so a future patch bump makes it inert rather than silently over-broad. Re-review if shipped agent code adds any tarfile.extract() or extractall() call, or if dateutil.zoneinfo.rebuild gains a caller and zic is added to the image.", - "timestamp": "2026-09-06T11:12:13Z" + "impact_statement": "CVE-2026-4360 affects hardlink handling in tarfile.extract(). This statement covers only the CPython versions listed in subcomponents, which the PSF CNA record does place inside the affected range (CPython 3.13.0 up to but not including 3.13.15); the 3.13.15 build the image now ships carries the vendor fix and is covered by a separate statement with status fixed. For the versions covered here the defect is present but unreachable: no shipped first-party code calls tarfile.extract(). A recursive search of the whole shipped tree for tarfile.extract / extractall, excluding the CPython standard library and the packaging tooling (pip, setuptools, wheel, pkg_resources, build, virtualenv), leaves exactly one tarfile.extract() call on both published architectures: site-packages/dateutil/zoneinfo/rebuild.py:24. That function is dateutil's maintenance utility for regenerating its own bundled zoneinfo tarball. It is unreachable for three independent reasons: nothing in the shipped tree imports or calls dateutil.zoneinfo.rebuild (the rebuild( matches elsewhere are unrelated methods on dateutil.rrule's internal iterinfo class and on pydantic schema objects); it requires the caller to pass an explicit IANA tz tarball path plus a zonegroups member list, and no caller exists; and it shells out to the zic compiler via subprocess.check_call, which is absent from both architectures, so it would fail before extraction completed. The only other archive extraction in the shipped tree, pyproject_hooks/_in_process/_in_process.py:241, is zipfile.extractall and not tarfile. pynag's SshConfig parser touches tar but uses extractfile() and addfile(), which return file objects and never create filesystem links, so they do not enter the vulnerable hardlink branch; SshConfig is only re-exported by pynag.Parsers and is never instantiated by shipped code, and would additionally require an operator-configured paramiko SSH connection. The bpftool extraction path cited when this statement was first written is not present in this image at all - bpftool appears nowhere in either architecture's filesystem - so the conclusion rests on there being no first-party tarfile.extract() call rather than on that path filtering hardlinks.", + "action_statement": "The vendor fix is in CPython 3.13.15 and the image already ships it, so no upgrade action remains for current builds; see the separate fixed statement for pkg:generic/python@3.13.15. Retire this statement once no supported image ships a CPython older than 3.13.15. Re-review if shipped agent code adds any tarfile.extract() or extractall() call, or if dateutil.zoneinfo.rebuild gains a caller and zic is added to the image.", + "timestamp": "2026-09-06T14:45:00Z" }, { "vulnerability": { @@ -1097,8 +1088,8 @@ "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-40355 is a NULL pointer dereference in parse_nego_message. NVD states it is triggerable only if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. Both preconditions the advisory names are unmet in this image, on both published architectures. (1) No GSS mechanism configuration exists: /etc/gss is absent, no mech or mech.d file exists anywhere in the filesystem, and no GSS_MECH_CONFIG or KRB5_ variable is set in the image configuration, so no NegoEx mechanism can be registered and the NegoEx message parsers are never entered. (2) Nothing shipped acts as a GSSAPI acceptor. Resolving the gss_accept_sec_context symbol across every shipped ELF object shows it defined only by embedded/lib/libgssapi_krb5.so.2.2 and left undefined (imported) only by embedded/lib/libgssrpc.so.4.2, the RPC library whose server programs kadmind and krb5kdc are not shipped; no executable or other library in the image imports it. The only source-level reference is pyspnego's spnego/_context.py, whose GSSAPI backend is not installed: gssapi, krb5, kerberos and winkerberos are all absent from site-packages and spnego._gss.HAS_GSSAPI evaluates to False in the running image. The agent uses Kerberos as an initiator only, and exposes just 8125/udp and 8126/tcp.", "action_statement": "Re-review if any of these stops holding: an /etc/gss mech configuration is added to the image or mounted into the container, GSS_MECH_CONFIG is set, the gssapi, krb5 or kerberos Python bindings are added (which would enable pyspnego's GSSAPI backend), or shipped code begins acting as a GSSAPI acceptor. This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward; retire it once the embedded krb5 reaches 1.22.3 or later, which carries the upstream fix.", - "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. NVD scores this CVSS 3.1 5.9 (MEDIUM, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, availability-only); Grype reports it as High from a different severity source.", - "timestamp": "2026-09-06T11:12:13Z" + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. Severity attribution, corrected after review: NVD supplies its own primary CVSS 3.1 score of 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), while the MITRE CNA supplies a secondary CVSS 3.1 score of 5.9 MEDIUM with the same vector except AC:H. Both are availability-only (C:N/I:N/A:H) and differ only in attack complexity, and both bodies record the same affected range of 1.18 up to but not including 1.22.3. Grype's High rating is consistent with the NVD primary score rather than an outlier from an unrelated source, so this suppression rests on the reachability evidence above and not on the finding being low severity.", + "timestamp": "2026-09-06T14:45:00Z" }, { "vulnerability": { @@ -1134,9 +1125,47 @@ "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-40356 is an integer underflow and resultant out-of-bounds read in parse_message. NVD states it is triggerable only if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. Both preconditions the advisory names are unmet in this image, on both published architectures. (1) No GSS mechanism configuration exists: /etc/gss is absent, no mech or mech.d file exists anywhere in the filesystem, and no GSS_MECH_CONFIG or KRB5_ variable is set in the image configuration, so no NegoEx mechanism can be registered and the NegoEx message parsers are never entered. (2) Nothing shipped acts as a GSSAPI acceptor. Resolving the gss_accept_sec_context symbol across every shipped ELF object shows it defined only by embedded/lib/libgssapi_krb5.so.2.2 and left undefined (imported) only by embedded/lib/libgssrpc.so.4.2, the RPC library whose server programs kadmind and krb5kdc are not shipped; no executable or other library in the image imports it. The only source-level reference is pyspnego's spnego/_context.py, whose GSSAPI backend is not installed: gssapi, krb5, kerberos and winkerberos are all absent from site-packages and spnego._gss.HAS_GSSAPI evaluates to False in the running image. The agent uses Kerberos as an initiator only, and exposes just 8125/udp and 8126/tcp.", "action_statement": "Re-review if any of these stops holding: an /etc/gss mech configuration is added to the image or mounted into the container, GSS_MECH_CONFIG is set, the gssapi, krb5 or kerberos Python bindings are added (which would enable pyspnego's GSSAPI backend), or shipped code begins acting as a GSSAPI acceptor. This statement is pinned to pkg:generic/krb5@1.21.3, so a krb5 bump makes it inert rather than silently carrying forward; retire it once the embedded krb5 reaches 1.22.3 or later, which carries the upstream fix.", - "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. NVD scores this CVSS 3.1 5.9 (MEDIUM, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, availability-only); Grype reports it as High from a different severity source.", - "timestamp": "2026-09-06T11:12:13Z" + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. Grype 0.117.0 with vulnerability database built 2026-09-06T06:27:35Z reports the finding against pkg:generic/krb5@1.21.3, detected from /opt/stackstate-agent/embedded/lib/libkrb5.so.3.3, with no fix version offered. krb5 1.21.3 is inside the affected range (NVD: affected from 1.18.0, fixed in 1.22.3). Upstream has not released 1.22.3 - the newest tag in krb5/krb5 is krb5-1.22.2-final, which is itself still inside the affected range - so no compatible upgrade exists and this is a reachability statement rather than a version argument. Severity attribution, corrected after review: NVD supplies its own primary CVSS 3.1 score of 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), while the MITRE CNA supplies a secondary CVSS 3.1 score of 5.9 MEDIUM with the same vector except AC:H. Both are availability-only (C:N/I:N/A:H) and differ only in attack complexity, and both bodies record the same affected range of 1.18 up to but not including 1.22.3. Grype's High rating is consistent with the NVD primary score rather than an outlier from an unrelated source, so this suppression rests on the reachability evidence above and not on the finding being low severity.", + "timestamp": "2026-09-06T14:45:00Z" + }, + { + "vulnerability": { + "name": "CVE-2026-4360", + "aliases": [ + "GHSA-gf2w-jqmq-fcm8" + ] + }, + "products": [ + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=quay.io/stackstate/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/python@3.13.15" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent?repository_url=registry.rancher.com/suse-observability/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/python@3.13.15" + } + ] + }, + { + "@id": "pkg:oci/stackstate-k8s-agent", + "subcomponents": [ + { + "@id": "pkg:generic/python@3.13.15" + } + ] + } + ], + "status": "fixed", + "impact_statement": "The CPython build this image ships contains the vendor fix for CVE-2026-4360. The PSF CNA record lists CPython 3.13.0 up to but not including 3.13.15 as affected, so 3.13.15 is the 3.13-series release that carries the fix. The fix passes filter_function through to TarFile._extract_one() in Lib/tarfile.py so that the extraction filter is applied to hardlink members; it reached the 3.13 branch in python/cpython PR 152610, whose merge commit eee3ddf0ca10283cc7fea724aae9cd8665f8d15e is an ancestor of tag v3.13.15 (the other commits the advisory lists are the 3.10, 3.11, 3.12, 3.14 and 3.15 backports and are not on this branch). This was confirmed in the shipped artifact rather than inferred from version strings: inside the running container /opt/stackstate-agent/embedded/bin/python3 reports 3.13.15, inspect.getsource(tarfile.TarFile.extract) contains the patched call self._extract_one(tarinfo, path, set_attrs, numeric_owner, filter_function=filter_function), and TarFile._extract_one carries the filter_function=None parameter the fix introduced. The Grype finding is a version-matching false positive: its data source records no fixed version for this advisory, so every 3.13.x build matches an open-ended affected range.", + "status_notes": "Verified 2026-09-06 against quay.io/stackstate/stackstate-k8s-agent:ff38da51 (index digest sha256:4ebe6280d7c28e07ab1447e1497fbe855ee1229e9ef38b3e9945145cb0367616) on both published architectures - linux/amd64 (sha256:72287f0a984855dd974821b0d0c8b09111f7f6a5910e3df6b1797b643924184d) and linux/arm64 (sha256:d9d07d885b8da704a0cf177ed7aabcb9d081e4b5e2b062859eaa33f5b018d521), which report an identical finding set. This statement supersedes, for pkg:generic/python@3.13.15 only, the reachability assertion that appeared at head 9124b60; that assertion was withdrawn because the vendor fix is present in the shipped interpreter, and a fix is preferred over a suppression. The reachability statement for CVE-2026-4360 is retained separately for pkg:generic/python@3.13.13, which the PSF CNA record does place inside the affected range. Retire this statement once the scanner's data records a fixed version for CVE-2026-4360, at which point the finding stops being reported on its own.", + "timestamp": "2026-09-06T14:45:00Z" } ], - "timestamp": "2026-09-06T11:12:13Z" + "timestamp": "2026-09-06T14:45:00Z" }