github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| ulikunitz | xz | affected |
|
No data.
No data.
No data available yet.
| Source | ID | Title |
|---|---|---|
EUVD |
EUVD-2025-26149 | github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives |
Github GHSA |
GHSA-jc7w-c686-c4v9 | github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.433% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives | |
| Weaknesses | CWE-770 | |
| References |
| |
| Metrics |
cvssV3_1
|
No data.