The xz backdoor, CVE-2024-3094, was reported on 29 March 2024 by Andres Freund after he noticed odd symptoms on Debian sid systems: SSH logins using a lot of CPU and valgrind errors. A failed login took about 0.8 seconds instead of about 0.3. That gap led him to liblzma. Nobody's scanner found it first.
What he saw
In his post to the oss-security mailing list, Freund describes weeks of strange behaviour. sshd was burning CPU on login attempts, and valgrind complained about memory problems. He traced both to the liblzma library in xz.
In one test, a failed SSH login took roughly 0.8 seconds with the affected library and roughly 0.3 seconds before. Half a second sounds trivial. On a system that handles many logins, it was a visible anomaly worth chasing.
What he found
The affected releases were xz 5.6.0 and 5.6.1. Freund's analysis says obfuscated files sat in the repository's test directory, unused by any test in 5.6.0. A script hidden in a build macro file ran at the end of configure, decoded that data and executed it. The malicious portion existed only in the distributed release tarballs, not in the upstream repository's visible source in the same form.
The injected code only activated under certain conditions: x86-64 Linux, GCC with the GNU linker, and a Debian or RPM package build. It then hooked the dynamic linker and redirected a function in sshd's public key authentication path.
Freund notes that OpenSSH does not use liblzma directly. Builds of sshd that link libsystemd load it indirectly. He believed the code likely ran before authentication and could allow unauthorized access, though he had not finished analysing it at the time of writing.
How the report travelled
He sent a preliminary report to the Debian security team, then to the distros list, and then posted publicly. CISA was notified by a distribution. CISA's alert named 5.6.0 and 5.6.1 as affected and advised downgrading to an uncompromised version such as 5.4.6 Stable, hunting for malicious activity and reporting positive findings.
What this suggests for your own monitoring
- Performance is a signal. Unexplained CPU use or latency in an authentication path deserves an investigation, even when nothing alerts.
- Pre-release channels get hit first. Freund's post says these versions had not been widely adopted by distributions and mostly appeared in pre-release versions. Fewer users on the newest version limited the damage.
- Tarballs can differ from repositories. Builds that consume release archives see different content than a review of the repository does. Where you can, build from a verified source and compare.
- Know your base images. If you cannot say which version of a core library is in each image, you cannot answer a question like "are we on 5.6.0?" quickly.
Safeguard's SBOM and dependency scanning can show which projects and images carry a given library version, which turns that question into a lookup. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Which xz versions were affected?
5.6.0 and 5.6.1, according to the oss-security post and CISA's alert.
Why did a compression library matter to SSH?
OpenSSH does not use liblzma directly, but builds of sshd linked with libsystemd load it indirectly, per Freund's analysis.
Sources
Last reviewed: 19 October 2026.
