CVE-2026-53488: containerd: label injection enables host RCE via CRI plugin

GHSA-xhf5-7wjv-pqxp HIGH
Published June 19, 2026
CISO Take

A vulnerability in containerd's CRI plugin allows Docker image LABEL instructions to propagate unvalidated into containers, where any installed plugin that acts on container labels can be weaponized to execute arbitrary commands on the underlying host. With 5,435 downstream dependents and containerd serving as the default runtime for Kubernetes, this flaw sits beneath virtually every containerized AI/ML workload — from inference servers and training pipelines to agentic AI systems. No public exploit is available and the vulnerability is not in CISA KEV, but independent discovery by both Anthropic Research and Google's GKE Security Team signals sustained attacker interest in this attack surface; a container-to-host escape is a high-value primitive for supply chain actors targeting AI GPU infrastructure. Upgrade containerd immediately to a patched release (1.7.33 / 2.0.10 / 2.1.9 / 2.2.5 / 2.3.2) and enforce image signing plus trusted-registry admission policies as interim controls.

Sources: GitHub Advisory NVD ATLAS

What is the risk?

High risk for AI/ML organizations running containerized workloads on Kubernetes or Docker. The vulnerability enables container-to-host escape — an adversary who can deliver a malicious container image via supply chain compromise, CI/CD infiltration, or a poisoned upstream base image gains host-level code execution on GPU nodes, threatening model weights, training data, secrets, and Kubernetes service account tokens enabling lateral movement. The absence of a public exploit and KEV listing moderates immediate urgency, but the 5,435 downstream dependents and high intrinsic value of AI infrastructure nodes (GPU compute, proprietary models, API credentials) elevate this above typical container CVEs. Organizations pulling unverified AI base images from public registries face disproportionate exposure.

How does the attack unfold?

Image Poisoning
Adversary crafts a container image with malicious LABEL directives embedded in the Dockerfile and pushes it to a registry accessible to the target — via a compromised upstream AI base image, typosquatted name, or CI/CD pipeline breach.
AML.T0010.004
Image Pull and Deployment
Target's ML pipeline or inference deployment pulls the malicious image; containerd's CRI plugin propagates the unvalidated labels from the image config to the running container without sanitization.
AML.T0011.001
Label-Triggered Host Escape
A containerd plugin installed in the environment that consumes container labels for privileged operations processes the malicious label value and executes an attacker-controlled command on the host.
AML.T0105
Host Compromise and Exfiltration
With host-level code execution on the GPU node, the adversary harvests model weights, API keys, Kubernetes service account tokens, and training datasets, then moves laterally within the cluster.
AML.T0050

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Anthropic Python go >= 1.7.0, < 1.7.33 1.7.33
3.6K 5.4K dependents Pushed 9d ago 94% patched ~1d to patch Full package profile →
Anthropic Python go >= 2.0.0, < 2.0.10 2.0.10
3.6K 5.4K dependents Pushed 9d ago 94% patched ~1d to patch Full package profile →

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

5 steps
  1. Upgrade containerd on all nodes immediately: v1.7.x → 1.7.33, v2.0.x → 2.0.10, v2.1.x → 2.1.9, v2.2.x → 2.2.5, v2.3.x → 2.3.2. Run containerd --version on every node to confirm version.

  2. Short-term workaround: restrict image pulls to trusted, internally mirrored registries via admission controllers (OPA Gatekeeper, Kyverno) and block unapproved external images.

  3. Implement and enforce image signing (Cosign/Sigstore) in CI/CD pipelines with signature verification at admission time.

  4. Audit installed containerd plugins in your environment for any that consume container labels in privileged operations — these are the proximate trigger component.

  5. Deploy runtime security monitoring (Falco, Tetragon) with rules alerting on unexpected process spawning from containerd-shim processes to detect exploitation attempts.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2 - AI system supply chain management
NIST AI RMF
GOVERN 1.1 - Policies and processes for AI risk management
OWASP LLM Top 10
LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-53488?

