Linux - Security - Detect and Mitigate CVE-2024-3094

What the CVE-2024-3094 xz backdoor mitigator does

This Automox Worklet™ detects whether a Linux endpoint is running an xz or xz-utils release that contains the CVE-2024-3094 backdoor, and downgrades the package to a clean version when it is. CVE-2024-3094 was disclosed on March 29, 2024 by Andres Freund. Malicious code was planted in the upstream xz tarballs starting with version 5.6.0 and shipped again in 5.6.1. The backdoor injects itself into liblzma at build time and hooks the OpenSSH server through systemd-notify on glibc-based distributions, allowing a holder of the attacker's private key to bypass sshd authentication.

The Worklet locates the xz binary with which xz, reads the version string from xz --version, and compares the parsed version against the known-bad 5.6.x releases. A compromised version exits non-zero from evaluation and queues remediation. The remediation script resolves the package name with a chained rpm -qf, dpkg -S, or zypper se -f lookup against the xz binary path, then drives the matching downgrade path for the detected package manager: dnf downgrade -y, yum downgrade -y, apt-get install pinned to the next-available version from apt-cache policy xz-utils, or zypper install --force xz=5.6.1.revertto5.4 on openSUSE.

After the downgrade completes, the Worklet re-reads the xz version and verifies the endpoint is no longer on 5.6.0 or 5.6.1. Endpoints that never had xz installed, or that run any other version, exit compliant with no changes applied.

Why patch CVE-2024-3094 across every Linux endpoint

CVE-2024-3094 carries a CVSS 10.0 score because the payload sits in liblzma, a library that ships on nearly every Linux distribution and that sshd loads transitively through libsystemd on glibc systems. The bleeding edges of Fedora 40/41, Debian sid/testing, openSUSE Tumbleweed, Kali, and Arch all shipped 5.6.0 or 5.6.1 in March 2024 before the backdoor was pulled. Alpine builds against musl rather than glibc, so the sshd exploit path that the backdoor uses is out of scope on Alpine even when the affected xz version is installed. The stable channels of RHEL, CentOS, Rocky, Alma, Debian stable, and Ubuntu LTS were largely spared, but developer laptops, container build hosts, and CI runners pull from the testing channels constantly. The fleet inventory that says "no production hosts affected" almost always misses those endpoints.

Detection has to be fleet-wide because a single unpatched build host can re-inject the compromised xz into container images and downstream artifacts. This Worklet reads the installed xz version on every Linux endpoint in scope, evaluates it against the affected 5.6.x range, and downgrades to a known-clean release on the same policy run rather than waiting for a follow-up patch cycle.

How xz/liblzma backdoor detection and downgrade works

1. Evaluation phase: The script resolves the package manager with the Automox get_package_manager helper, then locates the xz binary using which xz. It extracts the version with xz --version | head -n 1 | cut -d ' ' -f 4 and tests the result against the affected 5.6.x range. A match exits non-zero so Automox schedules the remediation step. Hosts without xz installed exit 0 immediately, and any other xz version also exits 0 as compliant.

2. Remediation phase: Remediation derives the package name with a chained rpm -qf "$xz_path" on RPM systems, dpkg -S "$xz_path" on Debian-family systems, or zypper se -f "$xz_path" on SUSE. It then runs the matching downgrade: dnf downgrade -y on Fedora and RHEL 8+, yum downgrade -y on RHEL 7 or CentOS 7, apt-get install -y "$xz_package_name=$alternative_xz_version" with the version pulled from apt-cache policy xz-utils, or zypper install --force xz=5.6.1.revertto5.4 on openSUSE. The script re-runs get_xz_version after the downgrade and exits non-zero if xz is still on an affected 5.6.x release, so a failed downgrade surfaces as a failure in the Automox Activity Report rather than reporting a false success.

xz backdoor remediation requirements

• Linux endpoint with xz or xz-utils installed; the Worklet exits compliant on hosts that lack xz

• Supported package managers: dnf (Fedora, RHEL 8+, Rocky, Alma), yum (RHEL 7, CentOS 7), apt (Debian, Ubuntu, Kali), zypper (openSUSE)

• Root or sudo privileges for the Automox agent; the default agent context already meets this

• Network reachability to the configured distribution repository (or an internal mirror) holding xz versions prior to 5.6.0

• Endpoints on RPM systems need rpm available; Debian-family endpoints need dpkg; SUSE endpoints need zypper. The remediation script chooses one path based on get_package_manager output.

• Compatible with both workstation and server device types; safe to schedule on a recurring policy so a re-installed 5.6.x package gets caught on the next evaluation

Expected endpoint state after xz downgrade

After a successful remediation, xz --version reports a release at or below 5.4.x on the endpoint, and the package metadata reflects the older version. The backdoored object file in liblzma is gone, so the sshd binary on glibc systems no longer loads the patched IFUNC resolver that the attacker used to hijack RSA_public_decrypt. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again, because the evaluation script finds the version is no longer 5.6.0 or 5.6.1.

Validate with the following commands. Confirm the version with xz --version | head -n 1 and rpm -q xz or dpkg -l xz-utils. Inspect the liblzma file age with stat /usr/lib/x86_64-linux-gnu/liblzma.so.5 (the path varies by distribution) to verify it matches the downgraded package's build date. Search the sshd memory map on a glibc host with grep liblzma /proc/$(pgrep -f /usr/sbin/sshd | head -1)/maps; on a clean host the loaded liblzma path resolves to the downgraded library. For audit evidence, capture the package manager log entries (/var/log/dnf.rpm.log, /var/log/yum.log, /var/log/apt/history.log, or /var/log/zypp/history) and store them with the Automox policy run identifier. Continue to monitor for distribution-vendor security advisories and apply any successor patches through normal patch management once they are released.