Malicious code was discovered in the upstream tarballs of xz

CVE-2024-3094 was not a normal coding bug; it was malicious code hidden in upstream xz release tarballs that tainted liblzma during build time. The known bad upstream releases are 5.6.0 and 5.6.1, but downstream impact depends on which distros actually built from those tarballs and then shipped the result. In practice, the meaningful exposure clustered in fast-moving branches like Fedora 40 beta/Rawhide, Debian testing/unstable/experimental, some Arch artifacts, and a handful of other rolling environments rather than mainstream enterprise LTS fleets.

The vendor's 10.0/CRITICAL score describes the *worst-case impact* correctly: if all preconditions line up, this becomes pre-auth SSH compromise with full host takeover. But severity for patch planning should be downgraded from that vacuum score because the attack path has hard friction: specific xz versions, specific distro packaging choices, mostly x86_64, and a vulnerable sshd integration path. This is a HIGH for enterprise defenders because the blast radius on affected hosts is catastrophic, but the exposed population is much smaller than the raw CVSS implies.

Why this verdict

• Downgrade from 10.0: vendor CVSS scores the end-state on the victim host, not the rarity of hosts that actually inherited the poisoned build artifact
• Requires a specific supply-chain path: attacker benefit exists only where xz 5.6.0/5.6.1 tarballs were built and shipped; most enterprise LTS baselines never crossed that line
• Exposure is empirically narrow: Wiz observed only about 2% of cloud environments with vulnerable versions, which is strong downward pressure on fleet-wide urgency
• But impact stays severe where present: if you do have an affected SSH host, this is pre-auth remote compromise with full host control, which keeps the verdict well above MEDIUM

Why not higher?

To earn CRITICAL in patch-ops terms, this needed broad exposed population or confirmed active exploitation at scale. Instead, the exploit chain depended on a rare combination of bad upstream tarball, distro packaging choice, runtime linkage, and reachable SSH service, which sharply limits enterprise-wide blast radius.

Why not lower?

This is still a backdoor in a core library with public weaponization and unauthenticated remote compromise potential on the affected hosts. If your org runs rolling Linux channels, dev images, CI runners, or hand-rolled base images, the impact of a single miss is too large to relegate this to backlog hygiene.

1. Block suspect repos and images — Freeze promotion of Linux artifacts built during the exposure window and block package sources carrying xz 5.6.0/5.6.1; for a HIGH verdict, deploy this within 30 days, but do it immediately anywhere Fedora beta/Rawhide, Debian testing/unstable, or rolling images are in use.
2. Constrain SSH reachability — Reduce inbound SSH to bastions, VPN ranges, and admin networks so an affected host is not internet-reachable while you verify image lineage. Apply within 30 days as the primary blast-radius reduction if you cannot attest every Linux image quickly.
3. Inventory and attest build provenance — Search package inventories, golden images, container bases, and CI runners for vulnerable xz versions and for artifacts built from the bad tarballs. For a HIGH verdict, complete the inventory push within 30 days; this is the most reliable way to catch quietly inherited exposure.
4. Prefer known-good rebuilds over in-place trust — For suspect hosts, redeploy from known-good images or reverted packages rather than assuming an in-place version bump is enough. Execute within 30 days for containment confidence, especially on ephemeral cloud and CI estates.

Run this on the target Linux host or inside a mounted rootfs of a golden image. Invoke it as sudo bash verify-cve-2024-3094.sh /usr/sbin/sshd; root is recommended so ldd, package metadata, and filesystem paths are all readable. The script outputs exactly VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.

#!/usr/bin/env bash
# verify-cve-2024-3094.sh
# Determine likely exposure to the xz/liblzma backdoor CVE-2024-3094.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

SSHD_PATH="${1:-/usr/sbin/sshd}"
ARCH="$(uname -m 2>/dev/null || echo unknown)"
STATUS="UNKNOWN"
VERSION=""
PKGSTR=""
LINKS_LZMA="no"
REASON=""

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

