← Back to Feed CACHED · 2026-09-23 11:29:21 · CACHE_KEY CVE-2026-79705
CVE-2026-79705 · CWE-22 · Disclosed 2026-09-15

A flaw was found in the buildah/copier Go package.

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

Someone left a trick welcome mat outside a side entrance that only a few macOS visitors ever use

CVE-2026-79705 is a path-traversal flaw in the buildah/copier Go package — specifically the tar extraction logic. A crafted tar archive with malicious symlinks can escape the intended extraction directory and overwrite arbitrary files on the host. The catch: Buildah itself is not affected because it wraps copier calls inside a chroot jail. The bug only fires when the copier library is consumed by non-root or non-Linux callers *outside* of the Buildah codebase. The canonical real-world trigger is a macOS Podman remote client performing podman cp against a compromised or malicious Podman system service server. Affected versions: buildah/copier < 1.43.4 and >= 1.44.0 < 1.45.1 (Go module github.com/containers/buildah/copier and go.podman.io/buildah/copier). Patched in 1.43.4 and 1.45.1.

Red Hat rated this MEDIUM at CVSS 4.5 (AV:N/AC:L/PR:H/UI:R); the GitHub Security Advisory scored the same bug at 6.1 (AV:L/AC:L/PR:N/UI:R). Both are *generous* given the real-world constraints. The bug does not affect buildah, does not affect Linux-root callers, has no confidentiality impact, requires user interaction, and the primary attack path demands the victim voluntarily connect to a malicious Podman service. With an EPSS of 0.00246 (bottom 3%), no KEV listing, no public PoC, and no observed exploitation, the vendor MEDIUM overstates the operational risk for nearly every enterprise fleet.

"Niche library-only bug requires a victim on macOS to trust a rogue Podman server — skip the fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker controls a Podman system service or tar archive

The attacker must operate a rogue Podman system service endpoint or deliver a specially crafted tar archive to the victim. The tar contains entries with symlink components that resolve outside the intended extraction root. This requires social engineering (tricking a developer into connecting to the rogue server) or supply-chain placement of a malicious archive.
Conditions required:
  • Attacker controls a Podman system service endpoint OR can deliver a malicious tar archive to the victim
Where this breaks in practice:
  • Podman remote clients almost universally connect to their own local VM, not external servers
  • Delivering a malicious tar requires social engineering or upstream compromise
STEP 02

Victim runs podman cp or copier-based extraction as non-root / non-Linux

The victim must invoke podman cp on a macOS remote client against the malicious server, or a third-party Go application that imports buildah/copier must extract the attacker-controlled tar as a non-root user. Buildah's own chroot hardening blocks this path entirely when buildah itself is the caller. On Linux, root callers are also unaffected.
Conditions required:
  • Victim is on macOS (Podman remote) OR running a non-buildah Go application importing copier as non-root on Linux
  • User must initiate the copy/extraction operation (UI:R)
Where this breaks in practice:
  • The vast majority of buildah/copier consumers ARE buildah itself — which is immune
  • Only 14 packages import copier externally, almost all are Podman forks
  • CI/CD runners are overwhelmingly Linux-based and often run as root, both of which neutralize the bug
  • macOS Podman remote users are developer workstations, not production infrastructure
Detection/coverage: No scanner signatures observed. Static analysis of Go module dependencies (go.sum / SBOM) can identify copier imports.
STEP 03

Symlink escape writes files outside extraction directory

The malicious tar entries use symlink traversal sequences to write files to arbitrary paths on the host filesystem accessible to the calling user. Because the caller is non-root, writes are limited to user-writable locations. No privilege escalation is inherent — the attacker gains write access equivalent to the running user's permissions.
Conditions required:
  • copier extraction proceeds without chroot (non-buildah caller)
  • Target paths must be writable by the calling user
Where this breaks in practice:
  • Non-root write scope limits blast radius to user home and tmp directories
  • No confidentiality impact — attacker cannot read files, only write/overwrite
  • macOS SIP and TCC further restrict writable paths on modern macOS
Detection/coverage: File integrity monitoring (FIM) on developer workstations would detect unexpected file creation, though this is rarely deployed on macOS dev machines.
STEP 04

Impact: arbitrary file overwrite within user context

The attacker can create or overwrite files within the calling user's permission scope. On a developer laptop this could mean modifying shell profiles, SSH configs, or IDE settings to achieve code execution on next login or terminal open. The impact is integrity-only — no data exfiltration path exists through this vulnerability alone.
Conditions required:
  • Successful file write from step 3
Where this breaks in practice:
  • Requires secondary action (user opening terminal, IDE, etc.) for code execution
  • Developer laptops are low-value targets relative to production infrastructure
  • EDR on macOS endpoints would flag anomalous process chains from modified shell profiles
