regreSSHion, xz-utils, and the year Linux supply-chain bugs got real — a defender's field guide

Why this story still matters in 2026

Every conference deck has its sshd-bug slide. Every executive memo has its xz-backdoor screenshot. By now both stories have been told a thousand times. But the interesting version of the story isn't what happened — it's what almost happened, why it didn't, and what the next one will look like.

If you administer even one Linux server, the next regreSSHion or xz will land on you. So this article is structured as a defender's read-through: what the bug was, what made it weaponizable, what the published mitigation actually does, and what to verify on your own boxes today.

Part 1 — regreSSHion (CVE-2024-6387)

The bug, in one paragraph

sshd uses a SIGALRM timer to enforce LoginGraceTime — the window in which an unauthenticated client must complete authentication. When that timer fires, sshd calls a signal handler asynchronously. That handler calls functions which are not async-signal-safe — including syslog(), which on glibc systems can call malloc(). If the signal fires while glibc's heap is in an inconsistent state (mid-allocation, mid-free), the result is heap corruption. Qualys demonstrated this could be steered into remote code execution as root.

Why it was a regression

The exact same bug class was disclosed in 2006 (CVE-2006-5051) and fixed. Then in 2020, an unrelated change to sshd (commit 752250c) accidentally re-removed the fix's protection. The vulnerability sat in shipped OpenSSH from version 8.5p1 (March 2021) through 9.7p1 (March 2024) — three full years.

Why most boxes were not actually exploited

1. It was AMD64-glibc-only at scale. Qualys's working exploit needed 6–8 hours of brute-forcing the heap state. ASLR plus glibc heap randomization meant ARM, musl-based systems, and OpenBSD were out of practical reach.
2. Each attempt is loud. Successful exploitation requires thousands of failed connection attempts. Anyone with a Fail2Ban or sshguard jail caught it as a brute-force flood and banned the source long before the heap aligned.
3. The 28-day patch race won. Qualys disclosed July 1, 2024 and Ubuntu shipped USNs the same day. Most cloud providers triggered live-patching within 48 hours.

But 'most' is not 'all.' Two populations got burned: Internet-exposed sshd on small VPS instances with no rate-limiting, and air-gapped industrial systems still running long-lived 9.4p1 or 9.6p1 builds.

The configuration mitigation that should have been default

Buried in the OpenSSH advisory is a one-line mitigation that disables the entire bug class without patching:

LoginGraceTime 0

Part 2 — The xz-utils backdoor (CVE-2024-3094)

What actually got compromised

