ZombieMutex / Security research / Technical write-up
CVE-2024-3094 — xz Utils source-tarball backdoor
xz Utils · xz/liblzma · Supply chain
My engineering notes on a third-party disclosed vulnerability. I didn't discover this CVE or test it against a real target. Source-backed facts are distinguished from defensive recommendations and conceptual models.
01 / Description
What happened
Malicious code was inserted into xz 5.6.0 and 5.6.1 upstream release tarballs. The altered build flow could introduce a backdoored liblzma library under particular integration conditions.
xz is a good reminder that a dependency can be compromised before your application ever runs. In this case, malicious material was introduced into upstream xz release tarballs and the build process could assemble a modified liblzma. A version number without its source and build provenance isn't the full story.
The part I'd remember
The release artifact, build path and downstream linkage determine exposure. I wouldn't call every Linux installation vulnerable just because it has xz.
02 / Severity
Metrics
CVSS v3.1 base score
10.0 / 10
Severity
Critical
Score source
Red Hat
CVSS 3.1 vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HScore and vector attributed to Red Hat's CVSS v3.1 assessment. Impact depends on affected distribution and integration circumstances.
Not marked as KEV in this editorial snapshot. Absence from the catalog is not proof of no exploitation.
03 / Affected scope
Known affected software
The malicious release tarballs for xz 5.6.0 and 5.6.1; presence in a system or exposure depends on package source, build integration, and distribution. A curated, source-attributed overview—not a complete CPE inventory or version classifier.
| Product / branch | Condition / fix | Status |
|---|---|---|
| xz 5.6.0 / 5.6.1 upstream tarballs | Compromised release tarball content; the malicious build behavior depends on the build integration. | Affected |
| Downstream systems | Affected only when a distribution or build includes the altered library and the relevant execution conditions. | Conditional |
| Red Hat Enterprise Linux | Red Hat states RHEL releases are not affected by this particular malicious package. | Not affected |
| Distribution-fixed builds | Use the relevant distribution security advisory and trusted artifacts; a numeric version alone is not enough. | Fixed |
For the exhaustive affected-software matrices, current hotfixes and CPE strings, use the vendor/CVE/NVD records linked below. An affected product family alone does not establish exposure.
04 / Engineering notes
How I'd think through it
01How the build became an attack surface
The malicious code lived in upstream release archives, not in an obvious application endpoint. During selected builds, obfuscated test content was used to introduce modified object code into liblzma. That compromised the software supply chain before runtime checks could even start.
A build can look perfectly normal to an application developer while carrying an altered dependency. Comparing the upstream source repository with the distributed source tarball, and understanding build scripts, is as important as scanning the final package name.
02Why the SSH discussion needs precision
The widely discussed risk involved particular combinations of liblzma, distribution packaging and SSH-related integration. It is not accurate to translate the score into 'all Linux SSH servers were backdoored.'
The distribution advisory, package origin, linked components and installed artifact digest are the evidence I compare. On a suspected affected system, The potentially compromised host is not an independent authority on its own binaries.
03The longer engineering lesson
Signed releases, reproducible builds, independent artifact checks and narrower build privileges are separate defenses. A single green build badge does not answer whether the published tarball is the same thing a reviewer saw in the source repository.
For an incident like this, my priority is evidence: which artifact went into the build, which distribution shipped it, which library was loaded and which services exercised it. The boring provenance questions are the useful ones.
05 / Classification
Weakness enumeration
- CWE-506Embedded malicious code
Weakness identifiers describe categories of mistakes, not a step-by-step exploit procedure.
06 / Evidence trail
References and further reading
These links leave ZombieMutex and point to the original vulnerability records, vendor guidance and supporting research. An outbound link is not an endorsement.
| Reference | Source / purpose |
|---|---|
| NVD vulnerability record | NVD |
| CVE record from Red Hat | CVE record |
| Red Hat analysis | Vendor |
| CVE program record | CVE · authoritative record |
What supports the conclusions
- Red Hat documented malicious code in 5.6.0/5.6.1 upstream tarballs and a build-time injection mechanism.
- Red Hat states that its RHEL versions were not affected; other distributions published their own advisories.
- This is an editorial reconstruction from public disclosures, not a reverse-engineering claim about a locally examined malicious binary.
07 / Editorial record
Scope, limitations and review history
- CVE publication
- 2024-03-29
- Editorial snapshot reviewed
- 2026-11-08
- Source score
- Red Hat · CVSS v3.1
- Research method
- Public-source analysis, not hands-on exploitation
This summary does not enumerate every distribution build or prove exposure through SSH. Consult your distribution's advisory and artifacts; a CVSS score is not a binary detection result.
This is a third-party disclosed CVE explained in my engineering notebook. I don't claim to have discovered it, tested impacted customer systems or received a bug bounty for it. Use current official vendor guidance for security decisions.
Public conversation / GitHub Discussions
Discuss this article
Read and reply using GitHub Discussions. A GitHub account is needed to post. Comments are public and subject to GitHub moderation.
For privacy, the external giscus widget does not load until you choose to open it. Opening it connects your browser to giscus and GitHub. Do not post credentials or private project data.