Data & Insight

Expanding Container and Orchestration Coverage: 7 New Products Now Supported

RobertUpdated Apr 25, 20260 min read
Container & orchestration vulnerability dashboard on a dark, terminal-style interface. Seven cards show components and their CVE counts with risk levels: runc (134, high), Docker Engine (212, high), containerd (167, medium), Kubernetes API Server (178, high), kubelet (153, medium), Helm (89, low), and Argo CD (64, low). A summary row at the bottom reads “7 new products,” “27 total coverage,” and “1 API call,” with Attestd branding centered below.

Expanding Container and Orchestration Coverage: 7 New Products Now Supported#

Attestd's second Q2 coverage expansion is live. Seven container and orchestration products are now supported via the /v1/check endpoint, covering the runtime layer of most production infrastructure stacks.

New products: runc, Docker Engine, containerd, Kubernetes API Server, kubelet, Helm, Argo CD.

One additional candidate, Podman, was evaluated and cut. NVD CVEs reference Podman in text but the CPE match criteria do not consistently use podman:podman, so the CPE gate drops all version-ranged entries. Nothing survives synthesis with a usable sentinel rate. The cut is documented for re-evaluation as NVD coverage improves.

Total supported products: 27.

What the data shows#

runc#

runc is the low-level container runtime that both Docker Engine and containerd depend on. Container escape vulnerabilities live here more than anywhere else in the stack, which is why it was added alongside the higher-level runtimes rather than treated as an afterthought.

Three CVEs of note in the data:

CVE-2019-5736 allows an attacker with access to a runc container to overwrite the host runc binary via /proc/self/exe, enabling container escape. CVE-2021-30465 is a symlink race that permits access to host mounts. CVE-2024-21626 is a file descriptor leak that enables host breakout and is listed on the CISA KEV catalog as actively exploited.

curl "https://api.attestd.io/v1/check?product=runc&version=1.0.0" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq .

{
  "product": "runc",
  "version": "1.0.0",
  "supported": true,
  "risk_state": "high",
  "remote_exploitable": true,
  "patch_available": true,
  "fixed_version": "1.0.0-rc95 or later",
  "cve_ids": ["CVE-2019-5736", "CVE-2021-30465", "CVE-2024-21626"]
}

Version 1.2.8 returns risk_state: none.

Docker Engine#

Docker Engine required dual CPE namespace handling. Pre-20.x CVEs are catalogued under docker:docker. Post-20.x CVEs use docker:docker_engine. Attestd queries both and deduplicates on CVE ID, the same pattern used for nginx and Redis.

CVE-2024-41110 is the most significant recent finding: an authorization plugin bypass in versions before the 27.x patch that allows privilege escalation. CVE-2020-27534 affects the 19.x train via information disclosure through docker cp.

containerd#

Three CVEs of note across the containerd data: CVE-2021-32760 (file permission misconfiguration on container root), CVE-2022-23648 (host filesystem leak via volume mount race), and CVE-2023-25173 (supplemental groups retained after exec, enabling privilege escalation, CVSS 7.8). The most recent finding, CVE-2024-40635, affects the 1.6 and 1.7 trains and is fixed at 1.6.38 and 1.7.29 respectively.

curl "https://api.attestd.io/v1/check?product=containerd&version=1.5.0" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq .

Version 1.5.0 returns risk_state: high. Version 1.7.29 returns risk_state: none.

Kubernetes API Server and kubelet#

Both sit under the kubernetes:kubernetes CPE in NVD. Attestd differentiates them by running keyword-scoped NVD queries per product using keywordSearch with keywordExactMatch, so each product only ingests CVEs that explicitly mention that component.

The risk classification for the current data is elevated rather than high. CVE-2022-3294 is the primary driver: it allows node address type bypass enabling man-in-the-middle, but it requires authentication. The Attestd classifier maps remote-exploitable-but-authentication-required to elevated, not high. CVE-2023-2431 affects kubelet specifically through 1.27.x via hostPath volume bypass on Windows nodes.

