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.
4 steps from start to impact.
Attacker controls a Podman system service or tar archive
- Attacker controls a Podman system service endpoint OR can deliver a malicious tar archive to the victim
- Podman remote clients almost universally connect to their own local VM, not external servers
- Delivering a malicious tar requires social engineering or upstream compromise
Victim runs podman cp or copier-based extraction as non-root / non-Linux
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.- 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)
- 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
go.sum / SBOM) can identify copier imports.Symlink escape writes files outside extraction directory
- copier extraction proceeds without chroot (non-buildah caller)
- Target paths must be writable by the calling user
- 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
Impact: arbitrary file overwrite within user context
- Successful file write from step 3
- 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
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed on CISA KEV. No campaigns, threat actor reporting, or honeypot activity documented as of 2026-09-23. |
|---|---|
| Proof-of-Concept | No 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. |
| EPSS | 0.00246 (0.246%) — bottom ~3rd percentile. Exploitation probability is near-floor. |
| KEV Status | Not listed. No CISA Known Exploited Vulnerabilities catalog entry. |
| CVSS Vectors | Red 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 Versions | github.com/containers/buildah/copier — all versions (migrate to go.podman.io/buildah/copier). go.podman.io/buildah/copier — < 1.43.4 and >= 1.44.0, < 1.45.1. |
| Fixed Versions | buildah 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 / Exposure | Not 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 Footprint | Only 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. |
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 cpagainst 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.
What to do — in priority order.
- 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. - Restrict podman cp to trusted sources only — Advise macOS Podman users to never run
podman cpagainst untrusted or third-party Podman service endpoints. This is the primary real-world vector. Document this in your developer security guidelines. - Audit Go SBOM for copier imports — Run
go mod graph | grep buildah/copieracross your Go codebases to identify any applications importing the vulnerable library outside of buildah itself. Prioritize updating those applications. - 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.
- 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.
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
#!/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 ;;
esacWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.