Overview

Software supply chain security refers to protecting the entire software development, distribution, and deployment process from unauthorized intrusion or modification. Instead of attacking the final product directly, attackers may target intermediate components – such as open-source libraries, build tools, or developer accounts—to inject malicious code.These types of attacks are increasingly growing in both scale and severity; according to Gartner, 45% of global organizations will experience a software supply chain attack before 2025, three times the figure in 2021 [1]. A typical example is the 2020 SolarWinds incident, where malware was embedded in a network management software update, infecting tens of thousands of customers worldwide [2]. Although open-source software is often perceived as more secure (since many people can review the code), in reality, many open-source projects lack the resources for comprehensive security auditing [2]. This creates opportunities for attackers to exploit, turning trusted components in the software supply chain into “weak links” used to compromise end-user systems.

Common Issues in Software Supply Chain Security

• Compromising maintainer accounts (project maintainers): Attackers may take over a maintainer’s account or impersonate them to inject malicious code. For example, in 2025, a major incident occurred when a project contributor was tricked into revealing credentials via phishing emails, allowing attackers to take control of the maintainer’s account. From there, attackers inserted malicious code into new releases of widely used libraries, creating a serious software supply chain attack [3]. This type of attack is often achieved through social engineering, where attackers trick maintainers into revealing login information, then exploit that access to insert backdoors into the codebase [3].
• Injecting malicious code into open-source packages: Even after gaining access to a maintainer’s account, attackers may employ various “poisoning” techniques to infect software packages. These include typosquatting (creating packages with names similar to legitimate ones to deceive users) and dependency confusion (registering package names that match internal dependencies to trick build systems into downloading the malicious version) [1]. Because open-source packages are widely trusted and reused, malicious code can spread quickly through base images, builds, or software dependencies.
• Challenges in source code control and inspection: Modern projects often depend on hundreds of third-party libraries, making auditing every line of code nearly impossible. Many open-source projects are maintained by small, overloaded volunteer teams who have limited time for thorough security reviews of every contribution [2]. Moreover, malware can be carefully concealed (e.g., obfuscation, multiple layers of code), making it difficult to detect even during regular inspections. This complexity demands new approaches to supply chain control — such as using Software Bill of Materials (SBOM), vendor trust evaluation processes, and automated malware scanning tools.

Analysis of the XZ Utils Backdoor Incident (CVE-2024-3094)

XZ Utils is a set of compression and decompression tools for the .xz format (based on the LZMA algorithm), and its liblzma library is pre-installed in most Linux distributions [4]. In February 2024, a malicious backdoor code was implanted into the XZ Utils source code (specifically in the liblzma library versions 5.6.0 and 5.6.1) by a maintainer account named “Jia Tan” [5]. This vulnerability was quickly assigned the identifier CVE-2024-3094 with a maximum CVSS score of 10.0, indicating an absolutely critical level of severity. The backdoor allows an attacker who possesses a specialized Ed448 key to execute remote code (Remote Code Execution – RCE) through the OpenSSH service on affected Linux systems [5]. In other words, if the backdoor is active, the attacker will have a “backdoor” to log into the victim’s machine via SSH without needing a password.

Attack Origin & Timeline: Subsequent investigation revealed that the backdoor implantation was part of a long-term campaign lasting nearly three years (from November 2021 to February 2024), orchestrated by an individual under the alias Jia Tan / JiaT75 [5]. This actor had been contributing code to the XZ Utils project since around 2021, gradually gaining trust through multiple small pull requests and active participation. Over time, they gained commit privileges and eventually became a release maintainer of XZ Utils [4]. Analysis shows that JiaT75 used multiple accounts (such as sockpuppet identities) to create pressure on the original maintainer, convincing them to delegate more responsibilities to Jia Tan. In March 2024, Jia Tan released versions 5.6.0 and 5.6.1, which contained the malicious backdoor implanted in a highly sophisticated manner [5].

Figure 1: Infographic summarizing how the attacker “JiaT75” infiltrated the XZ Utils project and the various layers of the backdoor CVE-2024-3094. The malicious code is divided into and hidden inside test files, along with a set of M4 macros, designed to bypass source code reviews. When built on Linux x86-64 (with GCC and glibc), the macro set automatically generates the payload and injects a malicious code segment into the liblzma library during the compilation process [5]. The entire sequence is carefully designed with multiple stages and conditional triggers to reduce the chance of early detection.

