CVE-2024-3094: the XZ Utils backdoor

02Which distributions shipped it?

The short version: almost no stable release. The backdoor was present in 5.6.0 and 5.6.1, which had mostly reached rolling-release and pre-release channels when it was caught. Stable Debian, released Ubuntu, and Red Hat Enterprise Linux were never affected.

03How the backdoor worked, conceptually

During the package build, an obfuscated script extracted machine code from a disguised test file and linked it into liblzma. At process start, before the process's relocation table (GOT) was remapped read-only, the code installed a hook into the dynamic linker and waited for a specific cryptographic routine in sshd to be resolved, then redirected it to attacker-controlled code.

The result was a key-gated remote path: only a client holding the matching private key could trigger it, which is why a passer-by could not simply exploit it. The backdoor also made SSH logins measurably slower — a stray half-second — which is precisely the anomaly that led to its discovery.

04How to check if you are affected

Check the installed liblzma / xz version. If it is in the 5.6.0–5.6.1 range on an affected distribution, treat the host as compromised rather than merely vulnerable, because a backdoor may have been used and a version downgrade alone does not prove the system is clean.

# Debian/Ubuntu/Kali: library and tool versions
apt-cache policy liblzma5          # look for an installed 5.6.0 / 5.6.1
dpkg-query -W -f='${Package} ${Version}\n' liblzma5 xz-utils

# Any distro: does sshd even link liblzma on this box?
ldd "$(command -v sshd)" | grep -E 'liblzma|libsystemd'

# RPM-based systems
rpm -q xz xz-libs
xz --version                       # 5.6.0 or 5.6.1 = backdoored release

05How to remediate

The fix is to get off 5.6.0/5.6.1 and back onto the 5.4 series, which carries none of the malicious content. CISA's advice on 29 March 2024 was to downgrade to an uncompromised version such as XZ Utils 5.4.6 Stable, hunt for malicious activity, and report findings. Debian and openSUSE had already rolled back, and Arch had rebuilt the package from git rather than the tarball, on 28 March; the clean upstream 5.6.2 followed on 29 May 2024.

• Apply your distribution's xz / liblzma update, which reverts to 5.4.x content
• Reboot, or at minimum restart sshd and anything else linked to liblzma, so the clean library is actually loaded
• On any host that ran the backdoored version with SSH exposed, treat it as potentially compromised: rebuild rather than trust it, and rotate keys and credentials
• Audit container images and CI base images, where old backdoored layers can linger long after the host is fixed

06What a WAF can and cannot do

Nothing at the HTTP edge filters this. The malicious path is in the SSH daemon, keyed to a secret the attacker holds, and it does not traverse a web application firewall or a reverse proxy at all. There is no signature a WAF could match that would help, and any vendor claiming to "block CVE-2024-3094" at the web layer is overstating it.

The honest control set here is supply-chain discipline: pin and verify dependencies, prefer building from reviewed source over opaque release tarballs, watch for behavioural anomalies like the login slowdown that exposed this one, and keep management services such as SSH off the public internet — the same advice that limits regreSSHion — so a key-gated backdoor has no easy route in. Hiding your origin behind a proxy reduces exposure of the box; it does not touch the dependency itself.

07Timeline: a multi-year social-engineering campaign

The attack's real weapon was patience. An identity spent years building credibility before planting the code, exploiting an exhausted volunteer maintainer. CISA's follow-up, "Lessons from XZ Utils" (12 April 2024), argued that every technology manufacturer that profits from open source must be a responsible consumer of, and sustainable contributor to, the packages it depends on, rather than leaving critical libraries to lone volunteers. For defenders, the practical reading is to treat every dependency as a trust decision and to keep the exposed surface small — the same inventory discipline that preparing for a DDoS attack relies on.