The XZ backdoor CVE-2024-3094 deep dive

On March 29, 2024, PostgreSQL developer and Microsoft engineer Andres Freund reported something odd on the oss-security mailing list: SSH logins on a Debian sid box were taking about 500 milliseconds longer than expected, and sshd processes were burning unusual amounts of CPU under valgrind. That report turned into one of the most consequential software supply chain findings in the industry's history — a multi-year, state-actor-grade operation that planted a remote code execution backdoor directly inside liblzma, the compression library bundled with xz-utils and linked, on many Linux distributions, into sshd itself. The vulnerability was assigned CVE-2024-3094 and scored a maximum CVSS 10.0. Had it shipped into stable production distributions rather than being caught in rolling-release testing, it would have granted whoever held the attacker's private key silent, authentication-bypassing SSH access to a meaningful share of the world's Linux server fleet.

This is a rare case where the "what if" is not hypothetical exaggeration. The backdoor was fully functional, deliberately obfuscated to survive code review, and inserted by a contributor who had spent roughly two years building trust and social-engineering their way into co-maintainer status. It is the clearest public example to date of a targeted, patient supply chain compromise of open source infrastructure — and it is exactly the class of threat that reachability analysis, provenance verification, and SBOM-driven monitoring exist to catch.

Affected Versions and Components

The backdoor lives specifically in liblzma versions 5.6.0 (released February 24, 2024) and 5.6.1 (released March 9, 2024), part of the xz-utils package. It does not affect the broader xz history before or after that narrow window — the maintainers reverted to a clean 5.4.x-derived line and later shipped a verified-clean 5.6.2.

Critically, liblzma itself is not the exploitation vector for most systems. The backdoor's real target is sshd. On distributions that patch OpenSSH to support systemd's socket-activation notification protocol, sshd ends up linking against libsystemd, which in turn links against liblzma for compression support. That chain — sshd → libsystemd → liblzma — is what let a compression library reach into the authentication path of the SSH daemon. Upstream OpenSSH itself does not use systemd-notify and does not link liblzma, so vanilla OpenSSH builds, macOS, and BSD systems were never exposed by this vector.

In practice, exposure was concentrated in rolling and bleeding-edge distributions that had already pulled the poisoned releases: Fedora 41 and Fedora 40 (beta/rawhide builds), Debian unstable and testing (sid/trixie), openSUSE Tumbleweed and MicroOS, and briefly Kali Linux and some Arch Linux installations. Long-term-support and stable production distributions — RHEL, Ubuntu LTS, Debian stable, Amazon Linux — were not affected in their released form, simply because the 5.6.x branch had not yet propagated to them. That timing, not any inherent safety in those distros, is what limited the blast radius.

Severity: CVSS, EPSS, and KEV Context

NVD and Red Hat both rated CVE-2024-3094 at CVSS 10.0, the maximum possible score — appropriate given the outcome: unauthenticated remote code execution via SSH, requiring only that the attacker hold a specific Ed448 private key embedded in the backdoor's design. There is effectively no meaningful "partial" version of this vulnerability; if the poisoned binary was in the authentication path, the attacker had a skeleton key.

EPSS scoring on this CVE is an unusually poor proxy for real-world risk and is worth calling out explicitly, because it illustrates a broader limitation of exploit-prediction models. EPSS is trained on observed exploitation patterns and public exposure signals; CVE-2024-3094 had neither, because the backdoor was discovered and neutralized before it ever reached a production-stable distribution and before any confirmed in-the-wild exploitation surfaced. Teams that rely solely on EPSS thresholds to triage patching priority would have deprioritized this finding right up until the disclosure made it front-page news — a good illustration of why supply chain risk needs provenance and reachability signals, not just historical exploitation statistics.

As of this writing, CVE-2024-3094 has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, because no confirmed exploitation was observed; the compromise was intercepted during the "testing/staging" phase of its rollout. CISA nonetheless issued an emergency advisory within 24 hours of disclosure directing agencies to downgrade affected systems, and OpenSSF, Red Hat, and major cloud providers followed with their own urgent guidance — a response tempo normally reserved for actively exploited zero-days, reflecting how close this came to a catastrophic outcome.

Timeline of the Attack

