XZ Utils backdoor: how to check your Linux system

If you run Ubuntu on your laptop and keep a Kali virtual machine for learning, the two installations can have different answers to the same alarming headline. “I use Linux” is too broad a starting point for checking the XZ Utils backdoor.

The immediate task is to identify your distribution, its release channel and the complete version of its XZ library package. Follow that distributor’s instructions if it supplied an affected build. A version check helps establish what is installed; it cannot tell you whether an attacker has already accessed the machine.

The issue, CVE-2024-3094, concerns malicious code in XZ Utils releases 5.6.0 and 5.6.1. Under the required conditions, the backdoor could let an attacker with the necessary private key execute commands through an affected SSH server before normal authentication. That makes it serious, but the affected distribution and build still matter. See Red Hat’s alert and CERT-EU’s advisory .

*This guide reflects public advisories available on 5 April 2024. It is based on those disclosures and distribution documentation, rather than an independent forensic investigation.*

Check your distribution’s advisory first

A Linux distribution packages software for its own releases. A stable release, a testing branch and a rolling release can therefore contain different builds of the same library. Your distribution’s name alone does not settle the question.

These contemporary advisories provide a useful starting point. The table is deliberately selective: use your own distributor’s notice if your system is not listed.

“Unaffected” here applies to the packages and channels described in the linked notice. It does not cover a library you compiled yourself or installed from a separate repository. Ubuntu explicitly identified manual installation and its proposed development repository as exceptions to its reassuring headline.

For a work machine, give your administrator the distribution and package details before changing it. A managed server may need a coordinated response that includes other systems built from the same image.

How did a compression tool reach an SSH server?

XZ provides compression tools and the liblzma library. Andres Freund investigated high CPU use during SSH logins and debugging errors on Debian sid, then traced the problem to upstream XZ.

Some distribution SSH builds loaded libsystemd, which depended on liblzma. This brought the compromised library into the SSH server indirectly; OpenSSH had no direct dependency on it. Freund’s 29 March disclosure explains the connection .

*The two paths converge on the same library. Applicability depended on the distribution’s build.*

Malicious components were present in the Git repository, while release tarballs supplied additional machinery that activated the injection during the build. The Red Hat explanation makes this distinction clear. Checking only the repository would not tell the full story of the distributed release.

For an administrator, the consequence is straightforward: replacing a desktop compression shortcut would not address the library loaded by another service. The package and the running environment are what need attention. CERT-EU’s 2 April guidance recommended replacing compromised versions and prioritising internet-facing assets.

Identify the system and its installed packages

The commands below read information. They do not remove packages, repair the backdoor or test whether an intrusion occurred. Run the relevant checks inside each Linux installation you use, including separately managed virtual machines and containers. A result from the host does not inventory the software inside a guest.

1. Read the distribution and release

Open a terminal and run:

cat /etc/os-release

Look for PRETTY_NAME, ID and, where present, VERSION_ID. The versioned systemd documentation defines this file as operating-system identification data.

Also establish which repositories you have enabled. A familiar distribution name does not reveal whether you added a testing repository. If you do not know how the machine was configured, ask its administrator rather than guessing from the desktop wallpaper.

2. Read the complete library package version

On Debian and Ubuntu, inspect the package database:

dpkg-query -W xz-utils liblzma5

The default output lists a matching package and its installed version, as documented in the Debian `dpkg-query` manual . Preserve the whole version string, including suffixes after the upstream number. If a package is missing or its version is blank, do not treat that as proof that no manually installed copy exists.

On Kali, its own advisory uses:

apt-cache policy liblzma5

Read the Installed line. A newer Candidate is a package available to install; it is not evidence that the update has already happened. Kali’s published example shows both fields.

For openSUSE, the advisory specifies:

rpm -q liblzma5

Use the package names and instructions supplied by your own distribution. These examples are not a universal command set for every Linux package manager.

3. Understand the limit of xz --version

You can also run:

xz --version

The XZ manual says this reports the versions of both xz and liblzma. It is useful supporting information, but it does not supply the full distribution package identifier or establish which library a particular service has loaded.

