github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.

Source published

28 Aug 2025 21:54:05 UTC

Source modified

29 Aug 2025 13:23:07 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.

Source published

Aug 28, 2025, 9:54:05 PM (timezone not stated)

Source modified

Aug 29, 2025, 1:23:07 PM (timezone not stated)

Observed here

11 Nov 2026 03:36:12 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.

Source published

28 Aug 2025 22:15:32 UTC

Source modified

26 Sep 2026 00:10:00 UTC

Observed here

25 Oct 2026 03:17:18 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

### Summary It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the [specification](https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt). Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. ### Mitigations The release v0.5.15 includes following mitigations: - The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size. - The default is 2 Gigabytes - 1 byte (2^31-1 bytes). - Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig. - The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary. - The code supports stream sizes only up to a pebibyte (1024^5). Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15. ### Methods affected Only software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#ReaderConfig.NewReader) is affected. There is no issue for software using the xz functionality. I thank @GregoryBuligin for his report, which is provided below. ### Summary When unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error __writeMatch: distance out of range__ occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation. ### Details Judging by the error __writeMatch: distance out of range__, the problems occur in the code around this function. https://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81 ### PoC Run a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning. ``` const ProjectLocalPath = "some/path" const TmpDir = "tmp" func UnpackLZMA(lzmaFile string) error { file, err := os.Open(lzmaFile) if err != nil { return err } defer file.Close() reader, err := lzma.NewReader(bufio.NewReader(file)) if err != nil { return err } tmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix) if err != nil { return err } defer func() { tmpFile.Close() _ = os.Remove(tmpFile.Name()) }() sha256Hasher := sha256.New() multiWriter := io.MultiWriter(tmpFile, sha256Hasher) if _, err = io.Copy(multiWriter, reader); err != nil { return err } unpackHash := hex.EncodeToString(sha256Hasher.Sum(nil)) unpackDir := filepath.Join( ProjectLocalPath, unpackHash[:2], ) _ = os.MkdirAll(unpackDir, DirPerm) unpackPath := filepath.Join(unpackDir, unpackHash) return os.Rename(tmpFile.Name(), unpackPath) } ``` ### Impact Servers with a small amount of RAM that download and unpack a large number of unverified LZMA archives

Source published

28 Aug 2025 19:36:22 UTC

Source modified

10 Sep 2026 03:50:27 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Publisher rating · MODERATE

Memory leaks when decoding a corrupted multiple LZMA archives in github.com/ulikunitz/xz

Source published

17 Sep 2025 17:03:38 UTC

Source modified

4 Feb 2026 03:52:11 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.