curl "https://api.attestd.io/v1/check?product=kube_apiserver&version=1.24.0" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq .

{
  "product": "kube_apiserver",
  "version": "1.24.0",
  "supported": true,
  "risk_state": "elevated",
  "remote_exploitable": true,
  "authentication_required": true,
  "fixed_version": "1.24.8",
  "cve_ids": ["CVE-2022-3294"]
}

Helm#

Helm has a real CVE history across its 3.x train. CVE-2022-23524 is a ReDoS in chart parsing (CVSS 7.5, fixed in 3.10.3). CVE-2024-25620 covers dependency confusion in chart repository handling (fixed 3.14.2). CVE-2025-32386 and CVE-2025-32387 are remote-exploitable issues in the 3.x train fixed in 3.17.3.

One noteworthy data point: CVE-2026-35206 affects all currently released Helm versions through 3.20.1 with no public patch train yet. This means even current Helm versions return a non-zero risk state. Version 3.18.5 returns risk_state: low rather than none. If you are querying Helm and expecting a clean result on a recent version, this is why.

Argo CD#

Argo CD passed eligibility with a solid CVE history. CVE-2022-24348 is a path traversal in the repository server that is unauthenticated and reaches CVSS 7.7. CVE-2022-29165 is an auth bypass via JWT forging. More recent findings, CVE-2025-47933 and CVE-2025-59531, affect the 2.12.x and 2.13.x trains and are fixed at 2.14.20.

curl "https://api.attestd.io/v1/check?product=argo_cd&version=2.1.8" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq .

{
  "product": "argo_cd",
  "version": "2.1.8",
  "supported": true,
  "risk_state": "high",
  "remote_exploitable": true,
  "authentication_required": false,
  "patch_available": true,
  "fixed_version": "2.8.13",
  "cve_ids": ["CVE-2022-24348", "CVE-2022-1025", "CVE-2022-29165"]
}

Checking your container stack#

All seven products are available via the standard /v1/check endpoint. The Python SDK works the same way for all new products:

from attestd import Client
 
client = Client(api_key="YOUR_API_KEY")
 
container_stack = {
    "runc": "1.0.0",
    "docker_engine": "19.03.0",
    "containerd": "1.5.0",
    "kube_apiserver": "1.24.0",
    "kubelet": "1.24.0",
    "helm": "3.9.0",
    "argo_cd": "2.1.8",
}
 
for product, version in container_stack.items():
    result = client.check(product, version)
    if result.risk_state in ("critical", "high", "elevated"):
        print(f"{product} {version}: {result.risk_state}")
        if result.fixed_version:
            print(f"  Fixed in: {result.fixed_version}")

Technical decisions#

runc CPE namespace: The correct CPE is linuxfoundation:runc, not opencontainers:runc. The OpenContainers namespace has no NVD entries. This is documented for future reference.

Docker dual CPE: Pre-20.x uses docker:docker, post-20.x uses docker:docker_engine. Attestd queries both and deduplicates on CVE ID.

Kubernetes shared CPE: Both kube-apiserver and kubelet use kubernetes:kubernetes in NVD. Differentiated at ingestion time via keyword-scoped queries with exact match.

Helm risk floor: CVE-2026-35206 affects all current Helm versions. No clean version exists in current NVD data. risk_state: low is the floor for recent Helm versions, not none.

Podman exclusion: 100% sentinel rate. CPE match criteria in NVD do not consistently use podman:podman across CVE entries. Nothing survives synthesis with usable version ranges. Documented in the excluded products registry for re-evaluation.

What is next#

Batch 3 covers web and proxy infrastructure: HAProxy, Traefik, Varnish, Apache Tomcat, Jetty, Caddy, and Squid. The LangChain integration guide publishes alongside that expansion.

Get an API key at api.attestd.io/portal/login. Free tier, 1,000 calls a month, no credit card required.