• 2021–2022 — An account using the name "Jia Tan" (GitHub handle JiaT75) begins submitting patches to the xz-utils project. Around the same time, sockpuppet accounts (including "Jigar Kumar" and "Dennis Ens") begin pressuring original maintainer Lasse Collin on mailing lists, complaining about slow response times and pushing for a co-maintainer to be added.
• 2022–2023 — Jia Tan's contributions increase in scope and trust. Collin, dealing with personal burnout and the social pressure, grants Jia Tan commit access and eventually co-maintainer status on the project.
• February 24, 2024 — liblzma 5.6.0 ships with the backdoor for the first time, hidden across a multi-stage chain: binary test files disguised as corrupt compression test cases, and obfuscated modifications to the m4/build-to-host.m4 autoconf macro and build-to-host.m4/Makefile.am build scripts that only activate the payload during a .deb/.rpm-style build, not from a clean git checkout.
• March 9, 2024 — liblzma 5.6.1 ships with a refined, more evasive version of the backdoor.
• March 28, 2024 — Andres Freund notices anomalous SSH login latency and elevated CPU usage on a Debian sid system he maintains, and traces it through valgrind to symbol resolution errors inside liblzma.
• March 29, 2024 — Freund posts full technical findings to the oss-security mailing list. CVE-2024-3094 is assigned within hours. Distribution maintainers begin emergency reverts; GitHub temporarily disables the xz-utils repository pending investigation.
• March 29 – April 2024 — The security community reverse-engineers the full payload: an IFUNC-based hook that intercepts RSA_public_decrypt-adjacent authentication logic in sshd, checking incoming certificate-like payloads against an embedded Ed448 public key and, on match, permitting arbitrary command execution or authentication bypass before normal SSH auth completes.
• Ongoing — Investigations into the identity and backing of "Jia Tan" continue; the operational sophistication, patience, and tradecraft (multi-year trust-building, anti-analysis timing checks, disabling of certain sanitizer and fuzzing hooks) are widely assessed as consistent with a well-resourced, likely state-linked actor, though attribution remains unconfirmed.

Remediation Steps

1. Inventory first. Query your SBOM or package manifests across all hosts, containers, and CI/CD images for xz/liblzma versions 5.6.0 and 5.6.1 specifically. Don't stop at the base OS — check golden images, builder containers, and any vendored/statically linked copies.
2. Downgrade or update. Roll back to a known-clean liblzma build — most distributions reverted to a 5.4.x-derived package — or move to the verified-clean 5.6.2+ release once your distribution has re-published it. Follow your distro's specific advisory (Red Hat, Debian, Fedora, SUSE, and Kali all published guidance within days of disclosure).
3. Rebuild and restart affected services. Simply updating the package on disk is not enough — sshd and any other long-running process that dynamically linked the poisoned library must be restarted so it loads the patched binary.
4. Audit the exposure window. For any host that ran 5.6.0 or 5.6.1 between late February and March 29, 2024, treat SSH access during that window as potentially untrustworthy. Review auth logs for anomalous latency patterns, unexpected certificate-based auth attempts, or connections from unfamiliar sources.
5. Rotate credentials as a precaution on systems confirmed to have run the affected build in a production or internet-facing context, even absent direct evidence of compromise — the backdoor was designed to leave minimal forensic trace.
6. Re-verify build provenance for any artifacts, containers, or packages compiled during the exposure window on affected build hosts, since a compromised builder could taint downstream artifacts beyond the direct liblzma dependency.
7. Harden the supply chain going forward: pin dependency versions rather than tracking latest, prefer distro-maintained stable packages over rolling releases for production, and push for reproducible builds so that binary artifacts can be independently verified against source.

How Safeguard Helps

CVE-2024-3094 is the textbook case for why "is this CVE present" is the wrong question and "is this vulnerable code path actually reachable and exploitable in my environment" is the right one — Safeguard's reachability analysis pinpoints whether the affected liblzma-to-sshd linkage chain actually exists in your build, cutting through the noise for the vast majority of environments that were never truly exposed. Our SBOM generation and ingestion pipeline continuously fingerprints exact package versions — including the narrow 5.6.0/5.6.1 window — across containers, VMs, and CI artifacts, so you get an authoritative exposure inventory in minutes instead of days of manual grepping. Griffin, Safeguard's AI security analyst, correlates that exposure against maintainer-trust and provenance signals in real time, flagging suspicious commit patterns and dependency changes before they reach the kind of trust erosion that let "Jia Tan" operate undetected for years. When remediation is needed, Safeguard's auto-fix PRs open the version bump or downgrade directly against your affected manifests and lockfiles, so the fix ships as fast as the advisory does. Together, this turns a scramble that took the broader industry days to fully scope into something Safeguard customers can answer with confidence in a single dashboard query.