The backdoor in XZ Utils operates via a complex, multi‑stage mechanism. Initially the malware remains “dormant” and does nothing unusual until the required conditions are met. Specifically, the payload abuses a glibc feature called IFUNC (Indirect Functions) to take control of symbol resolution during library load [5]. When the victim runs an OpenSSH build that includes systemd (a common distro patch that causes sshd to load libsystemd and thereby pull in liblzma) [5], the backdoor replaces OpenSSH’s RSA_public_decrypt with a malicious version [5]. The result is that the SSH key authentication flow is injected with a backdoor: if an attacker connects to the SSH service using a specially crafted SSH certificate (signed with the attacker’s secret Ed448 key), the backdoor recognizes it and allows the attacker’s payload to execute immediately before authentication [6]. Conversely, if a normal SSH connection (without the attacker’s marker) occurs, liblzma continues to operate normally and leaves no trace. This conditional activation mechanism makes the backdoor difficult to detect — the malware activates only for the attacker and remains stealthy to everyone else [2].

Exploitation and detection process: To exploit this backdoor, an attacker needs a matching Ed448 key pair. The attacker crafts a malicious SSH certificate using their Ed448 key as a Certificate Authority (CA) and embeds a payload (an arbitrary command) into a field of that certificate [2]. When the attacker attempts to SSH into the victim (a host running liblzma 5.6.0/5.6.1) using that special certificate, the backdoor in liblzma checks the certificate’s CA key. If the CA key matches the attacker’s key, the backdoor decrypts the payload hidden in the certificate and invokes that command with root privileges on the victim machine [2]. The entire sequence occurs before the normal SSH authentication step, meaning the attacker gains control of the host without valid login credentials. Conversely, if the certificate does not carry the attacker’s “valid” marker, the backdoor returns control to the regular SSH process and the connection proceeds with normal authentication [2].

Fortunately, this dangerous backdoor was discovered before it could cause widespread damage. In March 2024, engineer Andres Freund (a Microsoft employee and also a PostgreSQL developer), while investigating a performance issue on Debian Sid, noticed unusual behavior: the SSH login process was consuming an abnormal amount of CPU and triggered memory errors in the Valgrind tool [5]. This raised his suspicion about a possible issue in the liblzma library. Freund dug deeper and uncovered the malicious code hidden within XZ Utils, and subsequently disclosed his findings on the Openwall security mailing list (oss-security) on March 29, 2024 [5]. As soon as the information was published, the open-source community and Linux vendors quickly took action.

Table 1. Key Timeline of the XZ Utils CVE-2024-3094 Incident

Impact of the Incident and Lessons Learned

Severity level: Experts have assessed that the XZ Utils incident had the potential to become one of the most serious software backdoors in history if it had not been discovered in time. Alex Stamos (former CSO of Facebook) commented that, had this backdoor made it into stable releases, it would have given attackers a “master key” to unlock hundreds of millions of computers running SSH worldwide [5]. Indeed, XZ Utils is included by default in most Linux operating systems; once a backdoored XZ version was integrated into a distribution and delivered via updates, an attacker could have remotely accessed nearly any Linux server (including those running Fedora, Ubuntu, Debian…) within seconds [4]. Compared to the SolarWinds breach (which affected around 18,000 organizations), the XZ backdoor had the potential to be far more widespread and stealthy, as SSH is a core service present almost everywhere.

Fortunately, the actual impact of CVE-2024-3094 was minimized thanks to early detection. At the time of discovery, versions XZ 5.6.0/5.6.1 were only present in development (dev/testing) distro releases and had not yet made it into stable versions [5]. Thanks to a cautious release process (introducing new packages into experimental branches before stable), the Linux community was able to contain the backdoor within a limited scope [7]. Statistics show that only branches like Fedora Rawhide, Debian unstable/testing, Alpine Edge, etc., were affected; stable releases of most distros did not include the malicious XZ [6]. Immediately upon receiving the information, vendors took decisive action: Red Hat, SUSE, and Debian all simultaneously withdrew or replaced the vulnerable XZ package with safe older versions [5]; GitHub temporarily locked the XZ code repository to prevent downloading versions containing the backdoor [5]. Canonical even postponed the release schedule of the new Ubuntu version to rebuild the entire system eliminating the risk of malware spreading to other components during the build process [5]. These swift actions demonstrate the strength of the open-source model in handling incidents: the community detected, alerted, and patched the vulnerability within just a few days, before it could escalate into a widespread security disaster [7].

