TOCTOU

CVE-2025-47290: The Containerd Chameleon – How a Sneaky Symlink Could Hijack Your Host!

Robert Morgan

Robert Morgan

— 8 min read

Hey everyone, and welcome to another deep dive into the fascinating, and sometimes frightening, world of cybersecurity! Today, we're dissecting CVE-2025-47290, a crafty vulnerability in containerd that could allow a specially designed container image to play hide-and-seek with your host's filesystem. Grab your detective hats; this one's a classic case of "now you see it, now you don't!"

TL;DR / Executive Summary

CVE-2025-47290 is a Time-of-Check to Time-of-Use (TOCTOU) vulnerability discovered in containerd v2.1.0. It allows a malicious container image, during the unpack process of an image pull, to potentially write files to arbitrary locations on the host filesystem. This could lead to data corruption, denial of service, or even pave the way for further host compromise. The vulnerability is rated High severity. The good news? It's specific to version 2.1.0 and has been patched in containerd v2.1.1. The primary mitigation is to upgrade immediately. If you can't, stick to trusted images and restrict image import permissions like your server depends on it (because it does!).

Introduction: The Unseen Guest in Your Container Hotel

Imagine your server is a bustling hotel, and containers are the guests in its many rooms. containerd is like the super-efficient hotel manager, handling guest check-ins (pulling images), room assignments (running containers), and ensuring everything runs smoothly. It's a core component in the Docker Engine, Kubernetes (via CRI), and many other container platforms. So, when this manager has a momentary lapse in judgment, it can have serious consequences for the entire hotel.

This particular vulnerability, CVE-2025-47290, is a bit like the manager checking a guest's ID at the front door, giving them a key, but then the guest swaps their room key with a master key before reaching their room, gaining access to places they shouldn't. This "swap" is the crux of a TOCTOU vulnerability, and it matters because it can undermine the isolation boundaries that make containers secure. For anyone running containers – and that's a lot of us – understanding this bug is key to keeping your infrastructure safe.

Technical Deep Dive: Unpacking the Deception

Let's get our hands dirty and look at what's really going on under the hood.

Vulnerability Details: The TOCTOU Tango

At its heart, CVE-2025-47290 is a Time-of-Check to Time-of-Use (TOCTOU) race condition. This class of vulnerabilities occurs when a program:

  1. Checks a resource's state or a condition (e.g., "Is this file path safe and within the container's designated area?").
  2. Uses that resource based on the check's outcome (e.g., "Okay, the path is safe, let's write the file here.").

The vulnerability arises if an attacker can change the resource's state between the check and the use. In our containerd case, this happens during the image unpacking process, specifically when applying tar layers.

Root Cause Analysis: The Case of the Stale Cache

The vulnerability was inadvertently introduced in containerd v2.1.0 through a performance optimization. The function responsible for applying tar layers, applyNaive (in pkg/archive/tar.go), was modified to cache resolved file paths. Previously, for every file or directory in a tar archive layer, containerd would call fs.RootPath(root, path) to validate that the path was confined within the container's root directory on the host. This fs.RootPath function is crucial for security as it resolves symlinks and ensures no "path traversal" (like ../../../../etc/passwd) escapes the intended boundary.

The optimization introduced a cachedRootPath structure. Its get method would call fs.RootPath once for a given path component and store the validated result. Subsequent operations needing that path component would use the cached, "blessed" version.

Here's the rub: what if the nature of a filesystem object changes after its path is checked and cached, but before it's used for a write operation?

Imagine the unpacker encounters a path like my_dir/my_subdir.

  1. cachedRootPath.get("my_dir/my_subdir") is called. Internally, fs.RootPath validates it, and it's cached as a safe directory path.
  2. A cleverly crafted tar archive then, through subsequent entries or manipulations allowed by the tar format, replaces my_dir/my_subdir (which was a directory) with a symbolic link: my_dir/my_subdir -> /host/sensitive_area.
  3. Later, when containerd tries to write a file like my_dir/my_subdir/evil_file, it might still rely on the cached information that my_dir/my_subdir is a legitimate directory within the container. The write operation then follows the symlink, and evil_file lands on the host system, outside the container's jail.

The patch for CVE-2025-47290 (commit cada13298fba85493badb6fecb6ccf80e49673cc) reverts the commit that introduced this caching mechanism.

