CVE-2026-107446 in overlaybd
Summary
by MITRE • 10/08/2026
containerd overlaybd through 1.0.18 has a do_load_index (LSMT index loading) integer overflow (and resultant out-of-bounds heap access) for index_bytes, if an untrusted overlaybd blob from a registry is used in a scenario with multiple overlaybd-backed containers.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in containerd versions through 1.0.18 involves a critical integer overflow within the LSMT (Layered Snapshot Management Technology) index loading mechanism, specifically affecting the overlaybd storage driver implementation. This flaw manifests during the processing of index_bytes when an untrusted overlaybd blob is ingested from a remote registry into an environment running multiple containers backed by this specific storage type. The core technical failure lies in the arithmetic operation used to calculate memory allocation or buffer sizing for the LSMT index data structure. When the input parameters derived from the maliciously crafted blob result in values that exceed the maximum limit of the integer variable, a wrap-around occurs. This overflow causes the system to allocate significantly less memory than required for the subsequent copy operations, leading directly to an out-of-bounds heap access when the application attempts to write or read data beyond the allocated buffer boundaries.
From a technical perspective, this is classified as CWE-190 Integer Overflow or Wraparound which subsequently leads to CWE-787 Out-of-Bounds Write and potentially CWE-788 Out-of-Bounds Read depending on how the corrupted memory state is utilized by the runtime engine. The vulnerability exploits the trust model of container registries, assuming that blob metadata is benign. However, an attacker who can push a specially crafted overlaybd image to a registry accessible to the target environment can trigger this condition. Because containerd operates with elevated privileges relative to user-space containers and manages low-level storage drivers, exploiting this heap corruption allows for arbitrary memory read or write capabilities within the context of the containerd process. This breaks the isolation guarantees provided by the container runtime, as the attacker gains control over critical data structures that manage layer references and snapshot states.
The operational impact of this vulnerability is severe due to its potential for remote code execution and privilege escalation. By leveraging the out-of-bounds heap access, an adversary can corrupt adjacent memory regions containing function pointers or object metadata within the Go runtime environment managed by containerd. This corruption can be manipulated to redirect control flow, resulting in arbitrary code execution with the privileges of the containerd daemon process. In a multi-tenant Kubernetes cluster or similar orchestration platform where multiple overlaybd-backed containers are active, this vulnerability provides a reliable attack vector for lateral movement and escape from the container sandbox. The presence of multiple containers increases the likelihood of finding suitable heap layouts that facilitate successful exploitation, as memory fragmentation patterns vary across different processes and allocations.
Mitigation strategies must focus on immediate patching and architectural hardening. Organizations running affected versions should upgrade to a patched release of containerd where integer overflow checks have been implemented for index loading operations. Input validation mechanisms should be strengthened to ensure that all metadata extracted from registry blobs is rigorously checked against expected bounds before any memory allocation occurs. Additionally, deploying runtime security tools such as Falco or Sysdig can help detect anomalous behavior associated with heap corruption attempts, although prevention at the source remains the primary defense. Security teams should also audit their container registries to ensure that only trusted images are pulled and verify that no untrusted parties have push access to repositories containing overlaybd-compatible layers. Aligning these practices with MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter or T1203 Exploitation for Client Execution highlights the need for continuous monitoring of container runtime activities against known exploitation patterns associated with storage driver vulnerabilities.