CVE-2025-58058: Github.com/ulikunitz/xz Github.com/ulikunitz/xz Leaks Memory When Decoding Vulnerability

MODERATE
Advisory Identifier: GHSA-jc7w-c686-c4v9
CVSS 5.3
CWE-770
Published
Advisory Summary

CVE-2025-58058 is a MODERATE (CVSS 5.3) github.com/ulikunitz/xz leaks memory when decoding vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Github.com/ulikunitz/xz libraries in the Go ecosystem. The issue involves github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple lzma archives. Remediation is available by upgrading affected packages to version 0.5.15.

CVE-2025-58058 at a Glance

CVE Identifier CVE-2025-58058
GHSA Identifier GHSA-jc7w-c686-c4v9
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product Github.com/ulikunitz/xz
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix CVE-2025-58058

To remediate this vulnerability, upgrade all affected Github.com/ulikunitz/xz dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/ulikunitz/xz fixed: 0.5.15
Upgrade github.com/ulikunitz/xz to 0.5.15
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/ulikunitz/xz

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-58058, inspect your project dependencies for Github.com/ulikunitz/xz:

inspect dependencies for github.com/ulikunitz/xz

Analyze the terminal output to locate any version of Github.com/ulikunitz/xz in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.5.15), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Github.com/ulikunitz/xz, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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

CVE-2025-58058 Affected Github.com/ulikunitz/xz Versions

1 component(s)
Fixed Versions:
0.5.15
Product / Package Ecosystem Affected Versions Fixed Version
github.com/ulikunitz/xz
Go
< 0.5.15
0.5.15

References

Frequently Asked Questions

What is CVE-2025-58058?
CVE-2025-58058 is a security vulnerability in Github.com/ulikunitz/xz involving github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives under CWE-770: Allocation of Resources Without Limits or Throttling.
Which Github.com/ulikunitz/xz versions are affected?
Affected versions include releases prior to 0.5.15 across affected packages: github.com/ulikunitz/xz.
What version fixes CVE-2025-58058?
Upgrading to 0.5.15 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/ulikunitz/xz affected?
Yes, github.com/ulikunitz/xz is affected in releases prior to 0.5.15. Upgrade your dependency to 0.5.15 or later.
What is the CVSS score of CVE-2025-58058?
CVE-2025-58058 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2025-58058?
CVE-2025-58058 is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check Go dependencies for CVE-2025-58058?
Run the dependency tree command: 'inspect dependencies for github.com/ulikunitz/xz'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-jc7w-c686-c4v9",
  "modified" : "2025-08-29T20:25:38Z",
  "published" : "2025-08-28T19:36:22Z",
  "aliases" : [ "CVE-2025-58058" ],
  "summary" : "github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives",
  "details" : "### Summary\n\nIt 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).\n\nNote that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.\n\n### Mitigations\n\nThe release v0.5.15 includes following mitigations:\n\n- The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.\n- The default is 2 Gigabytes - 1 byte (2^31-1 bytes).\n- Users can check with the [Reader.Header] method what the actual values are in  their LZMA files and set a smaller limit using ReaderConfig.\n- 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.\n- The code supports stream sizes only up to a pebibyte (1024^5).\n\nNote that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.\n\n### Methods affected\n\nOnly 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.\n\nI thank  @GregoryBuligin for his report, which is provided below.\n\n### Summary\nWhen 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.\n\n### Details\nJudging by the error  __writeMatch: distance out of range__, the problems occur in the code around this function.\nhttps://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81\n\n### PoC\nRun 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.\n```\nconst ProjectLocalPath = \"some/path\"\nconst TmpDir = \"tmp\"\n\nfunc UnpackLZMA(lzmaFile string) error {\n\tfile, err := os.Open(lzmaFile)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer file.Close()\n\n\treader, err := lzma.NewReader(bufio.NewReader(file))\n\tif err != nil {\n\t\treturn err\n\t}\n\n\ttmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer func() {\n\t\ttmpFile.Close()\n\t\t_ = os.Remove(tmpFile.Name())\n\t}()\n\n\tsha256Hasher := sha256.New()\n\tmultiWriter := io.MultiWriter(tmpFile, sha256Hasher)\n\n\tif _, err = io.Copy(multiWriter, reader); err != nil {\n\t\treturn err\n\t}\n\n\tunpackHash := hex.EncodeToString(sha256Hasher.Sum(nil))\n\tunpackDir := filepath.Join(\n\t\tProjectLocalPath, unpackHash[:2],\n\t)\n\t_ = os.MkdirAll(unpackDir, DirPerm)\n\n\tunpackPath := filepath.Join(unpackDir, unpackHash)\n\n\treturn os.Rename(tmpFile.Name(), unpackPath)\n}\n```\n\n\n\n### Impact\nServers with a small amount of RAM that download and unpack a large number of unverified LZMA archives",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/ulikunitz/xz"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.5.15"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.5.13"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-58058"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/ulikunitz/xz/commit/88ddf1d0d98d688db65de034f48960b2760d2ae2"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/ulikunitz/xz"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-08-28T19:36:22Z",
    "nvd_published_at" : "2025-08-28T22:15:32Z"
  }
}