CVE-2024-3094: XZ Utils backdoor

CVE-2024-3094 backdoored XZ Utils 5.6.0–5.6.1 release builds. See how liblzma injection affected some Linux SSH builds and how to verify vendor fixes.^{[2], [4], [3], [1]}

CVSS vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H^[5]

💡 Plain English Explainer (ELI5)

Imagine a factory package with a hidden instruction that tells the assembly line to take a concealed part from a test kit and install it in a shipment. The machine is at risk only if its wiring connects that part to the front-door lock. In XZ Utils 5.6.0 and 5.6.1, altered release-build logic pulled hidden material from test data into liblzma; only some Linux builds connected that library to the SSH authentication path.^{[2], [4]}

Core Concepts & Subsystem Terms

Release tarball: The source archive a project publishes for each version. It can contain generated build files that are not in the git repository; the xz 5.6.0 and 5.6.1 backdoor trigger existed only there.^{[2], [4]}
Autotools m4 macro: Build logic expanded into the configure script. A modified build-to-host.m4 in the tarballs extracted hidden code from test files and injected it into liblzma during the build.^[2]
IFUNC resolver: A glibc mechanism that picks a function implementation when a library is loaded. The backdoor abused liblzma's resolvers to run early inside processes that loaded the library.^[2]
sshd linkage via libsystemd: Several distributions patch OpenSSH to call libsystemd, which loads liblzma. That indirect link let the backdoor hook sshd's RSA key verification.^{[2], [3]}

Framework mappings

CWE reference for the weakness described in this guide: CWE-506

Root Cause Analysis

CVE-2024-3094 was a deliberately planted supply-chain backdoor in XZ Utils 5.6.0 and 5.6.1. The release build path used a modified Autotools macro to extract obfuscated material from test data and inject it into liblzma. On some Linux distribution builds where OpenSSH loaded liblzma indirectly through systemd, the altered library interfered with the SSH authentication path and could enable attacker-controlled privileged access. Exposure depended on the distribution build and runtime conditions; this was not a flaw in every OpenSSH or XZ installation. The upstream 5.6.2 release removes the backdoor; operators should follow their distribution vendor’s fixed-package guidance.^{[2], [4], [3], [1]}

CVE-2024-3094 source, build, and SSH reachability matrix

Boundary to verify	What the evidence establishes	Operational response
Upstream Git source built directly	Freund reported that the injected build logic was absent from the corresponding Git source; this excludes the documented release-tarball injection path only.	Record the exact source revision and build inputs. Do not infer safety from a version label or use this fact to dismiss other supply-chain risks.
Official 5.6.0 or 5.6.1 release tarball used as a build input Freund's report	The XZ project said both release tarballs contained the backdoor. Altered build logic extracted hidden content from test data; the tarball itself was the compromised input.	Treat packages built from these archives as potentially affected until the distribution identifies their status. Follow its replacement or rollback guidance.
Distribution build linked affected liblzma into the SSH authentication path Debian advisory	Freund documented that only some distribution/build configurations connected the affected library to the SSH path. This was not a property of every XZ or OpenSSH installation.	Check the vendor’s affected-package and build guidance, then inventory the installed package and linkage for each system. Replace affected packages and investigate the exposure period.
Upstream 5.6.2 or a distribution-supported fixed package Debian advisory	Upstream 5.6.2 removes `CVE-2024-3094`; distributions may publish fixed or reverted package revisions whose numbers differ from the upstream version string.	Install the distribution-supported fixed package or roll back, verify the package revision, and retain build provenance. Assess any earlier affected exposure separately.

Step-by-Step Attack Flow

Step 1

Compromised release versions

The malicious trigger was in the 5.6.0 and 5.6.1 release-build path, not the ordinary upstream Git source tree; supporting test data was present in the repository. Do not use a version label alone as proof of artifact integrity.^{[2], [4]}

Step 2

Build-time injection

A modified Autotools macro caused obfuscated material stored among test data to be processed during configuration and incorporated into liblzma. Do not run or reproduce the extraction logic.^{[2], [4]}

Step 3

Distribution-specific linkage

On some affected Linux builds, OpenSSH loaded liblzma indirectly through systemd. This dependency path and the relevant build/runtime conditions were not universal.^{[2], [3]}

Step 4

Authentication-path compromise

Freund's initial analysis said remote code execution seemed likely, while noting that he had not yet analyzed precisely how the unauthorized access worked. Treat that as an early assessment, not proof that every system running XZ was remotely exploitable; follow distribution guidance for affected builds.^[2]

Source Code: Flaw vs. Secure Implementation

This comparison demonstrates an unsafe release-version shortcut versus detached-signature verification; neither snippet represents XZ's malicious build logic. The signature check is meaningful only when the keyring was obtained and authenticated through a separate trusted channel, and the signature and artifact are the exact vendor release pair. A verification failure must stop the pipeline. This is an artifact-integrity control, not proof that a build process or dependency chain is uncompromised; follow distribution rollback and incident guidance for affected systems. The compromised 5.6.0 and 5.6.1 release archives were official and signed, so signature verification could still pass for them. This example detects substitution only; it is not the CVE-2024-3094 remediation. Replace or roll back affected packages using distribution guidance.^{[6], [3]}

Source excerpt: Illustrative release-artifact verification; not XZ source

UNPATCHED FLAW

reported_version="$(xz --version | awk '{print $NF}')"
[ "$reported_version" = "5.6.2" ] || exit 1

HARDENED SECURE PATCH

gpgv --keyring ./trusted-release-keys.gpg \
    xz-5.6.2.tar.gz.sig xz-5.6.2.tar.gz || exit 1

Engineering & System Hardening Checklist

✓Inventory XZ Utils/liblzma package versions and distribution builds; use vendor advisories to identify exposure rather than relying on an upstream version string alone.^{[3], [4]}
✓Install the distribution-supported security update or rollback specified by the vendor; verify the installed package revision after updating.
✓Compare the installed package and distribution release with the vendor's affected-package list to determine whether the host matches the advisory.^[3]
✓For release pipelines, bind build inputs to reviewed source revisions and independently trusted signing identities; retain build provenance and compare release artifacts with their declared source.
✓Ensure test fixtures are inert in release pipelines: prohibit build scripts from interpreting fixture data, review release-only build logic, and compare published archives with their declared source.