CVE-2026-79699: containers/storage Path Traversal Vulnerability

CVE-2026-79699 Overview

CVE-2026-79699 is a link-following vulnerability [CWE-59] in the containers/storage library. A crafted tar archive containing a malicious whiteout header, such as victim/.wh., can cause the extraction destination directory to be replaced with an arbitrary file. The flaw affects the storage/pkg/archive.UnpackLayer, ApplyLayer, and ApplyUncompressedLayer functions used during container image layer extraction. Local attackers who can supply a malicious layer to a container runtime that relies on this library can tamper with files on the host or within container storage.

Critical Impact
A crafted tar layer can replace the extraction destination with an attacker-controlled file, enabling limited integrity and availability impact on systems that unpack untrusted container layers.

Affected Products

containers/storage library (Go module used by Podman, Buildah, CRI-O, and Skopeo)
Downstream container runtimes and tools that call storage/pkg/archive.UnpackLayer, ApplyLayer, or ApplyUncompressedLayer
Red Hat distributions shipping affected containers/storage versions (see Red Hat CVE-2026-79699 Advisory)

Discovery Timeline

2026-09-15 - CVE-2026-79699 published to the National Vulnerability Database
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-79699

Vulnerability Analysis

The containers/storage library extracts tar-formatted container layers into a destination directory on disk. Tar layers use OverlayFS-style whiteout entries, prefixed with .wh., to signal that a file present in a lower layer should be removed in the resulting merged view. The archive handler resolves and acts on these whiteout entries before validating the target path.

A maliciously crafted archive can include a whiteout header whose relative path resolves to the extraction destination itself, for example victim/.wh.. When the extractor processes the entry it removes the destination and creates a new filesystem object in its place, controlled by the archive contents. The result is that an arbitrary file replaces the directory intended to hold the extracted layer.

Exploitation requires local access and user interaction, because the victim must invoke a tool that extracts the attacker-supplied layer. Confidentiality is not impacted, but integrity and availability of files under the extraction path are.

Root Cause

The root cause is improper handling of link and whiteout semantics during archive extraction, categorized as a link-following weakness [CWE-59]. The archive code applies whiteout removals without confining them to entries strictly below the destination root, allowing traversal-style manipulation of the destination itself.

Attack Vector

An attacker publishes or supplies a container image, OCI layer, or raw tar archive containing a whiteout entry that names the extraction root. When a local user or automated pipeline pulls, imports, or applies that layer using UnpackLayer, ApplyLayer, or ApplyUncompressedLayer, the destination directory is replaced by an attacker-controlled file. No authentication to the storage library is required, but a user action is needed to trigger extraction.

No public proof-of-concept exploit code has been released. Refer to the Red Hat Bug Report #2523408 for vendor technical detail.

Detection Methods for CVE-2026-79699

Indicators of Compromise

Tar or OCI layer entries whose names match the pattern */.wh. where the component before .wh. resolves to the extraction root or a parent path.
Unexpected replacement of container storage directories such as /var/lib/containers/storage/overlay/<layer>/diff with regular files.
Container image pulls from untrusted registries immediately preceding filesystem anomalies in container storage.

Detection Strategies

Inspect suspicious images with tar -tvf or skopeo inspect and flag any entry containing .wh. at or above the layer root.
Enable audit logging on container storage paths and alert on unlink or rename operations against layer root directories performed by container runtime processes.
Correlate image pull events from podman, buildah, or cri-o with subsequent write anomalies under /var/lib/containers or /var/lib/docker.

Monitoring Recommendations

Monitor container runtime and build service logs for extraction errors referencing whiteout entries or unexpected file type conversions.
Track the version of the containers/storage module in build pipelines and host packages, and alert when unpatched versions are detected.
Review registries and CI artifact sources to ensure only trusted publishers can supply layers to production hosts.

How to Mitigate CVE-2026-79699

Immediate Actions Required

Restrict container image pulls and layer imports to trusted registries and signed content.
Update containers/storage and dependent tools (Podman, Buildah, CRI-O, Skopeo) to fixed versions as listed in the Red Hat CVE-2026-79699 Advisory.
Audit CI/CD pipelines that ingest third-party OCI layers and disable automatic extraction of untrusted archives until patched.

Patch Information

Red Hat has published tracking and remediation guidance in the Red Hat CVE-2026-79699 Advisory and Red Hat Bug Report #2523408. Apply distribution updates for the containers-storage package and rebuild any Go binaries that vendor the affected module against a patched release.

Workarounds

Avoid pulling or extracting container layers from unverified sources until patches are applied.
Enforce image signature verification with policy.json and require signed images before extraction.
Run container runtimes as rootless users and on dedicated hosts to limit the blast radius of a replaced storage directory.

bash

# Verify installed containers-storage version and update on RHEL-based hosts
rpm -q containers-storage
sudo dnf update containers-storage podman buildah cri-o skopeo

# Enforce signature verification for pulled images
sudo tee /etc/containers/policy.json > /dev/null <<'EOF'
{
  "default": [{"type": "reject"}],
  "transports": {
    "docker": {
      "registry.access.redhat.com": [{"type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"}]
    }
  }
}
EOF