← Back to Feed CACHED · 2026-09-23 11:25:04 · CACHE_KEY CVE-2025-11395
CVE-2025-11395 · CWE-277 · Disclosed 2026-09-15

A flaw was found in Podman.

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone hands you a booby-trapped suitcase and you have to unzip it yourself for the bomb to go off

CVE-2025-11395 is an arbitrary file-write flaw in Podman's podman load and podman volume import code paths. When a user feeds a specially crafted OCI tar archive to either command, the archive's malicious symlinks or path-traversal entries escape the intended extraction directory and write files anywhere the Podman process user can reach. Affected versions include Podman 5.4.2 through 5.8.6 and 6.0.x through 6.1.1. The underlying libraries — go.podman.io/image/v5 (< 5.39.3; 5.40.0–5.41.1) and go.podman.io/storage (< 1.62.1; 1.63.0–1.64.0) — carry the vulnerable tar-extraction routines used by storage/pkg/archive.UnpackLayer, ApplyLayer, and ApplyUncompressedLayer. Critically, registry-based image pulling (podman pull) is completely unaffected — only local archive import triggers the flaw.

Red Hat rates this MEDIUM / 5.5 and that broadly matches reality. The vendor CVSS uses AV:A/AC:L/PR:L which overstates network reachability; the GHSA advisory for the underlying library scores it 6.1 with AV:L/UI:R, which is closer to the truth because exploiting the bug requires someone to run podman load on a file the attacker controls. There is no daemon to probe, no listening port, no unauthenticated path. In rootless Podman — the default and recommended configuration — the blast radius is further bounded to the unprivileged user's writable directories. The vendor severity is directionally correct; a minor upward bump to 5.8 accounts for the HIGH integrity impact the GHSA notes and for CI/CD supply-chain scenarios where podman load is automated.

"Local file-write via crafted tar; registry pulls unaffected — patch on schedule."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Craft a malicious OCI tar archive

The attacker constructs an OCI-compliant image archive whose layer tarballs contain path-traversal entries (e.g., ../../../etc/cron.d/backdoor) or symlink chains that resolve outside the extraction root. No specialized tooling beyond tar and basic Go scripting is needed; the technique is a well-known variant of the classic 'Zip Slip' / tar path-traversal pattern documented in CWE-22.
Conditions required:
  • Attacker has the ability to create or modify an OCI tar archive
Where this breaks in practice:
  • Requires knowledge of the target filesystem layout to place files usefully
STEP 02

Deliver the archive to the target

The attacker must get the crafted tar file onto a system where a user or automation will invoke podman load or podman volume import against it. Delivery could happen via a poisoned artifact repository, a shared CI cache, an email attachment, or a compromised build pipeline artifact. This is the hardest step — registry pulls (podman pull) are not affected, so the normal container image consumption path is safe.
Conditions required:
  • Attacker can influence an archive that reaches a system running Podman
  • The archive must be consumed via podman load or podman volume import, not podman pull
Where this breaks in practice:
  • Standard container workflows use registry pulls, not podman load from untrusted files
  • Enterprise CI systems typically validate artifact provenance (Sigstore/cosign, Notary)
  • Network segmentation and download policies limit what files reach build workers
Detection/coverage: Monitor for podman load and podman volume import invocations via auditd rules on the execve syscall; unusual source paths or untrusted archive origins are signals.
STEP 03

Victim executes podman load

A user or CI job runs podman load -i malicious.tar or podman volume import vol malicious.tar. Podman's archive extraction routines process the crafted layer without sanitizing path components, writing attacker-controlled content to arbitrary paths reachable by the process user. No additional privileges are escalated — the write happens as the calling user.
Conditions required:
  • Victim must explicitly run podman load or podman volume import on the attacker's archive
  • Podman version must be in the affected range (< 5.8.7 or 6.0.x–6.1.1)
Where this breaks in practice:
  • In rootless mode (default), writes are confined to the unprivileged user's namespace — no system-level files are reachable
  • SELinux in enforcing mode (RHEL default) blocks writes outside Podman's allowed file contexts via container_t domain transitions
Detection/coverage: SELinux AVC denials will fire if the write targets a file context outside container_file_t. File integrity monitoring (AIDE, OSSEC, osquery file_events) on sensitive paths catches unexpected modifications.
STEP 04

Attacker achieves persistence or supply-chain injection

If the process runs as root (rootful Podman), the attacker can overwrite system binaries, cron jobs, SSH authorized_keys, or systemd units to achieve persistence. In a CI/CD context, overwriting build scripts or source files could inject malicious code into downstream artifacts. In rootless mode, the impact is limited to the user's own files — .bashrc, per-user crontabs, or application configs.
Conditions required:
  • Rootful Podman for system-level impact, OR CI pipeline context for supply-chain impact
Where this breaks in practice:
  • Rootless Podman constrains the blast radius to user-owned files
  • Most production Kubernetes/OpenShift nodes pull images from registries — podman load is rare on cluster nodes
  • CI pipelines with ephemeral workers discard the worker after each job, limiting persistence
