Loading story…
A high-severity vulnerability tracked as CVE-2026-50540 affects Kata Containers versions prior to 4.0.0, allowing a low-privileged attacker to trigger host code execution as root through the kata-runtime component. The issue stems from support for the pod annotation io.katacontainers.config_path, which let the runtime load an arbitrary host TOML configuration file without sufficient validation or restriction. If an attacker can place a file at a host-visible path, they can point Kata Containers to attacker-controlled settings and select a malicious hypervisor or virtio-fs daemon binary.
Kata Containers addressed the flaw by removing support for the config_path sandbox annotation override in a code change that deleted the annotation constant, helper logic, tests, and documentation tied to that behavior. The updated runtime now resolves configuration from the KATA_CONF_FILE environment variable, shimv2 create task options, and default runtime configuration paths instead. The vulnerability is associated with path traversal and improper input validation weaknesses and carries a CVSS v3.1 score vector of AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
GitHub security advisories received CVE-2026-50540 on August 7, 2026 for a Kata Containers vulnerability in `kata-runtime` that allowed arbitrary host TOML configuration loading via the `io.katacontainers.config_path` annotation. The issue affected versions prior to 4.0.0 and could lead to host code execution as root; the CVE record states it was fixed in version 4.0.0.
A Kata Containers code change removed support for the `io.katacontainers.config_path` pod sandbox annotation as a runtime configuration override across Go and Rust components, tests, and documentation. This change eliminated annotation-based loading of host TOML configuration files and updated configuration precedence to use `KATA_CONF_FILE`, shimv2 task options, and default paths.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map 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
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`.
Jul 1, 2026
CERT/CC and public reporting disclosed a critical vulnerability in **Terrarium**, the open-source Python sandbox developed by Cohere AI, that can allow arbitrary code execution and sandbox escape. Tracked as `CVE-2026-5752` and `VU#414811`, the flaw arises from JavaScript prototype chain traversal in the Pyodide WebAssembly environment, enabling an attacker with local access to execute code with **root privileges** in the host Node.js process without user interaction or special privileges. The vulnerability could let attackers access sensitive files, communicate with other services on the container network, and potentially escape the container entirely. Researcher Jeremy Brown is credited with discovering the issue, and reports indicate **Terrarium is no longer actively maintained**, making a vendor patch unlikely. Defenders are advised to disable user code submission where possible, restrict and segment network access, closely monitor container activity, use stronger container isolation and orchestration controls, deploy web application firewall protections where applicable, and keep supporting dependencies updated.
Jun 29, 2026