However, the XZ Utils incident also raised many concerns and valuable lessons. First, it serves as a reminder that even the most trusted core projects can be vulnerable. Attackers exploited process weaknesses (such as maintainer privilege management and tarball releases not matching the git source) to bypass control systems. Second, this incident raises questions about the sustainability of the open-source software maintenance model: is it viable when critical Internet infrastructure depends on the voluntary efforts of just a few individuals? [5]. The pressure on lone maintainers can lead to mistakes or manipulation, as seen in the case where the XZ maintainer was pressured by sockpuppet accounts. Finally, the XZ backdoor highlights the importance of system monitoring: it was abnormal runtime behaviors that exposed the malware, suggesting organizations should monitor unusual process behaviors (for example, sshd launching suspicious commands) to detect similar backdoors early [4].

Solutions and Recommendations

The XZ Utils incident serves as a wake-up call about risks in the software supply chain. To enhance security and prevent similar attacks, organizations and development communities can consider the following solutions:

• Enhancing security for accounts and open-source project processes: Projects should implement multi-layered controls for critical source code changes – for example, requiring independent code reviews and approvals from multiple maintainers before merging code. Additionally, protecting maintainer accounts with strong measures such as mandatory two-factor authentication (2FA) is essential [3]. Developers need to remain vigilant against phishing attacks and regularly verify the integrity of the release environment (such as ensuring that release packages do not differ from the source code in the repository).
• Improving release and testing processes: Lessons from XZ highlight the value of releasing new packages through testing channels before deploying them to stable versions [7]. Software distributors should continue to maintain a staged rollout strategy, combined with expanding the scope of automated security testing (such as fuzzing and static code analysis) on development versions. This approach helps detect abnormal behavior of new components (like XZ 5.6.x) in isolated environments before they affect a wider audience. Additionally, there should be a verification process between source code and released binaries – ensuring that distribution packages (tarballs, binaries) do not contain any extra components beyond what is in the source repository (as was the case with the malicious script present only in the XZ tarball).
• Implementing monitoring and threat hunting tools: Since backdoors often remain deeply hidden in source code, system-level monitoring can serve as the last line of defense for detection. Organizations should configure their systems to log and alert on unusual activities—for example, system processes (such as sshd) executing unexpected commands or sudden spikes in CPU/memory usage. Modern threat hunting services can establish baselines and detect when subprocesses or system activities deviate from normal behavior [4]. Investing in these tools helps identify early signs of an active backdoor, minimizing potential damage.
• Supporting the open-source community and strengthening the supply chain: Ultimately, the long-term lesson is the need for greater investment in the security of critical open-source projects. As OpenSSF emphasizes, we must remain vigilant and ready to support the silent “gatekeepers” of open-source software [7]. This includes funding independent source code audits, developing automated tools to detect backdoors (for example, Binarly’s project to develop an XZ backdoor scanner [8]), and creating environments where security experts, maintainers, and developers can collaborate and share threat intelligence [7]. For businesses, maintaining a Software Bill of Materials (SBOM) for their products is essential to track dependency versions and respond quickly when vulnerability alerts arise. Regularly applying security patches and promptly removing malicious components from the supply chain will determine resilience against similar attacks in the future.

References: The information and analysis above are compiled from numerous reputable sources, including announcements from security vendors and in-depth analytical articles on CVE-2024-3094 [4], [5], [7]. Although the XZ Utils backdoor incident caused a significant shock, the timely response from the community has turned it into a valuable case study. It reminds us that software supply chain security is not only about technology but also about people, processes, and coordinated responsibility throughout the entire software development ecosystem [7].

References

[1] https://blog.rad.security/blog/software-supply-chain-attacks-13-examples-of-cyber-security-threats

[2] https://www.cybereason.com/blog/threat-alert-the-xz-backdoor

[3] https://snyk.io/blog/npm-supply-chain-attack-via-open-source-maintainer-compromise/

[4] https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know

[5] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[6] https://jfrog.com/blog/xz-backdoor-attack-cve-2024-3094-all-you-need-to-know/

[7] https://openssf.org/blog/2024/03/30/xz-backdoor-cve-2024-3094/

[8] https://harsim.ca/Unraveling-the-XZ-Backdoor-A-Close-Call-for-Open-Source-Security/