Detection/coverage: Host-based IDS, file integrity monitoring, and CI artifact signing/verification (cosign verify) detect or prevent the downstream impact.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No campaigns, threat actor TTPs, or incident reports reference this CVE as of 2026-09-23.
Proof-of-ConceptNo public PoC identified. No exploit code on GitHub, Exploit-DB, or Nuclei templates. The technique (tar path traversal) is well-understood but no weaponized tool targets this specific Podman code path.
EPSS Score0.00193 (≈0.19% probability of exploitation in next 30 days). This places it in roughly the 30th–35th percentile — lower predicted exploitation likelihood than ~65–70% of all scored CVEs.
KEV StatusNot listed. No CISA Known Exploited Vulnerabilities entry as of 2026-09-23.
CVSS VectorVendor: CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L5.5. GHSA (library-level): CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L6.1. The GHSA vector is more accurate — the attack is local with user interaction required, and the integrity impact is high (arbitrary file overwrite).
Affected VersionsPodman 5.4.2 – 5.8.6 and 6.0.0 – 6.1.1. Libraries: go.podman.io/image/v5 < 5.39.3 and 5.40.0–5.41.1; go.podman.io/storage < 1.62.1 and 1.63.0–1.64.0. Also affects github.com/containers/storage and github.com/containers/image/v5 (deprecated, no fix — migrate to go.podman.io equivalents).
Fixed VersionsPodman 5.8.7 and 6.1.2 (both released 2026-09-16). Libraries: go.podman.io/image/v5 5.39.3 / 5.41.2; go.podman.io/storage 1.62.1 / 1.64.1. RHEL backports: pending per Red Hat tracker; RHEL 9.2 advisory RHSA-2026:4533 covers related but distinct CVEs — watch for a dedicated erratum.
Scanning / ExposureNot a network-exploitable vulnerability — no Shodan/Censys/GreyNoise/FOFA exposure surface. The vulnerable code path is podman load / podman volume import, which are CLI commands, not daemons or APIs.
Disclosure TimelineDisclosed 2026-09-15. Podman 5.8.7 and 6.1.2 released 2026-09-16 (next-day fix). GHSA advisories GHSA-3gcv-x57j-xqxv and GHSA-mmq6-9mjh-hvq3 published concurrently.
ReporterNot publicly credited in available advisories. Fix commits: acbb1e7 (main), 3b75133 (podman-6.1 branch), bdae767 (podman-5.8 branch).
04 · The Call

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

Why this verdict

  • User interaction is mandatory. The victim must explicitly run podman load or podman volume import on an attacker-controlled archive. There is no daemon, no listening port, no unauthenticated remote vector. This is equivalent to 'open a malicious file' — the attacker cannot trigger it without the user's participation.
  • Registry pulls are completely unaffected. The overwhelmingly dominant container image consumption path — podman pull from a registry — does not exercise the vulnerable code. This dramatically narrows the reachable population even among Podman users.
  • Rootless Podman (the default) caps the blast radius. In rootless mode, the file write is constrained to the unprivileged user's writable paths. System binaries, cron, and SSH host keys are out of reach. This applies to the majority of modern Podman deployments, especially on RHEL 8+/9+/10 where rootless is default.
  • SELinux enforcing mode provides a hard backstop on RHEL. The container_t SELinux domain prevents Podman from writing to file contexts outside its allowed set, even if the path-traversal succeeds at the filesystem layer. RHEL ships with enforcing mode on by default.
  • Role multiplier: CI/CD pipelines. In CI/CD, podman load is sometimes used to import pre-built images from artifact caches. If an attacker poisons the cache artifact, they could overwrite files on the CI worker and inject malicious code into build outputs — a supply-chain pivot. This scenario is realistic but narrow: it requires the attacker to already have write access to the artifact store, the pipeline to use podman load (not podman pull), and the worker to be non-ephemeral. Estimated ≥5% of Podman installs are in CI/CD roles using podman load. The blast radius can be supply-chain-scale, which would normally trigger a HIGH floor — however, the chain requires a prior compromise (artifact store write access), making the Podman bug a second-stage amplifier rather than the initial entry point.
  • Role multiplier: Container build hosts / OpenShift nodes. Production Kubernetes and OpenShift nodes use CRI-O or containerd as their runtime, not podman load. Podman on these nodes is a debugging tool, not the image ingestion path. The chain does not meaningfully succeed in this role via the normal operational path.
  • No exploitation evidence, no PoC, very low EPSS. EPSS of 0.00193 (≈30th percentile) and zero in-the-wild activity or public PoC code indicate no near-term weaponization pressure.

Why not higher?

Elevating to HIGH would require either a remotely exploitable vector or a scenario where the vulnerable code path is exercised automatically in high-value roles without user interaction. Neither condition is met: registry pulls are unaffected, podman load is a manual/deliberate action, and the CI/CD supply-chain scenario requires a prior compromise of the artifact source — making this CVE a chain amplifier, not an initial access vector. The blast radius in the most common deployment (rootless, SELinux enforcing, registry-based pulls) is bounded to user-level file writes.

