CVE-2026-41579

What it actually does

A malicious OCI container image can define /dev as a symlink rather than a normal directory. Vulnerable runc versions use filepath.Join-derived paths with os.Remove and os.Symlink while setting up /dev/ptmx and standard /dev symlinks. If the parent /dev path resolves outside the container root filesystem, runc can delete a host-side file named ptmx or create a fixed set of symlinks such as fd, stdin, stdout, and stderr in an attacker-influenced pre-existing host directory. The impact is limited to host filesystem integrity changes and does not by itself provide arbitrary code execution, credential theft, or broad container escape. Docker is not considered exploitable because its image layering masks a malicious top-level /dev symlink, but other container tooling built on runc may remain exposed.

Why it matters to the business

The main risk is that running an untrusted or malicious container image with affected runc-based tooling could modify limited host filesystem contents, potentially disrupting container hosts, build systems, CI runners, developer workstations, or Kubernetes/container runtime nodes that execute third-party images. The CVSS and EPSS are low, it is not in CISA KEV, and there is no known public exploit maturity in the provided data, so this is lower urgency than active remote-code-execution issues; however, organizations that run untrusted images or multi-tenant container workloads should still prioritize patching because container runtime boundary flaws can become operationally significant when chained with other weaknesses.

How an attack unfolds

An attacker prepares an OCI image whose /dev entry is a symlink pointing to a host-accessible directory that will exist when the image is unpacked or used by a susceptible higher-level runtime. The attacker then persuades a user, build pipeline, orchestrator, or container platform to run or otherwise instantiate that image using a vulnerable runc version through tooling that does not mask the malicious /dev symlink. During container root filesystem setup, runc attempts to remove or create device-related paths under what it believes is the container's /dev directory. Because /dev is a symlink, those operations can resolve into the targeted host directory. The attacker can cause deletion of a file named ptmx or creation of a small, hardcoded set of symlinks in that host directory. Exploitation requires the malicious image to be used and is constrained to specific path names and symlink targets; it is not a general arbitrary file write primitive. Docker-based execution is not expected to be exploitable due to Docker's protective top-level read-only layer behavior.

How to fix it

Upgrade runc to a fixed release: 1.3.6, 1.4.3, 1.5.0, or later, depending on the release branch in use. Also update Linux distribution packages and higher-level container runtime packages that vendor or bundle runc, including containerd, CRI-O, Kubernetes node images, appliance images, CI runner images, and platform-specific container runtime distributions. Restart or roll nodes where needed so the patched runc binary is actually used by subsequent container starts. Where immediate upgrade is not possible, reduce exposure by blocking untrusted OCI images, enforcing image allowlists and signed-image policy, preventing arbitrary users from launching containers, avoiding runtimes known to expose the issue, and scanning images for /dev implemented as a symlink. Docker deployments are described as not exploitable for this specific issue, but the underlying runc package should still be updated to prevent exposure through other tooling on the same systems.

How to confirm the fix worked

Confirm the effective runc binary reports a fixed version by running runc --version or using the operating system package manager to verify the installed package version. Validate the runtime path used by containerd, CRI-O, Kubernetes node images, CI runners, and other orchestrators rather than assuming the system default runc is the one in use. Check that patched packages have been deployed to all container hosts and that long-lived nodes or runner images have been rebuilt or restarted if necessary. For exposure testing, inspect container images and layers for a top-level /dev symlink; vulnerable environments should be treated as exposed if they run such images through non-Docker runc-based tooling. In a controlled lab only, run a benign test image with /dev as a symlink targeting a disposable host directory and confirm that no host-side ptmx deletion or fd/stdin/stdout/stderr symlink creation occurs after patching.

Typical attack path

1. Build or obtain a malicious OCI image containing /dev as a symlink instead of a directory.
2. Set the symlink target so runc path setup resolves into a chosen pre-existing host directory under an exposed runtime configuration.
3. Publish the image to a registry, submit it to a CI/build workflow, or otherwise induce an operator or platform to run it.
4. The vulnerable runc-based runtime starts the container and performs root filesystem device setup.
5. runc follows the malicious /dev symlink during /dev/ptmx or /dev symlink setup operations.
6. A host-side file named ptmx is deleted or fixed symlinks such as fd, stdin, stdout, and stderr are created in the targeted directory.
7. The attacker leverages the resulting host filesystem modification for disruption, persistence of misleading filesystem artifacts, or as part of a broader exploit chain.

How to detect it

To determine whether this was already exploited, focus on image provenance, runtime execution records, and filesystem artifacts. Review container runtime logs, orchestrator audit logs, CI job logs, image pull records, and registry access logs for recently executed untrusted images, then inspect those image manifests/layers for a top-level /dev entry that is a symlink. On hosts that ran suspicious images through non-Docker runc-based tooling, examine likely target directories for unexpected deletion of a file named ptmx or unexpected symlinks named fd, stdin, stdout, or stderr pointing to /proc/self/fd paths. File integrity monitoring, endpoint telemetry, Linux auditd records, eBPF filesystem event logs, and EDR file-operation timelines are the most useful sources because the exploitation effect is a local filesystem operation performed by runc during container setup. Useful event patterns include runc creating symlinks named fd, stdin, stdout, or stderr outside a container root filesystem, or runc unlinking/removing a file named ptmx outside an expected container rootfs path. There are no unique network indicators for this issue; registry activity alone is only suspicious when tied to an image containing /dev as a symlink and subsequent host filesystem artifacts.

• /dev -> symlink
• dev -> symlink
• /dev/ptmx
• ptmx
• fd -> /proc/self/fd
• stdin -> /proc/self/fd/0
• stdout -> /proc/self/fd/1
• stderr -> /proc/self/fd/2
• /proc/self/fd
• /proc/self/fd/0
• /proc/self/fd/1
• /proc/self/fd/2
• comm="runc" name="ptmx"
• comm="runc" name="fd"
• comm="runc" name="stdin"
• comm="runc" name="stdout"
• comm="runc" name="stderr"

What your security team should do

• Inventory all systems and products that include runc directly or indirectly, especially Kubernetes nodes, containerd/CRI-O hosts, CI runners, image build infrastructure, developer container tooling, and appliance images.
• Patch runc to 1.3.6, 1.4.3, 1.5.0, or later and redeploy dependent runtime packages or node images.
• Prioritize hosts that run untrusted third-party images, multi-tenant workloads, user-submitted CI jobs, or images from public registries.
• Add image scanning checks that flag OCI images where /dev is a symlink rather than a directory.
• Restrict container execution to trusted, signed, and approved images until patching is complete.
• Review recent container start activity involving untrusted images on non-Docker runc-based tooling for signs of unexpected host filesystem changes.
• Do not rely only on the low CVSS or EPSS score if the environment allows untrusted users to run containers, because exploitability is highly dependent on runtime workflow and trust boundaries.