get_pkg_string() {
  if have_cmd dpkg-query; then
    if dpkg-query -W -f='${Version}' xz-utils >/dev/null 2>&1; then
      dpkg-query -W -f='${Version}' xz-utils 2>/dev/null
      return 0
    fi
    if dpkg-query -W -f='${Version}' liblzma5 >/dev/null 2>&1; then
      dpkg-query -W -f='${Version}' liblzma5 2>/dev/null
      return 0
    fi
  fi

  if have_cmd rpm; then
    if rpm -q xz-libs >/dev/null 2>&1; then
      rpm -q --qf '%{VERSION}-%{RELEASE}.%{ARCH}' xz-libs 2>/dev/null
      return 0
    fi
    if rpm -q xz >/dev/null 2>&1; then
      rpm -q --qf '%{VERSION}-%{RELEASE}.%{ARCH}' xz 2>/dev/null
      return 0
    fi
  fi

  if have_cmd apk; then
    if apk info -e xz-libs >/dev/null 2>&1; then
      apk info -v xz-libs 2>/dev/null | head -n1
      return 0
    fi
    if apk info -e xz >/dev/null 2>&1; then
      apk info -v xz 2>/dev/null | head -n1
      return 0
    fi
  fi

  if have_cmd pacman; then
    if pacman -Q xz >/dev/null 2>&1; then
      pacman -Q xz 2>/dev/null | awk '{print $2}'
      return 0
    fi
  fi

  if have_cmd xz; then
    xz --version 2>/dev/null | awk 'NR==1{print $4}'
    return 0
  fi

  return 1
}

classify_pkg() {
  local s="$1"

  # Explicitly known fixed/reverted forms
  case "$s" in
    *really5.4.5*|*revertto5.4*|5.6.1-2*|5.6.0-r2*|5.6.1-r2*)
      echo "safe"
      return 0
      ;;
  esac

  # Explicit known vulnerable major upstream versions or package strings
  case "$s" in
    5.6.0|5.6.1|5.6.0-*|5.6.1-*|*5.6.0-1.fc40*|*5.6.0-2.fc40*|*5.6.1-1*|*5.5.1alpha-0.1*|*5.5.*alpha*|*5.6.0-r0*|*5.6.0-r1*|*5.6.1-r0*|*5.6.1-r1*)
      echo "vuln"
      return 0
      ;;
  esac

  # Plain semantic versions below 5.6.0 are treated as safe.
  if [[ "$s" =~ ^([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then
    if printf '%s\n%s\n' "$s" "5.6.0" | sort -V | head -n1 | grep -qx "$s" && [[ "$s" != "5.6.0" && "$s" != "5.6.1" ]]; then
      echo "safe"
      return 0
    fi
  fi

  # Common package strings containing clearly older versions
  if echo "$s" | grep -Eq '5\.[0-4]\.|5\.5\.0|5\.4\.'; then
    echo "safe"
    return 0
  fi

  echo "unknown"
  return 0
}

check_sshd_linkage() {
  local sshd="$1"
  if [[ ! -x "$sshd" ]]; then
    echo "missing"
    return 0
  fi

  if have_cmd ldd; then
    if ldd "$sshd" 2>/dev/null | grep -qi 'liblzma'; then
      echo "yes"
      return 0
    fi
    echo "no"
    return 0
  fi

  if have_cmd readelf; then
    if readelf -d "$sshd" 2>/dev/null | grep -qi 'liblzma'; then
      echo "yes"
      return 0
    fi
    echo "no"
    return 0
  fi

  echo "unknown"
}

PKGSTR="$(get_pkg_string 2>/dev/null || true)"
if [[ -z "$PKGSTR" ]]; then
  echo "UNKNOWN"
  exit 2
fi

VERSION_CLASS="$(classify_pkg "$PKGSTR")"
LINKS_LZMA="$(check_sshd_linkage "$SSHD_PATH")"

if [[ "$VERSION_CLASS" == "safe" ]]; then
  echo "PATCHED"
  exit 0
fi

if [[ "$VERSION_CLASS" == "vuln" ]]; then
  # Strongest likely vulnerable case: x86_64 + sshd linked to liblzma
  if [[ "$ARCH" == "x86_64" && "$LINKS_LZMA" == "yes" ]]; then
    echo "VULNERABLE"
    exit 1
  fi

  # Package is bad, but exploitable SSH path is unclear
  echo "UNKNOWN"
  exit 2
fi

echo "UNKNOWN"
exit 2

Sources

1. Openwall disclosure by Andres Freund
2. Red Hat Fedora alert
3. CISA alert
4. Debian DSA-5649-1
5. Ubuntu CVE page
6. Arch Linux security tracker
7. Wiz vulnerability analysis
8. Public exploit demo xzbot