CVE-2025-58058

What it actually does

In ulikunitz/xz before 0.5.14, the LZMA decoder allocates the full decode buffer immediately after parsing the stream header. LZMA headers have no magic number or checksum, so bytes placed in front of a valid or crafted LZMA stream are not rejected at header-parse time. A header that advertises a large dictionary or buffer therefore causes a large allocation before the decoder later fails while reading the body, producing unbounded or excessive memory use in any process that decompresses untrusted xz/LZMA input with this library. Confidentiality and integrity are unaffected; impact is availability only.

Why it matters to the business

Services that decompress untrusted xz or LZMA data with this Go module can suffer memory spikes, out-of-memory crashes, restarts, or reduced capacity. There is no data-theft or tampering impact. Likelihood is low: EPSS is about 0.43% with only a slight 30-day rise, the issue is not in CISA KEV, it is not associated with ransomware, exploit maturity is none, and it has been public for over a year. Residual risk remains for any Go application or downstream module that still vendors a vulnerable ulikunitz/xz until it is upgraded and rebuilt.

How an attack unfolds

An unauthenticated attacker who can get a vulnerable application to decompress attacker-controlled xz or LZMA bytes supplies a stream whose LZMA header fields imply a large decoding buffer, optionally with extra data prepended so the header is still accepted. The library allocates the full buffer on header read and only later detects that the stream is invalid. One oversized allocation or repeated submissions can exhaust process or host memory and stall or crash the service. No privileges or user interaction are required if the application already decompresses untrusted input. There are no named threat actors or known in-the-wild campaigns for this CVE.

How to fix it

Upgrade github.com/ulikunitz/xz to 0.5.14 or later (fix commit 7184815834c4777e8fa665946721d5fe114c2c35), update go.mod/go.sum, and rebuild all binaries and container images that embed the module. Inventory Go services and transitive dependents that import ulikunitz/xz and pin the patched version. Until rebuilt, constrain untrusted compressed input size, apply process memory limits (cgroups, GOMEMLIMIT, ulimits), and avoid decompressing untrusted xz/LZMA with the vulnerable library.

How to confirm the fix worked

Confirm go.mod and go.sum require github.com/ulikunitz/xz at 0.5.14 or later, or that the module resolves to commit 7184815834c4777e8fa665946721d5fe114c2c35. Run govulncheck or equivalent SCA against source and built binaries. Inspect deployed images and GOPATH/pkg module caches for older versions. After upgrade, decompress oversized and header-malformed LZMA samples in a staging environment and verify memory stays bounded and the decoder rejects bad headers without a large allocation.

Typical attack path

1. Find an application, API, or tool that decompresses xz or LZMA using ulikunitz/xz older than 0.5.14.
2. Prepare an LZMA stream whose header requests a large decode buffer, with optional leading bytes that are not rejected at header parse.
3. Deliver that stream on any path the application decompresses (upload, archive, message, or network payload).
4. Cause the library to parse the header and allocate the full buffer before the stream is rejected.
5. Repeat or size the allocation until the process is memory-starved, restarted, or taken offline.

How to detect it

There is no public exploit and no named actor activity, so confirmed compromise is unlikely; look for availability artifacts rather than a unique payload. Review process and host metrics for sudden RSS/heap growth or OOM kills in Go services that decompress xz/LZMA around the time of untrusted uploads or archive processing. Check application and runtime logs for LZMA/xz decode failures that follow a large allocation, container OOMKilled events, and Kubernetes/node memory pressure. Compare those events to inbound compressed objects. Absence of distinctive malware artifacts means memory and decode-error correlation is the practical hunt.

What your security team should do

• Inventory all Go modules, binaries, and images that import github.com/ulikunitz/xz and flag versions before 0.5.14.
• Upgrade to 0.5.14 (commit 7184815834c4777e8fa665946721d5fe114c2c35), rebuild, and redeploy as a standard patch cycle—this is not a KEV emergency.
• Enforce SCA/govulncheck gates so vulnerable ulikunitz/xz cannot re-enter CI.
• Apply memory limits and compressed-input size caps on any service that still decompresses untrusted xz/LZMA.
• Prioritize internet-facing decompress paths first; treat internal batch tools as lower urgency given low EPSS and no known exploitation.