--- a/pkg/archive/tar.go
+++ b/pkg/archive/tar.go
@@ -157,31 +157,6 @@ func Apply(ctx context.Context, root string, r io.Reader, opts ...ApplyOpt) (int
 	return options.applyFunc(ctx, root, r, options)
 }
 
-// cachedRootPath will memoize root paths, avoiding redundant checks.
-type cachedRootPath struct {
-	root  string
-	cache map[string]string
-}
-
-func newCachedRootPath(root string) *cachedRootPath {
-	return &cachedRootPath{
-		root:  root,
-		cache: make(map[string]string),
-	}
-}
-
-func (c *cachedRootPath) get(path string) (string, error) {
-	if hit, ok := c.cache[path]; ok {
-		return hit, nil
-	}
-	p, err := fs.RootPath(c.root, path)
-	if err != nil {
-		return "", err
-	}
-	c.cache[path] = p
-	return p, nil
-}
-
 // applyNaive applies a tar stream of an OCI style diff tar to a directory
 // applying each file as either a whole file or whiteout.
 // See https://github.com/opencontainers/image-spec/blob/main/layer.md#applying-changesets
@@ -239,7 +214,6 @@ func applyNaive(ctx context.Context, root string, r io.Reader, options ApplyOpti
 	}
 
 	// Iterate through the files in the archive.
