CVE-2025-58058: xz Golang Package DOS Vulnerability

CVE-2025-58058 Overview

CVE-2025-58058 affects github.com/ulikunitz/xz, a pure Go package for reading and writing xz-compressed files. Prior to version 0.5.14, the LZMA header parser fails to detect data prepended to an LZMA-encoded byte stream. Because the LZMA header format lacks a magic number or checksum, the library cannot distinguish valid streams from crafted input during header parsing. The implementation allocates the full decoding buffer immediately after reading the header, so an attacker-supplied dictionary size drives memory consumption before the malformed stream is detected. The flaw is classified as [CWE-770] Allocation of Resources Without Limits or Throttling.

Critical Impact
Attackers can trigger excessive memory allocation by supplying crafted LZMA input, leading to denial of service in applications that decompress untrusted data.

Affected Products

github.com/ulikunitz/xz versions prior to 0.5.14
Go applications embedding the lzma subpackage for decompression
Downstream tooling relying on pure-Go xz/LZMA decoding

Discovery Timeline

2025-08-28 - CVE-2025-58058 published to NVD
2025-08-28 - GitHub Security Advisory GHSA-jc7w-c686-c4v9 published
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-58058

Vulnerability Analysis

The ulikunitz/xz library exposes an LZMA decoder that reads a 13-byte header containing properties, dictionary size, and uncompressed size fields. The decoder immediately allocates a decoding buffer sized according to the header's dictionary size field. Because the LZMA specification defines no magic bytes or header checksum, the parser cannot validate whether the leading bytes belong to a legitimate LZMA stream. An attacker can prepend arbitrary data to an LZMA stream, and the decoder will interpret those bytes as header fields and allocate memory accordingly.

Root Cause

The root cause is unbounded resource allocation driven by untrusted input. The decoder trusts the dictionary size field in the header and allocates memory before validating the remainder of the stream. Stream corruption is detected only after allocation completes, making early rejection impossible. This maps directly to [CWE-770].

Attack Vector

An attacker delivers a crafted byte sequence to any service that decompresses LZMA or xz data through ulikunitz/xz. Typical exposure includes package managers, artifact stores, log processors, and network protocol handlers that accept compressed payloads. Repeated decode requests can exhaust process or host memory.

// Security patch in lzma/header.go - GHSA-jc7w-c686-c4v9
// HeaderLen provides the length of the LZMA file header.
const HeaderLen = 13

-// header represents the header of an LZMA file.
-type header struct {
-	properties Properties
-	dictCap    int
-	// uncompressed size; negative value if no size is given
-	size int64
+// Header represents the Header of an LZMA file.
+type Header struct {
+	Properties Properties
+	DictSize   uint32
+	// uncompressed Size; negative value if no Size is given
+	Size int64
}

// marshalBinary marshals the header.
-func (h *header) marshalBinary() (data []byte, err error) {
-	if err = h.properties.verify(); err != nil {
+func (h *Header) marshalBinary() (data []byte, err error) {
+	if err = h.Properties.verify(); err != nil {
 		return nil, err
 	}
-	if !(0 <= h.dictCap && int64(h.dictCap) <= MaxDictCap) {
+	if !(h.DictSize <= MaxDictCap) {
 		return nil, fmt.Errorf("lzma: DictCap %d out of range",
-			h.dictCap)
+			h.DictSize)
 	}
// Source: https://github.com/ulikunitz/xz/commit/88ddf1d0d98d688db65de034f48960b2760d2ae2

The patch replaces the signed dictCap int field with an unsigned DictSize uint32 bounded by MaxDictCap, and hardens header validation to reject prepended data before allocation occurs.

Detection Methods for CVE-2025-58058

Indicators of Compromise

Sudden spikes in resident memory of Go services that decompress user-supplied archives
Repeated out-of-memory (OOM) kills or process restarts tied to decompression workers
Inbound requests carrying LZMA or xz payloads with abnormal byte patterns preceding the header

Detection Strategies

Perform software composition analysis (SCA) on Go modules to flag github.com/ulikunitz/xz versions below 0.5.14 in go.sum and vendored dependency trees
Instrument decompression code paths to record input length, declared dictionary size, and allocation size for anomaly review
Correlate application OOM events with recent inbound payloads containing LZMA magic patterns

Monitoring Recommendations

Track process memory and allocation rates for services accepting compressed uploads
Alert on decompression errors that follow large buffer allocations in the same request
Log dependency inventories continuously and re-scan after each build to catch regressions to vulnerable versions

How to Mitigate CVE-2025-58058

Immediate Actions Required

Upgrade github.com/ulikunitz/xz to version 0.5.14 or later across all Go projects and rebuild affected binaries
Inventory transitive dependencies using go list -m all and patch any indirect references to vulnerable versions
Apply request size limits and decompression quotas at ingress points that accept compressed data

Patch Information

The fix is available in ulikunitz/xz version 0.5.14. The remediation commit 88ddf1d0d98d688db65de034f48960b2760d2ae2 restructures the LZMA header type, bounds DictSize with MaxDictCap, and rejects streams with unexpected leading bytes before allocation. Full advisory details are available in GHSA-jc7w-c686-c4v9.

Workarounds

Cap the maximum size of decompressed input using a bounded io.LimitReader before passing data to the LZMA decoder
Isolate decompression workers in memory-constrained containers or cgroups to contain allocation abuse
Reject archives from untrusted sources until dependencies are upgraded to 0.5.14 or later

bash

# Upgrade the vulnerable module to the fixed version
go get github.com/ulikunitz/xz@v0.5.14
go mod tidy

# Verify no vulnerable versions remain in the dependency graph
go list -m all | grep ulikunitz/xz