A clean-looking output also says nothing about last week’s installation. Keep the current package check separate from the question of previous exposure.

Read the whole version: a worked Debian example

Imagine you administer a Debian unstable machine and see a package version beginning with 5.6.1. The headline says 5.6.1 was implicated. Should you conclude that the installed package is backdoored?

Compare these actual Debian package identifiers:

The second identifier looks alarming if you stop reading after its first five characters. Debian’s 28 March package acceptance record explicitly records the security team’s reversion. Its security announcement explains the replacement version.

The correct conclusion is therefore specific: that complete remedial identifier matches Debian’s response. It is not a reason to install some other package merely because its number appears smaller.

There is a second question. If the machine previously ran an affected build, replacing it does not reconstruct what happened during that period. A package database answers an inventory question; an investigation answers a history question. Keep both answers in your notes.

Choose the response that matches your situation

Three checks help you avoid both unnecessary alarm and false reassurance.

*Package status, service exposure and evidence of intrusion are different questions. Resolving one does not automatically resolve the others.*

Your distributor says your normal release was unaffected

Confirm that you actually used the documented release and repositories. If you did, follow normal updates; this incident alone is not a reason to erase that installation. If you manually installed a newer library, return to the exception in the advisory. Ubuntu’s follow-up specifically cautioned people who installed the affected liblzma5 themselves.

You have an affected package, without evidence of intrusion

If an affected SSH service was reachable, or you cannot establish its exposure, also follow the next section. An update alone does not complete that response.

Apply the distributor’s replacement through its supported package-management route. Avoid downloading a supposedly clean library from an unfamiliar mirror or deleting library files by hand. The distributor’s instructions should govern whether to update, roll back, restart services or reboot.

For example, Kali’s March advisory gave these steps to refresh package information and upgrade an already installed liblzma5:

sudo apt update
sudo apt install --only-upgrade liblzma5

Review the proposed package change before confirming it. Then run apt-cache policy liblzma5 again and compare the Installed version with the advisory’s remedial package, 5.6.1+really5.4.5-1. This example is specific to Kali’s response at the time; use your distributor’s notice for other systems.

An affected system had reachable SSH, or its exposure is uncertain

Treat package replacement and possible intrusion as separate work. Stop using the machine for sensitive tasks and involve whoever manages its security. Record what was installed and when; on a business system, preserve the evidence your response team needs before rebuilding it.

The contemporary advice could be stronger than an update. openSUSE recommended a fresh installation for affected Tumbleweed systems whose SSH service was exposed to the internet, plus rotation of credentials that could have been obtained from them. For other Tumbleweed cases, it advised moving to snapshot 20240328 or later and rebooting. The same notice warned that local breach detection could be unreliable.

That is why “I cannot see anything suspicious” is an inadequate substitute for the vendor’s recovery instructions. An investigation may find evidence of access, but a quiet log is not a certificate that nothing happened.

What a completed check should establish

Keep a short record for every relevant installation: distribution and release channel, complete package version, the advisory you matched it against, and the action taken. If a virtual machine shares your laptop, give it its own entry.

After remediation, verify the installed package again and complete any required reboot, rebuild or credential changes. If the machine previously carried an affected build, record how that exposure was assessed as well.

You should finish with a specific answer about a specific installation: which advisory applies, whether the package now matches the recommended replacement, and whether earlier exposure needs further attention. “Linux is fine” is too broad; those recorded answers are useful.

Sources and further reading

• Andres Freund’s original disclosure, 29 March 2024 .
• Red Hat’s Fedora warning, including its 30 March clarification .
• Ubuntu’s security follow-up, 2 April 2024 .
• Debian DSA-5649-1, 29 March 2024, preserved in a mailing-list mirror , and Debian’s remedial package record .
• openSUSE’s affected releases and recovery advice, 29 March 2024 .
• Kali’s package check and update instructions, 29 March 2024 .
• CERT-EU advisory 2024-032, updated 2 April 2024 .