A vulnerability in containerd's CRI plugin allows Docker image LABEL instructions to propagate unvalidated into containers, where any installed plugin that acts on container labels can be weaponized to execute arbitrary commands on the underlying host. With 5,435 downstream dependents and containerd serving as the default runtime for Kubernetes, this flaw sits beneath virtually every containerized AI/ML workload — from inference servers and training pipelines to agentic AI systems. No public exploit is available and the vulnerability is not in CISA KEV, but independent discovery by both Anthropic Research and Google's GKE Security Team signals sustained attacker interest in this attack surface; a container-to-host escape is a high-value primitive for supply chain actors targeting AI GPU infrastructure. Upgrade containerd immediately to a patched release (1.7.33 / 2.0.10 / 2.1.9 / 2.2.5 / 2.3.2) and enforce image signing plus trusted-registry admission policies as interim controls.

Is CVE-2026-53488 actively exploited?

No confirmed active exploitation of CVE-2026-53488 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-53488?

1. Upgrade containerd on all nodes immediately: v1.7.x → 1.7.33, v2.0.x → 2.0.10, v2.1.x → 2.1.9, v2.2.x → 2.2.5, v2.3.x → 2.3.2. Run `containerd --version` on every node to confirm version. 2. Short-term workaround: restrict image pulls to trusted, internally mirrored registries via admission controllers (OPA Gatekeeper, Kyverno) and block unapproved external images. 3. Implement and enforce image signing (Cosign/Sigstore) in CI/CD pipelines with signature verification at admission time. 4. Audit installed containerd plugins in your environment for any that consume container labels in privileged operations — these are the proximate trigger component. 5. Deploy runtime security monitoring (Falco, Tetragon) with rules alerting on unexpected process spawning from containerd-shim processes to detect exploitation attempts.

What systems are affected by CVE-2026-53488?

This vulnerability affects the following AI/ML architecture patterns: Kubernetes AI inference clusters, Containerized ML training pipelines, MLOps platforms (Kubeflow, Argo, MLflow on Kubernetes), AI agent frameworks deployed in containers, RAG pipeline services, Model serving infrastructure.

What is the CVSS score for CVE-2026-53488?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Kubernetes AI inference clustersContainerized ML training pipelinesMLOps platforms (Kubeflow, Argo, MLflow on Kubernetes)AI agent frameworks deployed in containersRAG pipeline servicesModel serving infrastructure

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0010.004 Container Registry
AML.T0011.001 Malicious Package
AML.T0050 Command and Scripting Interpreter
AML.T0105 Escape to Host

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: GOVERN 1.1
OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

### Impact A bug was found in containerd where the CRI plugin propagates labels from an image config (`LABEL` instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. ### Patches This bug has been fixed in the following containerd versions: * 2.3.2 * 2.2.5 * 2.1.9 * 2.0.10 * 1.7.33 Users should update to these versions to resolve the issue. ### Workarounds Ensure that only trusted images are used. ### Credits The containerd project would like to thank Anthropic Research, in collaboration with Claude, the GKE Security Team using Gemini, and Robert Prast (@robertprast) for independently discovering and responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md). ### For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose) * Email us at [security@containerd.io](mailto:security@containerd.io) To report a security issue in containerd: * [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io)

Exploitation Scenario

An attacker targeting an AI organization's GPU inference cluster first confirms nodes run an unpatched containerd version via Kubernetes API reconnaissance or version disclosures in CI/CD pipeline logs. The attacker then crafts a malicious container image embedding LABEL directives designed to trigger command execution when processed by a containerd plugin installed in the target environment — for example, a logging, monitoring, or orchestration sidecar known to consume container labels for privileged operations. The poisoned image is injected via a compromised upstream AI base image (a popular CUDA or PyTorch base layer on Docker Hub), a typosquatted image name, or a CI/CD pipeline breach. When an automated ML training job or inference deployment pulls and starts the container, containerd's CRI plugin propagates the malicious labels without sanitization; the installed plugin processes them and spawns an attacker-controlled process on the host. The attacker then harvests GPU node credentials, model artifacts, and Kubernetes service account tokens to persist and move laterally across the cluster.

Weaknesses (CWE)

CWE-74 — Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'): The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.

  • [Requirements] Programming languages and supporting technologies might be chosen which are not subject to these issues.
  • [Implementation] Utilize an appropriate mix of allowlist and denylist parsing to filter control-plane syntax from all input.

Source: MITRE CWE corpus.

Timeline

Published
June 19, 2026
Last Modified
June 19, 2026
First Seen
June 19, 2026

Related Vulnerabilities