Why not lower?

Dropping to LOW would understate the real integrity impact. The GHSA correctly rates integrity as HIGH — an attacker who lands the chain can write arbitrary content to arbitrary paths within the user's permission scope. In rootful deployments (still present in legacy environments and some CI setups) this means full system-level file overwrite. The tar path-traversal technique is well-understood and trivial to implement, so the barrier to building a PoC is low even if none is public yet.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rootless Podman across all hosts — Rootless mode confines file writes to the unprivileged user's namespace, preventing system-level overwrite even if the vulnerability is triggered. Verify with podman info --format '{{.Host.Security.Rootless}}'. This is the single highest-impact mitigation and should already be your default. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, but this control should be validated immediately.
  2. Keep SELinux in enforcing mode on RHEL/Fedora/CentOS — SELinux's container_t domain blocks writes to file contexts outside Podman's allowed set. Run getenforce to verify. Do not set permissive mode on container hosts.
  3. Audit and restrict podman load / podman volume import usage — Create auditd rules: auditctl -a always,exit -F arch=b64 -S execve -F path=/usr/bin/podman -k podman_load. Alert on any podman load or podman volume import invocation, especially from CI/CD pipelines. Restrict these commands to trusted operators via sudoers or Polkit policies.
  4. Validate container image provenance in CI/CD — Require Sigstore/cosign signature verification on all images before podman load. If your pipeline uses podman load from artifact caches, add cosign verify as a gating step. This blocks crafted archives from untrusted sources.
  5. Upgrade to Podman 5.8.7+ or 6.1.2+ — The definitive fix. Podman 5.8.7 and 6.1.2 were released on 2026-09-16 with patched archive extraction. Under the noisgate remediation SLA for MEDIUM, apply the vendor patch within 365 days. If you have CI/CD pipelines running podman load from external sources, prioritize those hosts.
What doesn't work
  • Network segmentation / WAF / NGFW — This is not a network-exploitable vulnerability. There is no inbound traffic to block; the attack is triggered by a local CLI command on a file already present on the host.
  • Container image scanning (Trivy, Grype, Snyk Container) — These tools scan image contents for known vulnerabilities inside containers. They do not inspect the OCI tar archive's layer structure for path-traversal payloads during podman load. The malicious entries are in the tar metadata, not in package manifests.
  • Disabling podman pull or registry access — Registry-based pulls are *not* the vulnerable path. Restricting registry access does not mitigate this CVE and may cause operational disruption.
06 · Verification

Crowdsourced verification payload.

Run this script on each target host where Podman is installed. No special privileges required — it just parses podman --version. Example: chmod +x check_cve_2025_11395.sh && ./check_cve_2025_11395.sh or specify a custom binary path: ./check_cve_2025_11395.sh /usr/local/bin/podman.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2025-11395 Checker — Podman arbitrary file write via crafted tar archive
# Fixed in: Podman 5.8.7+ (5.x branch), 6.1.2+ (6.x branch)
# Affected: Podman 5.4.2–5.8.6, 6.0.0–6.1.1
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PODMAN_BIN="${1:-podman}"

if ! command -v "$PODMAN_BIN" &>/dev/null; then
    echo "UNKNOWN — podman binary not found at '$PODMAN_BIN'"
    exit 2
fi

VERSION=$("$PODMAN_BIN" --version 2>/dev/null | grep -oP '\d+\.\d+\.\d+' | head -1)

if [[ -z "$VERSION" ]]; then
    echo "UNKNOWN — could not parse podman version"
    exit 2
fi

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

echo "Detected Podman version: $VERSION"

if (( MAJOR < 5 )); then
    echo "UNKNOWN — Podman $VERSION predates known affected range; verify manually"
    exit 2
elif (( MAJOR == 5 )); then
    if (( MINOR < 4 )); then
        echo "UNKNOWN — Podman $VERSION may predate the vulnerable code; verify manually"
        exit 2
    elif (( MINOR < 8 )); then
        echo "VULNERABLE — Podman $VERSION is affected (fix: >= 5.8.7)"
        exit 1
    elif (( MINOR == 8 && PATCH < 7 )); then
        echo "VULNERABLE — Podman $VERSION is affected (fix: >= 5.8.7)"
        exit 1
    else
        echo "PATCHED — Podman $VERSION includes the fix (>= 5.8.7)"
        exit 0
    fi
elif (( MAJOR == 6 )); then
    if (( MINOR < 1 )); then
        echo "VULNERABLE — Podman $VERSION is affected (fix: >= 6.1.2)"
        exit 1
    elif (( MINOR == 1 && PATCH < 2 )); then
        echo "VULNERABLE — Podman $VERSION is affected (fix: >= 6.1.2)"
        exit 1
    else
        echo "PATCHED — Podman $VERSION includes the fix (>= 6.1.2)"
        exit 0
    fi
elif (( MAJOR > 6 )); then
    echo "PATCHED — Podman $VERSION is above all affected versions"
    exit 0
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.