-	rootPath := newCachedRootPath(root)
 	for {
 		select {
 		case <-ctx.Done():
@@ -276,7 +250,7 @@ func applyNaive(ctx context.Context, root string, r io.Reader, options ApplyOpti
 
 		// Split name and resolve symlinks for root directory.
 		ppath, base := filepath.Split(hdr.Name)
-		ppath, err = rootPath.get(ppath)
+		ppath, err = fs.RootPath(root, ppath) // Reverted to direct call
 		if err != nil {
 			return 0, fmt.Errorf("failed to get root path: %w", err)
 		}

By removing cachedRootPath and ensuring fs.RootPath is called afresh before operations like creating directories or files, the window for the TOCTOU race condition is effectively closed. The check is now performed much closer to the use.

Attack Vectors

An attacker would need to craft a malicious container image. This image's tar layers would be structured to exploit this caching behavior. For example, one layer might define a directory, get it cached, and then a subsequent layer (or even a later entry in the same layer) could replace that directory with a symlink pointing outside the container's intended root, followed by an attempt to write a file into that symlink.

The primary attack vector is tricking a user or system into pulling and unpacking this malicious image on a host running the vulnerable containerd v2.1.0.

Business Impact

The impact can be severe:

  • Data Corruption/Modification: Arbitrary file writes can corrupt critical host system files or application data.
  • Denial of Service (DoS): Overwriting essential system files could render the host unusable.
  • Information Disclosure: While the vulnerability is about file writes, a cleverly placed file could alter system behavior to disclose information.
  • Potential for Further Compromise: Writing malicious executables, cron jobs, or SSH authorized keys could lead to full host takeover.

Proof of Concept (Theoretical)

Let's illustrate with a simplified, theoretical PoC. An attacker crafts a tar archive for an image layer with the following entries, exploiting the (now-fixed) caching logic:

# Malicious Tar Archive Structure (Conceptual)

# Entry 1: Create a directory. This path might get "checked" and "cached" as safe.
1. type: directory
   name: "var/lib/myapp/config_temp"
   mode: 0755

# (Imagine other legitimate files/dirs being processed here)

# Entry X: This is where the TOCTOU race might be triggered.
# The attacker crafts the tar so that 'var/lib/myapp/config_temp' is now replaced
# by a symlink before a file is written into it.
# This could involve specific tar entry ordering or types that allow replacement.
# For simplicity, let's assume the tar format allows an overwrite or a specific
# sequence that achieves this effect on the vulnerable `cachedRootPath` logic.

2. type: symlink
   name: "var/lib/myapp/config_temp"  # Same path as the directory above
   link_target: "../../../../../../../etc" # Points to /etc on the host

# Entry Y: Write a file. The vulnerable containerd might use the cached (stale)
# information that "var/lib/myapp/config_temp" is a safe directory within the
# container's root. However, it's now a symlink.
3. type: regular_file
   name: "var/lib/myapp/config_temp/malicious_settings.conf"
   content: "ATTACKER_CONTROLLED_CONTENT_HERE"
   mode: 0644

Expected outcome on a vulnerable containerd v2.1.0 system:
The file malicious_settings.conf would be written to /etc/malicious_settings.conf on the host system, not within the container's isolated filesystem.

Why the fix works:
The patched version of containerd (v2.1.1) removes the path caching. Before writing malicious_settings.conf, it would re-evaluate var/lib/myapp/config_temp using fs.RootPath. fs.RootPath would correctly resolve the symlink and detect that ../../../../../../../etc/malicious_settings.conf is outside the allowed container root, preventing the write and likely erroring out.

Mitigation and Remediation

Don't panic, but do act! Here's how to protect yourself:

Immediate Fixes:

  1. Upgrade Containerd: The most crucial step. Update to containerd v2.1.1 or later.
    # Example for systems using apt (Debian/Ubuntu) - actual commands may vary
sudo apt-get update
sudo apt-get install containerd.io=<version_string_for_2.1.1_or_later>
# Verify the version
containerd --version
  2. Use Trusted Images: If upgrading immediately isn't possible (though it really should be your priority), be extremely cautious about the images you pull. Only use images from verified, trusted registries and publishers.
  3. Restrict Permissions: Limit who can pull or import images onto your systems.

Long-Term Solutions:

  • Patch Management: Keep all your software, especially critical infrastructure like container runtimes, up-to-date.
  • Defense in Depth: Employ multiple layers of security (network segmentation, host-based intrusion detection, runtime security monitoring).
  • Image Scanning: Integrate image scanning tools into your CI/CD pipeline to detect known vulnerabilities or malicious patterns in container images before they are deployed.
  • Principle of Least Privilege: Ensure that containerd and related processes run with the minimum necessary privileges.

Verification Steps:

  • Confirm your containerd version is v2.1.1 or newer.
  • Monitor host filesystem for any unexpected modifications, especially in sensitive directories like /etc, /bin, /usr/bin, etc., particularly after pulling new images if you were running the vulnerable version.

Timeline of CVE-2025-47290

  • Discovery Date: While not explicitly stated, this was likely in early to mid-May 2025 by Tõnis Tiigi.
  • Vendor Notification: Tõnis Tiigi responsibly disclosed the issue to the containerd project.
  • Patch Availability: containerd v2.1.1 was released, incorporating the fix, around May 20, 2025.
  • Public Disclosure: The CVE and GitHub advisory were made public on May 20-21, 2025.

Behind the Scenes:
It's worth noting that the discoverer, Tõnis Tiigi, is a prominent developer in the container ecosystem, known for his work on BuildKit and Docker. Discoveries from such experts often highlight subtle but important issues that arise from deep familiarity with the system's internals. This find underscores the ongoing effort by the community to harden these critical infrastructure components.

Lessons Learned: The Perils of Premature Optimization (and Stale Bread)

This CVE offers some valuable takeaways:

  1. Performance vs. Security is a Delicate Balance: The vulnerability stemmed from a performance optimization (caching path resolutions). While performance is important, security-critical operations (like filesystem access control) must be handled with extreme care. Caching results of security checks can be dangerous if the underlying state can change. It's like caching the answer to "Is the door locked?" – it's only useful if the door's state can't change without invalidating the cache.
  2. TOCTOU Vulnerabilities are Sneaky: They often hide in plain sight and depend on race conditions that can be hard to trigger consistently during testing. Diligent code review and a security-first mindset are crucial.
  3. Trust, but Verify (Your Images and Your Runtimes): Even foundational software like containerd can have vulnerabilities. Regularly update, and be mindful of the provenance of your container images.

One Key Takeaway:
Never assume that a security check performed once remains valid indefinitely, especially when dealing with mutable resources like a filesystem. Re-validate critical conditions as close to the point of use as possible.

References and Further Reading

This vulnerability, CVE-2025-47290, is a great reminder that container security is an ongoing process, not a one-time setup. The narrow affected version range is a silver lining, but it highlights the importance of prompt patching.

So, what are your thoughts? Have you encountered similar TOCTOU issues in other software? How does your organization balance the need for speed with the imperative of security? Share your insights in the comments below!

Stay safe, and keep those containers contained!

Read more