Detection/coverage: EDR behavioral detection on macOS (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) would catch execution from tampered shell profiles or LaunchAgents.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed on CISA KEV. No campaigns, threat actor reporting, or honeypot activity documented as of 2026-09-23.
Proof-of-ConceptNo public PoC. No exploit code found on GitHub, ExploitDB, or PoC aggregator repositories. The advisory credits Oleh Konko, JUNYI LIU, İbrahim Sağlam, and Ron Masas as reporters — no PoC published by any.
EPSS0.00246 (0.246%) — bottom ~3rd percentile. Exploitation probability is near-floor.
KEV StatusNot listed. No CISA Known Exploited Vulnerabilities catalog entry.
CVSS VectorsRed Hat: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N = 4.5. GHSA: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L = 6.1. Discrepancy reflects differing interpretations of the attack vector (network via rogue server vs. local tar extraction).
Affected Versionsgithub.com/containers/buildah/copierall versions (migrate to go.podman.io/buildah/copier). go.podman.io/buildah/copier< 1.43.4 and >= 1.44.0, < 1.45.1.
Fixed Versionsbuildah 1.43.4 and 1.45.1. Backport commit: a88128d47cb3f3fcbd9e874270c22271b73eb30d. Distro packages: check RHEL 8/9/10, SLES 16, Fedora, Debian buildah packages for backport status.
Scanning / ExposureNot a network service — no Shodan/Censys/GreyNoise/FOFA exposure surface. Detection is via SBOM / dependency scanning for Go modules importing the vulnerable copier package.
Affected Products (Red Hat)RHEL 8, 9, 10; OpenShift Container Platform 4; Ansible Automation Platform 2; OpenShift Dev Spaces; OpenShift Virtualization 4; Red Hat Quay 3; Red Hat Hardened Images.
Library Import FootprintOnly 14 packages across the Go ecosystem import buildah/copier directly. Almost all are Podman core or Podman forks. One CI/CD tool (werf) imports it. Buildah itself — the dominant consumer — is not affected.
04 · The Call

Final Verdict
DOWNGRADED to LOW (3.0/10)

Why this verdict

  • Buildah immunity eliminates the primary consumer: Buildah wraps all copier calls in a chroot jail. The single largest consumer of this library is categorically not vulnerable. The bug only fires in the thin slice of code paths where copier is called outside buildah without chroot — primarily macOS Podman remote podman cp.
  • User interaction + social engineering prerequisite: The victim must voluntarily run podman cp against a malicious Podman service or extract an attacker-supplied tar archive. This is not a fire-and-forget remote exploit; it requires tricking a developer into connecting to an untrusted endpoint.
  • Non-root / non-Linux gate crushes reachable population: On Linux as root, the bug does not trigger. CI/CD pipelines (Linux, often root) and production container hosts (Linux, root-managed) are not in the blast radius. The reachable population is overwhelmingly macOS developer workstations.
  • Integrity-only, no confidentiality: The attacker can write files but cannot read them. There is no data exfiltration path. The write is limited to the calling user's permission scope — on macOS, further constrained by SIP and TCC.
  • Role multiplier: (a) *Low-value role (developer workstations)*: This is the canonical deployment. macOS Podman remote users are developers. Chain succeeds, blast radius is single-host, user-context file overwrite. (b) *Typical role (Linux container build hosts)*: Buildah itself is immune; Podman on Linux as root is immune. Chain fails. (c) *High-value role (CI/CD — werf, OpenShift builds)*: werf is the only non-Podman importer. OpenShift builds use buildah (immune). werf on Linux CI runners as non-root could theoretically be vulnerable if processing attacker-controlled tar input, but this is an edge case affecting <0.1% of the installed base. No domain/fleet/supply-chain escalation path exists — the write is bounded to the runner's user context. No high-value role floor is triggered.
  • Zero threat signal: EPSS 0.00246, no KEV, no PoC, no in-the-wild exploitation, no campaign attribution. The vulnerability has been public for 8 days with zero weaponization.

Why not higher?

A MEDIUM rating would require either a broader reachable population or a credible path to high-value asset compromise. Neither exists here. Buildah's chroot immunity removes the dominant consumer. The non-root/non-Linux gate eliminates production Linux hosts and CI/CD runners. The remaining attack surface is macOS developer laptops connecting to rogue Podman services — a scenario that requires targeted social engineering with single-host, user-context impact. No PoC or exploitation activity justifies maintaining the vendor's MEDIUM.

Why not lower?

