CVE-2026-32288

What it actually does

This vulnerability affects Go's standard library tar archive reader. When software using archive/tar processes a malicious tar file containing an extremely large number of sparse regions encoded using the old GNU sparse map format, tar.Reader can allocate memory without a practical upper bound. The result is resource exhaustion, typically excessive memory consumption, process termination by the operating system, container eviction, or service instability. The flaw does not directly enable code execution, data theft, or data modification; its primary impact is availability loss in applications that parse attacker-supplied or otherwise untrusted tar archives.

Why it matters to the business

Applications, build systems, CI/CD workers, artifact scanners, backup/import tools, container or package processing services, and user-facing upload workflows that rely on Go's tar handling may be crashed or degraded by a crafted archive. Because exploitation requires the vulnerable software to open or inspect a malicious archive, the most likely business impact is denial of service against batch jobs, upload pipelines, scanning systems, or backend workers rather than direct compromise. EPSS is currently low and there is no known KEV or ransomware association, but the issue can still be operationally significant wherever untrusted archives are processed at scale.

How an attack unfolds

An attacker creates a tar archive that uses the old GNU sparse map format and includes an intentionally excessive number of sparse region entries. The attacker then places that archive where vulnerable Go-based software will process it, such as an upload endpoint, artifact repository, CI job input, package ingestion pipeline, backup restore workflow, malware scanner, or local file-processing workflow. When the application invokes Go's archive/tar Reader on the archive, the reader attempts to parse the sparse map and allocates memory proportional to the attacker-controlled sparse region count. If limits are not enforced by the application or runtime environment, memory usage can grow until the process becomes unresponsive, crashes, is killed by the kernel or container runtime, or causes broader node-level resource pressure.

How to fix it

Upgrade to a Go release that includes the fix for this issue once available from the Go project or your operating system/package vendor. Because no fixed versions were provided in the input, track the official Go security advisory and vendor backports for the exact patched versions. Rebuild and redeploy all Go binaries that statically include the standard library after upgrading the Go toolchain; simply updating the compiler on disk does not patch already-built binaries. As interim mitigations, avoid processing untrusted tar files, reject or quarantine tar archives using GNU sparse formats if not required, impose strict maximum archive size, maximum file count, maximum sparse region count, and maximum memory/CPU limits, process archives in isolated sandboxes with cgroup/container memory limits, and apply timeouts and worker recycling for archive-processing jobs.

How to confirm the fix worked

Confirm exposure by identifying Go-based applications and tools that parse tar archives, especially upload handlers, import/export features, artifact processors, container/package tooling, CI/CD workers, backup systems, and security scanners. Verify the Go version used to build deployed binaries using build metadata where available, such as `go version -m <binary>`, SBOMs, build manifests, or CI build logs. After upgrading, rebuild affected binaries and confirm they were built with a patched Go toolchain or vendor-backported package. Functional validation should include processing a benign tar archive and, in a controlled non-production environment, a stress-test archive with excessive old GNU sparse entries to verify the process rejects the archive or remains within expected memory limits. Also validate that runtime memory limits, upload size limits, archive parser limits, and monitoring alerts are in place.

Typical attack path

1. Identify a target workflow that processes tar archives using Go's archive/tar package or a Go-based tool that depends on it.
2. Craft a tar archive containing many sparse regions encoded in the old GNU sparse map format.
3. Deliver the archive through a supported input path, such as upload, import, package submission, CI artifact, backup restore, or local user action.
4. Wait for the vulnerable service, worker, or tool to parse the archive with tar.Reader.
5. Trigger excessive memory allocation during sparse map parsing.
6. Cause process crash, worker failure, container eviction, job failure, or service degradation.

How to detect it

Look for evidence of denial-of-service activity around archive-processing workflows. Useful log sources include application logs for upload/import/extraction errors, CI/CD job logs, artifact repository logs, backup/restore logs, container runtime events, system logs, kernel OOM logs, Kubernetes events, EDR process telemetry, and reverse proxy or object-storage access logs showing tar file submissions. Investigate cases where Go-based processes show sudden memory growth, are terminated by the operating system, or repeatedly crash shortly after handling tar archives. Correlate OOM or crash events with recent uploads or downloads of `.tar`, `.tar.gz`, `.tgz`, `.tar.bz2`, `.tar.xz`, or other tar-derived files. For forensic triage, inspect suspicious archives for GNU sparse entries, unusually large sparse region counts, or tar member typeflag `S` associated with GNU sparse files. There are no public named threat actors, KEV listing, ransomware usage, or mature exploit indicators provided, so detection should focus on behavioral signs of resource exhaustion and archive artifacts rather than actor-specific infrastructure.

• Out of memory: Killed process
• oom-kill
• Memory cgroup out of memory
• OOMKilled
• signal: killed
• exit code 137
• archive/tar
• GNU sparse
• old GNU sparse
• GNUSparse
• typeflag S
• .tar
• .tar.gz
• .tgz
• .tar.bz2
• .tar.xz

What your security team should do

• Inventory Go-based services and tools that process tar archives from users, partners, build pipelines, artifact repositories, backups, or external sources.
• Prioritize systems where archive processing is internet-facing, unauthenticated, automated, or part of critical CI/CD or artifact ingestion workflows.
• Monitor the official Go security advisory and vendor channels for fixed versions, then upgrade the Go toolchain and rebuild affected binaries.
• Apply compensating controls immediately: archive size limits, sparse-format rejection where feasible, memory limits, timeouts, sandboxing, and worker isolation.
• Add detection for abnormal memory growth, out-of-memory kills, repeated archive-processing crashes, and failed jobs correlated with newly submitted tar files.
• Quarantine and preserve suspicious tar files that caused crashes or memory spikes for forensic review.
• Document which products and internal tools embed Go standard library archive handling so future Go standard library advisories can be triaged quickly.