Two upstream xz-utils release tarballs (versions 5.6.0 and 5.6.1, signed by maintainer 'Jia Tan') contained a deliberately obfuscated payload that, during the build of liblzma, modified the resulting .so file. On systems where sshd was patched to depend on libsystemd (Debian and Fedora's downstream patches, not vanilla upstream OpenSSH), liblzma was loaded into the sshd address space — and the backdoor used IFUNC resolvers to hook RSA_public_decrypt, turning a specific attacker key into a pre-authentication RCE primitive.

The three-year social engineering operation

The 'Jia Tan' GitHub account was created in 2021. Their first commit landed in early 2022. Over twenty-four months they:

• Sent dozens of helpful patches to gain maintainer trust.
• Created sockpuppet accounts ('Jigar Kumar', 'Dennis Ens') that publicly pressured the original maintainer Lasse Collin to add a co-maintainer, citing his slow response time.
• Were granted commit access in mid-2022.
• Took over signing duties for releases in late 2023.
• Quietly added the malicious build-time logic across multiple commits, hidden in test fixtures and obfuscated CMake.
• Released the backdoored 5.6.0 in February 2024 and 5.6.1 the next month.

Why your LTS box was almost certainly safe

The backdoor only activated on systems where xz-utils was version 5.6.0 or 5.6.1 from the upstream tarball, AND the distribution applied the Debian/Fedora libsystemd patch to OpenSSH, AND sshd was running as a long-lived process.

By the time these versions of xz reached Debian unstable, Fedora 40 beta, and a handful of rolling-release distributions in March 2024, Andres had already published. Debian stable, Ubuntu LTS, RHEL, Amazon Linux, and Alpine never shipped a backdoored version. Ubuntu 24.04 LTS ships xz-utils 5.6.1+really5.4.5-1 — a deliberate rebuild that restores the known-clean 5.4.5 source.

Verify on your own box

xz --version
apt-cache policy xz-utils

# Expected on Ubuntu 24.04 LTS:
#   xz (XZ Utils) 5.6.1+really5.4.5
#   liblzma 5.6.1+really5.4.5

Part 3 — What both stories teach us

Lesson 1: 'Patched' is a moving target

regreSSHion is fixed in OpenSSH 9.8p1 and in every distro that backported the fix. But the same class of bug — async signal handler reaching into non-async-safe code — exists in dozens of long-running daemons. CVE-2024-39929 (Exim), CVE-2024-7264 (curl), CVE-2025-1086 (postfix) all share the same fault DNA. Patch the CVE, then disable the class with config hardening:

• LoginGraceTime 0 on sshd.
• Restrict daemons to non-root users (so even successful exploitation lands in a small blast radius).
• AppArmor / SELinux profiles for every Internet-facing daemon.
• systemd hardening directives: NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes.

Lesson 2: Supply-chain trust is not transitive

You trust your distro. Your distro trusts upstream. Upstream trusts the maintainer. The maintainer trusts the GitHub account holding the signing key. In the xz case, every one of those trust links held — and the system still got backdoored, because the attacker became the legitimate signer.

The defence is not 'trust harder.' It is reproducible builds and independent attestation. Sigstore, in-toto attestations, Reproducible Builds Initiative — these are the technologies that would have made the xz operation impossible (or at least visible) because they decouple 'this binary was signed by this key' from 'this binary was built from this source.'

Lesson 3: The next one is already in flight

There is, statistically, another multi-year social-engineering campaign against a critical Linux dependency happening right now. We will read about it in 2027 or 2028. The maintainer-burnout-pipeline-of-doom — single volunteer, foundational library, no funding — has not been fixed. Until the broader open-source ecosystem solves the 'tragedy of the commons' funding problem, the attack surface remains identical.

• Donate to maintainers of the libraries you depend on. Sovereign Tech Fund, GitHub Sponsors, OpenSSF, OpenJS Foundation — pick a vehicle and route ~1% of your security budget there.
• Mirror upstream artifacts. If your build pipeline pulls from pypi, npm, or Maven Central directly, you are one compromised account away from supply-chain exposure. Use Nexus, Artifactory, or a simple S3 mirror with content hashes.

The five-minute defender's checklist

Run this on every Linux box you care about. Today.

# 1. OpenSSH — patched and grace time disabled?
ssh -V                                # OpenSSH_9.8p1 or newer
grep -ri logingracetime /etc/ssh/     # should show "0"

# 2. xz-utils — clean rebuild?
xz --version                          # should include "+really5.4.5" on 24.04 LTS

# 3. Pending CVE patches?
sudo apt update && sudo apt list --upgradable 2>/dev/null | grep -i security
# On Ubuntu Pro:
sudo pro security-status --thorough

# 4. Brute-force protection actually running?
sudo systemctl is-active fail2ban
sudo fail2ban-client status sshd

# 5. sshd's signal-handler attack surface minimized?
sudo sshd -T | grep -E 'logingracetime|maxstartups|permitroot|passwordauth'
# Expected:
#   logingracetime 0
#   maxstartups 10:30:100
#   permitrootlogin no
#   passwordauthentication no

Further reading (curated)

• Qualys regreSSHion advisory — the original technical disclosure with exploit primitives: qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
• Andres Freund's xz disclosure — the openwall post that started the world's worst Friday: openwall.com/lists/oss-security/2024/03/29/4
• Filippo Valsorda's xz post-mortem — best non-technical explanation of how a maintainer takeover works: blog.filippo.io/severity-of-the-xz-backdoor
• Sam James's xz forensic timeline — the social engineering reconstructed commit-by-commit: research.swtch.com/xz-timeline
• Ubuntu Security Notices — authoritative source for the exact linux-image-* ABI build containing any fix: ubuntu.com/security/notices
• Reproducible Builds project — the long-term structural fix: reproducible-builds.org
• Sovereign Tech Fund — pay the maintainers: sovereign.tech