XZ Utils Backdoor – Advisory for Mitigation and Response

Organizations Urged to Address Newly Discovered Security Flaw to Prevent Unauthorized Access to Linux Machines.

Key Insights

  • In a recent highly sophisticated cyber operation, threat actors stealthily implanted a backdoor within a Linux operating system package. The backdoor could potentially enable threat actors to gain remote access to vulnerable systems.
  • The backdoor was discovered on March 29th within the XZ Utils package versions 5.6.0 and 5.6.1; the package is being utilized for data compression in Linux environments.
  • Investigations into the vulnerability reveal that this backdoor is likely part of a long-term operation conducted by a potent threat actor, with the aim of creating a reliable foothold within the operating system, in order to obtain privileged access in the future, without the need for credentials.
  • This operation also provides the threat actor with a potential vector to perform remote code execution (RCE) with system privileges over vulnerable systems, posing a risk of unauthorized access and system compromise.
  • The vast diversity of Linux distributions makes fully identifying vulnerable versions challenging. System administrators are advised to stay informed through security advisories and actively identify susceptible distributions within their infrastructure.
  • Consistently applying and adhering to best practices ensures resilient defense mechanisms, effectively safeguarding against sophisticated threats, including alleged nation-state attacks, such as this one.

We will continue to update the advisory upon further developments.



The XZ Utils package is essential for Linux systems, and offers efficient .xz format file compression and decompression, providing high compression ratios and speed for data archiving and transfer. A backdoor vulnerability was identified in versions 5.6.0 and 5.6.1 on March 29. The backdoor was implanted as part of a sophisticated cyber operation, suspected to have been orchestrated by a nation-state threat actor. The ultimate target of this operation has not yet been determined.

Despite the limited amount of actual damage that this compromise can cause, the vulnerability gained widespread attention due to the intriguing story of the backdoor’s development, implementation, and obfuscation within the open-source code of the package. Under certain conditions, the backdoor allows gaining initial access via SSH authentication mechanism, potentially enabling unauthorized access to affected systems, and facilitating remote code execution (RCE) on the vulnerable device.

Relevance and Impact for Your Organization

The early detection of the backdoor minimized its infiltration into production systems and curtailed its immediate impact; the mitigation strategies are detailed in the Hardening and Prevention section. Despite its limited impact, this incident underscores the critical importance of adhering to security best practices as a formidable defense against attackers, including advanced and nation-state actors. Among these practices are blocking public-facing device management from the internet, filtering outgoing traffic from servers and network devices, and implementing strong segmentation, among other critical security controls.

What You Should Do

Technical Guidance

General Details and Affected Products

The vulnerability CVE ID is CVE-2024-3094, with CVSS score of 10.0 (Critical).

Systems using XZ Utils 5.6.0 or 5.6.1 on 64-bit Linux hosts (x86-64) are susceptible to this vulnerability; the risk is higher for systems running glibc that have publicly-accessible SSH ports.

DistributionAffected VersionsRemark
Fedora40, RawhideRed Hat advisory
KaliVersions updated between March 26th and 29thKali advisory
OpenSUSETumbleweed and MicroOS between March 7th and March 28thOpenSUSE advisory

For other distribution and Linux-based products, check the XZ version using the following command, where the vulnerable versions are 5.6.0 and 5.6.1:

strings /usr/local/bin/xz | grep "(XZ Utils)"


Applying system updates promptly is the top mitigation strategy to ensure alignment with the latest vendor versions:

  1. First, seek to apply patches or download updated versions of XZ Utils as soon as they become available from Linux distribution maintainers. Please note that some distributions reverted their version of XZ Utils to an older, uncompromised, and stable version.
  2. For each distribution and version, verify whether it is if it’s vulnerable; and if you should temporarily downgrade vulnerable versions (until a patch is published).

Apply patches in the following order of priority:

  1. Systems with publicly accessible SSH services running systemd and using glibc should be prioritized for immediate updates.
  2. Internal systems using affected versions should be updated promptly to prevent lateral movement within networks – even if the systems are not publicly accessible.

