Investigation of the xz Backdoor Vulnerability and Its Attack Chain

In recent days an open‑source project, xz, was found to contain a serious backdoor. Security researchers traced the entire process, noting the attacker’s meticulous approach—similar to a TV drama spy—who rose from ordinary contributor to core developer with direct commit rights, quietly inserting a backdoor over two and a half years.

Vulnerabilities generally arise in two ways. First, sloppy code in software or operating systems can be exploited by attackers who study the source and craft specific attack flows and data. Second, attackers embed malicious code in web pages or applications, turning a visited site or downloaded software into a backdoor.

This incident differs: the attacker joined the xz compression tool project as a programmer, spent nearly three years becoming a major contributor and maintainer, and then cleverly implanted a backdoor.

xz is a compression utility used by the remote‑login daemon sshd; it is present on macOS and Linux. If a backdoor is present, the impact is massive.

The compromised versions are xz 5.6.0 and 5.6.1, discovered shortly after merging, so the current impact is limited. Users of macOS should check their version; if it matches one of these, downgrading resolves the issue.

My own systems run xz 5.2.10 and 5.2.5, indicating that only very recent or manually upgraded installations are affected.

Step‑by‑step infiltration

The process unfolded as follows:

JiaT75 (Jia Tan) created a GitHub account in 2021, actively contributed to xz, gained the trust of the core team, and obtained direct commit rights. The name and timezone were chosen to appear Chinese, but the identity is likely fake.

In a recent commit, JiaT75 quietly added two test binary files, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma . Under specific build conditions, these files are read and alter the compiled output, making the binary differ from the published source. The test data is ignored during normal source compilation and only invoked during packaging.

Preliminary research shows the injected code uses glibc’s IFUNC to hook OpenSSH’s RSA_public_decrypt function, allowing an attacker to craft verification data that bypasses RSA signature checks.

Consequently, any program that links both liblzma and OpenSSH—most notably sshd—is vulnerable, enabling crafted requests to bypass key‑based authentication.

The affected xz packages have been pushed to Debian testing for evaluation, and the attacker is also attempting to get them into Fedora and Ubuntu. The submission was timed just before Ubuntu’s beta freeze to reduce the window for detection.

Before being exposed, the attacker had risen to a senior contributor with direct code‑submission privileges, demonstrating exceptional skill.

The xz project maintainer frequently disconnects from the internet, leaving the codebase without timely review, which the attacker exploited.

Minor slip leads to discovery

Despite careful planning, a small bug in the injected code caused a CPU usage spike in sshd under certain conditions. A PostgreSQL developer noticed the spike, performed performance analysis, and discovered a 500 ms delay, which led to the backdoor being uncovered.

If not for this coincidence, the backdoor could have spread to countless machines and servers, potentially affecting many macOS development workstations.

The malicious code was added as a make‑file test command that inserted a “.”, causing the file to fail sandbox checks and skip further validation.

Once merged into the public codebase, the attacker can inject arbitrary code into the sandbox without any security review.

Conclusion

The ability to infiltrate an open‑source project for over two years, rise to a top‑level position, and embed a backdoor reads like a spy thriller. Such talent is in high demand; recruiters should take notice.

Given the extensive third‑party dependencies in Linux, similar hidden backdoors could exist elsewhere, a prospect that is deeply unsettling.