Loading story…
The containerd project released patches for five vulnerabilities in its CRI and image-handling components, including three critical flaws tracked as CVE-2026-50195, CVE-2026-53488, and CVE-2026-53492, alongside CVE-2026-53489 and CVE-2026-47262. According to the project’s disclosure and an AWS security bulletin, the bugs could let attackers poison a node’s local image cache with crafted checkpoint images, pass unvalidated image labels that may lead to arbitrary host command execution through label-consuming plugins, and abuse untrusted CDI annotations during checkpoint restore to bypass Kubernetes device allocation controls.
The remaining issues include a high-severity arbitrary host file-read path through kubectl logs by restoring a symlinked container.log from a checkpoint image, and a moderate denial-of-service flaw that can exhaust memory and crash the containerd process. Fixes are available in containerd 2.3.2, 2.2.5, and 2.1.9 for all five vulnerabilities, while versions 2.0.10 and 1.7.33 address CVE-2026-53488 and CVE-2026-47262; maintainers urged immediate upgrades and said containers restored from untrusted checkpoints may need to be recreated to remove smuggled CDI configuration tied to CVE-2026-53492.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
1 event from the most recent confirmed update back to the earliest known activity.
On June 18, 2026, the containerd project announced patch releases addressing CVE-2026-50195, CVE-2026-53488, CVE-2026-53492, CVE-2026-53489, and CVE-2026-47262. Fixed versions included 2.3.2, 2.2.5, and 2.1.9 for all five issues, with 2.0.10 and 1.7.33 fixing CVE-2026-53488 and CVE-2026-47262.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcecvefeed.io
Open sourcecvefeed.io
Open sourceseclists.org
Open sourceaws.amazon.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Security researchers have disclosed three critical vulnerabilities in the runC container runtime, which is widely used in platforms such as Docker and Kubernetes. The flaws, identified as CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, arise from logic and race-condition errors in runC's handling of temporary bind mounts, symbolic links, and certain write operations. Attackers can exploit these weaknesses to break container isolation, potentially gaining write access to sensitive host system files and kernel interfaces such as `/proc/sys/kernel/core_pattern` or `/proc/sysrq-trigger`, leading to full container escapes and even host-level compromise. The vulnerabilities allow attackers to abuse masked paths, console bind-mounts, and redirected writes, bypassing standard hardening and isolation controls. Exploitation requires either custom mount configurations or the use of untrusted container images, but the risk is significant for orchestrated environments like Docker and Kubernetes. Security advisories from both the runC project and the U.S. National Vulnerability Database urge immediate updates to patched versions or the application of provided patches to mitigate these threats. The vulnerabilities highlight the importance of robust container runtime security and the potential impact of logic flaws in core infrastructure components.
Jun 29, 2026
Researchers disclosed three new `runc` vulnerabilities — `CVE-2025-31133`, `CVE-2025-52565`, and `CVE-2025-52881` — that can let attackers break container isolation and gain root access on the host systems running Docker, Kubernetes, and other platforms built on `runc`. The flaws abuse race conditions, mount manipulation, and redirected writes into `procfs`, including paths such as `/proc/sys/kernel/core_pattern` and `/proc/sysrq-trigger`, to turn container access into host-level impact. Sysdig reported that exploitation requires the ability to launch containers with custom mount configurations, making malicious or untrusted container images and Dockerfiles a likely delivery path, and said no active exploitation had been observed at disclosure. The new issues echo the earlier `CVE-2019-5736` `runC` escape, which allowed container root users to overwrite the host `runC` binary via `/proc/self/exe` and `/proc/[pid]/exe` handling and then execute code as root on the host. That earlier flaw affected Docker by default and also impacted LXC in some configurations, leading maintainers to harden `runC` by re-executing from a sealed in-memory copy created with `memfd_create()`. For the newly disclosed bugs, fixed releases are `runc` `1.2.8`, `1.3.3`, and `1.4.0-rc.3` or later, and defenders were advised to monitor for suspicious symlink creation and other attempts to target sensitive `procfs` entries from inside containers.
Jun 29, 2026
Docker disclosed a high-severity Docker Engine vulnerability, **CVE-2026-34040** (`CVSS 8.8`), that allows attackers to bypass authorization plugins and perform actions that should be blocked. The flaw stems from an incomplete fix for **CVE-2024-41110** and is triggered when a specially crafted oversized Docker API request causes the request body to be dropped before inspection by an AuthZ plugin. In affected environments, the plugin may approve container operations it would otherwise deny, opening a path to unauthorized privileged actions and potential host compromise. Researchers said an attacker with Docker API access could exploit the bug by padding a container-creation request beyond **1 MB** to launch a privileged container with access to the host filesystem, exposing sensitive assets such as **AWS credentials**, **SSH keys**, and **Kubernetes configurations**. The issue affects deployments that rely on authorization plugins inspecting request bodies, while environments not using those plugins are not impacted. Docker patched the vulnerability in **Docker Engine 29.3.1** and urged defenders to upgrade, restrict Docker API access, avoid AuthZ plugins that depend on request-body inspection, and use controls such as rootless mode, user namespace remapping, and least-privilege access to reduce risk.
Jul 23, 2026