Temporary Downgrade

If an immediate update for XZ Utils is not available, or if applying such updates might disrupt critical services, consider temporarily downgrading to a safer version of the software.

  1. Version 5.4.6 of XZ Utils is recommended, as it currently shows no indications of containing the malicious code found in versions 5.6.0 and 5.6.1. This measure should be considered as a stopgap until updates can be safely applied.
  2. To downgrade XZ Utils, use the package management system specific to your Linux distribution. For example:
    1. On Debian-based systems (like Ubuntu), use apt-get install xz-utils=5.4.6-1
    2. On Red Hat-based systems, use yum downgrade xz-utils-5.4.6-1
    3. On systems using `dnf`, such as Fedora: dnf downgrade xz-utils-5.4.6-1., replace `5.4.6-1` with the exact package version available for your distribution. It is essential to verify the version number from your package repository.
  3. Note: Ensure to review the compatibility of downgrading with your system’s dependencies, as this action could affect other packages that rely on XZ Utils.

Hardening and Prevention

  1. If possible, block SSH access to any public-facing systems. Enable SSH access only from trusted IP addresses.
  2. Prevent devices that do not require external connections from sending outbound traffic. When outright blocking is not feasible, use firewalls or access control lists to restrict these devices to only trusted destinations and protocols, favoring an allowlist approach over a denylist.
  3. Enhance protection by placing devices behind firewalls and intrusion prevention systems, safeguarding them against attacks and controlling their traffic.

Monitoring and Detection

  1. Regularly review SSH authentication logs to identify failures or unexpected successes that could signal exploitation.
  2. Monitor changes in the behavior of sshd, since the RCE runs within the deamon and not from the shell.
  3. Monitor network traffic for anomalous patterns to and from systems, especially those involving SSH services.
  4. Explore the utilization of publicly-available YARA signature to identify potentially compromised systems.
  5. Validate that the organization has adequate visibility into Linux systems:
    • Collect operating system logs to a central logging repository. Consider leveraging AuditD to enhance Linux host visibility.
    • Collect SSH logs to a central logging repository. Prioritize external-facing Linux hosts.
    • Consider deploying an EDR solution on all Linux hosts. Consider forwarding alerts and logs generated by the EDR to a central logging repository to have a single pane of glass.
  6. Conduct periodic threat hunts that are focused on Linux hosts, to identify anomalies.
    • Since the backdoor enables threat actors to execute commands on a compromised host, it might be possible to detect suspicious behavior via process tracking. For example, search for suspicious processes executed by the SSH daemon process, sshd.

Resilience From Future Attacks

Mitigating supply chain attacks poses a significant challenge, particularly when a rogue actor manages to implant a backdoor within code running on the organization’s machines. Such threats are notoriously difficult to detect and neutralize due to their deep integration into trusted components.

However, a robust implementation of cybersecurity best practices, especially adopting a zero-trust approach and operating under the ‘assume breach’ principle, can significantly mitigate potential damage. By ensuring that every piece of code operates with the minimum necessary permissions and restricting its network accessibility, the harmful impact of any hostile code is greatly reduced.

These practices construct a formidable barrier against attackers, effectively safeguarding against even the most sophisticated threats. In essence, while it may be difficult to prevent every attack, through vigilant application of these principles, organizations can create a resilient environment that limits the extent of any potential breach. Sygnia underscored the effectiveness of this approach in its 2023 annual field report, recommending it as a cornerstone of contemporary cybersecurity strategies.



How Sygnia Can Help

Sygnia offers in-depth vulnerability assessments, patch management strategies, and incident response services to navigate the challenges posed by CVE-2024-3094. Our experts are on standby to assist in swiftly securing your environment against this and future vulnerabilities. 

This advisory and any information or recommendation contained herein has been prepared for general informational purposes and is not intended to be used as a substitute for professional consultation on facts and circumstances specific to any entity. While we have made attempts to ensure the information contained herein has been obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study, and needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results obtained from the use of this Advisory. This Advisory is provided on an as-is basis, and without warranties of any kind.

subsctibe decor
Want to get in touch?