Red Hat warns xz backdoor could open Linux systems to unauthorized remote access

Red Hat has warned that malicious code was inserted into upstream xz release tarballs, creating a serious supply chain threat tracked as CVE-2024-3094. The concern was not a normal software bug. Researchers found a deliberate backdoor that could let an attacker interfere with SSH authentication and gain unauthorized remote access on affected systems.

The xz package matters because Linux distributions use it widely for compression and decompression. That broad use made the incident especially dangerous, even though the compromised versions did not end up spreading across most stable enterprise releases. Red Hat said versions 5.6.0 and 5.6.1 carried the malicious code.

In plain terms, the backdoor targeted the build process rather than sitting openly in the main source repository. Red Hat said the payload hid inside upstream tarballs and used obfuscated build logic to modify liblzma during compilation, which then affected sshd through systemd on vulnerable Linux systems.

How the xz compromise worked

Security researchers said the malicious logic did not appear clearly in the public Git repository alone. Instead, the attack relied on extra code placed in the release tarballs that Linux distributions use when they build packages. During the build, that code injected a backdoor into liblzma under certain conditions.

Red Hat warned that the result could allow a malicious actor to bypass or break SSH authentication and reach the entire system remotely. OpenSSF echoed that assessment and noted that the attacker specifically designed the backdoor for Linux distributions building RPM or DEB packages on x86-64 systems with common toolchains.

The incident drew intense attention because it came very close to wider deployment. Fedora later called it the “backdoor in XZ Utils that almost happened,” after the compromise was caught before Fedora stable releases shipped with the exploitable build in the way originally feared.

Affected distributions

Red Hat said no versions of Red Hat Enterprise Linux were affected. Inside Red Hat’s ecosystem, the issue centered on Fedora Rawhide and Fedora Linux 40 beta, where affected xz library builds appeared during development and testing.

Red Hat initially told Fedora Rawhide users to stop using those systems until the project reverted to xz 5.4.x. The company also said Fedora 40 beta contained affected xz library packages, although Red Hat did not believe the actual malware exploit took effect in those Fedora 40 builds. Even so, it urged users to downgrade to 5.4.x versions.

Debian also confirmed exposure in its non-stable branches. Debian said stable releases were not known to be affected, but testing, unstable, and experimental carried compromised xz-utils packages up to and including 5.6.1-1 before maintainers reverted the code base to a safe upstream version.

What admins should do

If you run enterprise RHEL systems, Red Hat says you are not affected by this CVE. If you ran Fedora Rawhide or Fedora 40 beta during the exposure window, you should verify the installed xz packages and make sure the system reverted to a safe 5.4.x build.

Administrators using Debian testing or unstable should make sure their systems fully updated after Debian’s security response. Teams using rolling or development distributions should also review their vendor advisories, because this attack mainly touched pre-release, unstable, and development branches rather than mainstream stable enterprise releases.

The wider lesson is clear. A compromise in a deeply trusted upstream utility can ripple through the software supply chain very quickly. This case also showed why developers and distro maintainers need to verify source provenance, not just trust a package because it comes from a well-known project.

Key facts at a glance

Immediate response steps

• Check whether any system used xz 5.6.0 or 5.6.1 during the exposure period.
• Downgrade or confirm reversion to xz 5.4.x where your vendor instructed it.
• Prioritize Fedora Rawhide, Fedora 40 beta, Debian testing, Debian unstable, and other development branches.
• Review SSH-related logs and package provenance if any affected build was present. This is a prudent response based on the reported attack path.
• Follow your distribution’s official remediation guidance instead of relying on generic downgrade advice from third parties.

FAQ