IGNORE would be appropriate only if the bug were entirely theoretical or affected no shipping software. Podman on macOS is a real product with real users, and macOS Podman remote podman cp is a documented attack path. A developer workstation compromise — even user-context — can lead to credential theft or code tampering. The integrity impact (High per both CVSS vectors) is genuine within its narrow scope, which justifies LOW over IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Update buildah/copier to 1.43.4+ or 1.45.1+ — The definitive fix. If you consume buildah as a binary (not the Go library), update your distro's buildah package. If you import the copier Go module, update your go.mod. Per noisgate remediation SLA for LOW, treat as backlog hygiene — no hard deadline, but roll into your next routine patching cycle.
  2. Restrict podman cp to trusted sources only — Advise macOS Podman users to never run podman cp against untrusted or third-party Podman service endpoints. This is the primary real-world vector. Document this in your developer security guidelines.
  3. Audit Go SBOM for copier imports — Run go mod graph | grep buildah/copier across your Go codebases to identify any applications importing the vulnerable library outside of buildah itself. Prioritize updating those applications.
  4. Deploy EDR on macOS developer workstations — Endpoint detection on macOS (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) will catch post-exploitation behaviors like modified shell profiles, LaunchAgent creation, or anomalous process trees resulting from file overwrites.
What doesn't work
  • WAF / network-layer filtering — This is not a network service vulnerability. There is no HTTP/TCP exploit payload to inspect or block. WAF rules are irrelevant.
  • Container image scanning (Trivy, Grype, Snyk Container) — These scan container images, not the host-side Go binary that runs the extraction. The vulnerability is in the client-side copier library, not in a container image layer.
  • Linux kernel hardening (seccomp, AppArmor, SELinux) — Buildah already uses chroot which neutralizes the bug. Additional Linux kernel hardening helps buildah-the-binary, but the vulnerable path is specifically the *non-chroot* code path on non-Linux or non-root callers where these controls don't apply.
06 · Verification

Crowdsourced verification payload.

Run on any host where buildah or a Go application importing buildah/copier is installed. Requires read access to the buildah binary or Go module cache. Example: bash check_cve_2026_79705.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-79705 — buildah/copier symlink path traversal checker
# Checks installed buildah version and Go module dependency.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

RESULT="UNKNOWN"

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

# --- Check 1: buildah binary ---
if command -v buildah &>/dev/null; then
  BVERSION=$(buildah --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  if [ -n "$BVERSION" ]; then
    echo "[*] Detected buildah version: $BVERSION"
    # Buildah itself uses chroot and is NOT vulnerable, but check
    # if the bundled copier library is patched anyway.
    # Patched: >= 1.43.4 (in 1.43.x line) or >= 1.45.1 (in 1.44+)
    MAJOR_MINOR=$(echo "$BVERSION" | grep -oE '^[0-9]+\.[0-9]+')
    if version_gte "$BVERSION" "1.45.1"; then
      echo "[+] buildah >= 1.45.1 — copier library is PATCHED"
      echo "[i] Note: buildah itself was never vulnerable (chroot hardening)."
      RESULT="PATCHED"
    elif [ "$MAJOR_MINOR" = "1.43" ] && version_gte "$BVERSION" "1.43.4"; then
      echo "[+] buildah 1.43.x >= 1.43.4 — copier library is PATCHED"
      echo "[i] Note: buildah itself was never vulnerable (chroot hardening)."
      RESULT="PATCHED"
    elif [ "$MAJOR_MINOR" = "1.44" ] || { [ "$MAJOR_MINOR" = "1.45" ] && ! version_gte "$BVERSION" "1.45.1"; }; then
      echo "[-] buildah $BVERSION — bundled copier is VULNERABLE"
      echo "[i] Note: buildah itself uses chroot and is NOT exploitable,"
      echo "    but other tools linking this copier version may be."
      RESULT="VULNERABLE"
    elif ! version_gte "$BVERSION" "1.43.4"; then
      echo "[-] buildah $BVERSION < 1.43.4 — bundled copier is VULNERABLE"
      RESULT="VULNERABLE"
    else
      echo "[?] buildah $BVERSION — cannot determine patch status"
    fi
  fi
else
  echo "[*] buildah binary not found on this host."
fi

# --- Check 2: Go module dependency (for Go projects) ---
if command -v go &>/dev/null; then
  echo ""
  echo "[*] Scanning Go module cache for buildah/copier..."
  GOMODCACHE=$(go env GOMODCACHE 2>/dev/null || echo "")
  if [ -n "$GOMODCACHE" ] && [ -d "$GOMODCACHE" ]; then
    FOUND=$(find "$GOMODCACHE" -path '*/containers/buildah@*' -name 'copier' -type d 2>/dev/null || true)
    if [ -n "$FOUND" ]; then
      echo "[!] Found buildah/copier in Go module cache:"
      echo "$FOUND"
      echo "[i] Audit go.mod files in your projects for this import."
      if [ "$RESULT" = "UNKNOWN" ]; then
        RESULT="VULNERABLE"
      fi
    else
      echo "[+] No buildah/copier found in Go module cache."
      if [ "$RESULT" = "UNKNOWN" ]; then
        RESULT="PATCHED"
      fi
    fi
  fi
fi

echo ""
echo "=== RESULT: $RESULT ==="

case "$RESULT" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac
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.