A slow SSH login exposed a years-long backdoor in xz Utils

What happened

On 29 March 2024, Microsoft engineer Andres Freund posted to the oss-security mailing list describing how he had traced unusual behavior, SSH logins taking noticeably longer than expected and unexplained valgrind errors, to a compromised version of liblzma, the compression library underlying xz Utils. His investigation found that release tarballs for xz Utils versions 5.6.0 and 5.6.1, but not the project's public git repository, contained an obfuscated build step that modified specific functions in the compiled library.

The CISA alert published the same day assigned the tracking designation CVE-2024-3094 and recommended downgrading to the prior stable release, 5.4.6. Red Hat's advisory rated the flaw critical, with a CVSS score of 10.0, and clarified that no released version of Red Hat Enterprise Linux was affected because the compromised versions had only reached pre-release and rolling distributions such as Fedora Rawhide. Because liblzma is a dependency of systemd, which in turn many Linux distributions link into OpenSSH, the compromised library had a pathway into the authentication process on affected systems.

Confidence and limits

The technical description here draws on the discoverer's own account, an official government alert issued the same day, and a vendor advisory, all of which agree on the affected versions and the general mechanism of activation through the tarball build process rather than the source repository. These documents describe what the backdoor did to the build process at a level sufficient for defenders to identify affected systems; they do not, and this article does not, describe the specific triggering conditions or payload behavior in operational detail. Attribution of who introduced the code, developed over a period of contribution to the project, is not established in the documents reviewed here.

Why it mattered

The compromise reached widely used pre-release Linux distributions only weeks before it might have propagated into stable releases used across enterprise and cloud infrastructure, and it was caught because one engineer investigated a performance regression rather than because any scanning tool flagged it. It demonstrated that trust in open-source supply chains rests partly on the assumption that long-term, seemingly legitimate contributors remain trustworthy, an assumption that is difficult to verify at scale and that this incident shows can be patiently exploited.

Defensive takeaway

Verify that production systems build from pinned, checksummed release artifacts or, where feasible, directly from source-controlled history rather than opaque release tarballs, and treat unexplained performance regressions in security-relevant paths such as SSH as worth investigating rather than dismissing.

• Do we know which of our systems depend on xz Utils or liblzma, directly or transitively through systemd?
• Would an unexplained CPU or latency anomaly in an authentication path reach someone empowered to investigate it, as happened here?
• Do we distinguish, in our own build pipelines, between a project's source history and the release artifacts we actually consume?

The xz Utils backdoor is most useful to defenders not as a story about a uniquely clever attacker, but as a reminder that patient, low-visibility manipulation of a trusted maintenance relationship can be more durable than any single exploit, and that catching it depended on ordinary engineering curiosity rather than a security control.