{
	"id": "1da1042e-7594-4b28-a339-8ad606f7fe66",
	"created_at": "2026-04-06T01:32:22.045432Z",
	"updated_at": "2026-04-10T13:11:58.638611Z",
	"deleted_at": null,
	"sha1_hash": "889eee7bff4578156b1f4a418bfb6f9868b08cd1",
	"title": "XZ Backdoor: How to check if your systems are affected",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1938442,
	"plain_text": "XZ Backdoor: How to check if your systems are affected\r\nBy DCSO CyTec Blog\r\nPublished: 2024-04-09 · Archived: 2026-04-06 01:25:54 UTC\r\n7 min read\r\nApr 8, 2024\r\nA principal software engineer at Microsoft by the name of Andres Freund accidentally stumbled upon a backdoor\r\nwithin XZ, the popular compression library. This discovery happened because he noticed both a 500ms delay for\r\nssh as well as the sshd processes using a surprising amount of CPU, despite immediately failing because of wrong\r\nusernames etc. He researched this and on March 29th, 2024 posted his findings on oss-security, a popular mailing\r\nlist, avoiding a worldwide disaster in the open-source community.\r\nPress enter or click to view image in full size\r\nPhoto by Markus Spiske on Unsplash\r\nBlog authored by Veronika Wiederkehr and Sooi Vervloessem.\r\nWhat is XZ Utils?\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 1 of 8\n\nXZ Utils is a set of open-source tools for lossless data compression based on the Lempel-Ziv-Markov chain\r\nalgorithm widely utilized across Unix-like operating systems. These include Liblzma, a general-purpose data\r\ncompression library with a zlib-like API, as well as the eponymous xz. At the time of writing, GitHub shutdown\r\nthe XZ repository for further investigation.\r\nThe XZ Backdoor explained\r\nJia Tan, believed to be a malicious contributor and maintainer of XZ Utils, worked more than two years on slowly\r\ngaining trust and implementing malicious pieces of code to the XZ Utils repository. It is currently unknown if this\r\nis their real name, or if this is even one individual and not a nation state.\r\nThe backdoor is obfuscated so well that at the time of writing, researchers are still trying to decipher and analyze\r\ncertain parts.\r\nIt was designed so that the XZ backdoor would be injected into OpenSSH binaries on Linux at several stages\r\nduring compilation.\r\nUsing this backdoor, a threat actor (in possession of the private counterpart of a hard-coded ED448 public key)\r\ncan remotely execute code if a target machine is running a combination of Linux, systemd and an OpenSSH server\r\nbinary that has been poisoned with the backdoor, and the SSH server port is directly exposed to the internet. A\r\nmore technical and detailed explanation can be found in the next chapter.\r\nThe XZ backdoor is assigned CVE-2024–3094 with a Base Score of 10.0 (Critical):\r\nPress enter or click to view image in full size\r\nSource: NIST\r\nSomething worth noting is that according to GitHub user thesamesam, no log messages at the INFO level or\r\nhigher are written by OpenSSH when a successful exploitation occurs. This makes the detection by log analysis in\r\nproduction environments highly unlikely.\r\nWorkflow of the Backdoor\r\nThe m4/build-to-host.m4 macro is executed during the build process. This macro uncorrupts a malformed XZ file,\r\nbad-3-corrupt_lzma2.xz, that has been disguised as a code test. Afterwards, a malicious Bash script is extracted\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 2 of 8\n\nand decrypted from another decoy test archive, good-large-compressed.lzma.\r\nThis Bash script will extract a binary file, decrypt it and save it as liblzma_la-crc64-fast.o. Jia Tan also commited\r\na . in the CMake check for landlock support, so that this check always fails causing the landlock support to be\r\ndetected as absent:\r\nPress enter or click to view image in full size\r\nSource: Tukaani\r\nThe backdoor will hijack pre-authentication RSA decryption function calls in OpenSSH server binaries. When a\r\nconnection towards the SSH server is verified by the backdoor, the adversary’s payload is extracted and piped into\r\nsystem(). This makes the target machine vulnerable to remote code execution.\r\nJia Tan even added an extension mechanism, which makes the backdoor scalable and avoids the need to change\r\nthe binary every time. The idea is to just add more signature files that contain malicious payloads. According to\r\nGynvael Coldwind, the idea is to avoid modifying ‘bad’ and ‘good’ test files over and over again, since this is\r\npretty suspicious.\r\nA detailed yet well-structured scheme from Thomas Roccia about the workflow can be found below:\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 3 of 8\n\nSource: Thomas Roccia\r\nTimeline\r\nTo visualize the supply chain attack, underneath you can find a timeline:\r\nPress enter or click to view image in full size\r\nTimeline based upon scheme from Thomas Roccia\r\nAffected XZ Versions\r\nThe XZ versions affected by this backdoor at the time of writing are versions 5.6.0 and 5.6.1. These versions are\r\nluckily not used in most stable versions of Linux distributions. The versions occur only in rolling-release, ie\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 4 of 8\n\nmostly experimental versions of Linux distributions. There is a possibility that there are other backdoors Jia Tan\r\nhas placed into XZ.\r\nAffected Operating Systems\r\nUnderneath, you can find a list of affected operating systems:\r\nKali Linux (only those that were available between March 26–29)\r\nopenSUSE Tumbleweed/MicroOS (available from March 7-28)\r\nFedora 41, Fedora Rawhide, and Fedora Linux 40 beta\r\nDebian (testing, unstable (sid) and experimental distributions only)\r\nArch Linux\r\nAlpine Edge (active development)\r\nPlease note that additional operating systems and distributions might be added over time.\r\nHow to check if your system is affected?\r\nIn order to verify if a system is affected by the XZ backdoor, you should check the following things. These checks\r\nonly aim at unveiling the CVE-2024–3094 backdoor, so please keep in mind that there might be other backdoors\r\nthat are yet to be discovered.\r\nGet DCSO CyTec Blog’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nCheck affected version\r\nTo check if any known backdoored XZ version is present on your system, execute the following command:\r\nstrings `which xz` | grep '5\\.6\\.[01]'\r\nIf there is no output, it means that no such binary was found in any of the $PATHs specified.\r\nCheck Liblzma library\r\nTo check whether there is an OpenSSH server loading the Liblzma library, you can execute the following\r\ncommand:\r\nlsof -p $(ps -aux | grep 'sshd' | grep 'listener' | awk '{print $2}') | grep '\\.so' | grep 'liblzma'\r\nIn the output you can see which version of the Liblzma library is loaded in the memory. If that version matches\r\none of the affected versions, please take further actions.\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 5 of 8\n\nIf you get no output, we can assume that there is no SSH server loading the Liblzma library in the memory of the\r\nsystem.\r\nUse the XZ Backdoor scanner\r\nAnother option is using the XZ Backdoor scanner from Binarly.\r\nThis scanner looks for the backdoor code in an ELF file which the user can upload (\u003c5Mb).\r\nUse the XZ Backdoor Detector\r\nThere is a detector for the CVE-2024–3094 on GitHub. It checks whether a malicious version of xz or liblzma is\r\ninstalled on the system.\r\nThe tool also checks whether the currently installed SSH server (sshd) links to liblzma. SSH servers that do not\r\nlink to lzma are not affected by CVE-2024–3094 as the backdoor will never activate.\r\nTo quickly analyze your current system, you can execute the following commands:\r\ngit clone https://github.com/jfrog/cve-2024-3094-tools.git\r\ncd cve-2024-3094-tools/cve-2024-3094-detector/\r\n./cve-2024-3094-detector.sh\r\nThis is what the output could look like for a system that is not affected:\r\nPress enter or click to view image in full size\r\nYou can find the GitHub repository here.\r\nHow to check if your container is affected?\r\nGrype is a vulnerability scanner for container images and filesystems. It is very easy to use and is able to find\r\nvulnerabilities for major operating systems.\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 6 of 8\n\nInstallation Grype\r\nTo install Grype, please follow the instructions in the installation section of the GitHub page.\r\nVerify the artifacts\r\nChecksums are applied to all artifacts, and the resulting checksum file is signed using cosign.\r\nYou need the following tool to verify signature:\r\nCosign\r\nVerification steps are as follow:\r\n1. Download the files you want, and the checksums.txt, checksums.txt.pem and checksums.txt.sig files from\r\nthe releases page\r\n2. Verify the signature:\r\ncosign verify-blob \u003cpath to checksum.txt\u003e \\\r\n--certificate \u003cpath to checksums.txt.pem\u003e \\\r\n--signature \u003cpath to checksums.txt.sig\u003e \\\r\n--certificate-identity-regexp 'https://github\\.com/anchore/grype/\\.github/workflows/.+' \\\r\n--certificate-oidc-issuer \"https://token.actions.githubusercontent.com\"\r\nOnce the signature is confirmed as valid, you can proceed to validate that the SHA256 sums align with the\r\ndownloaded artifact:\r\nsha256sum --ignore-missing -c checksums.txt\r\nGetting started\r\nInstall the binary, and make sure that grype is available in your path. To scan for vulnerabilities in an image:\r\ngrype \u003cimage\u003e\r\nThe above command scans for vulnerabilities that are visible in the container (i.e., the squashed representation of\r\nthe image). To include software from all image layers in the vulnerability scan, regardless of its presence in the\r\nfinal image, provide --scope all-layers :\r\ngrype \u003cimage\u003e --scope all-layers\r\nTo run grype from a Docker container so it can scan a running container, use the following command:\r\ndocker run --rm \\\r\n--volume /var/run/docker.sock:/var/run/docker.sock \\\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 7 of 8\n\n--name Grype anchore/grype:latest \\\r\n$(ImageName):$(ImageTag)\r\nYou can specify a lot of options and even scan on specific vulnerabilities. For more information, see the GitHub\r\nrepository.\r\nExploitation in the wild\r\nCurrently, there are no known/public cases in which the backdoor was leveraged. If you are affected by this\r\nbackdoor and have the suspicion that there were post-exploitation activities, we would love to hear from you.\r\nConclusion\r\nThere are multiple ways to check if your system has been affected by the XZ backdoor. The XZ Backdoor Scanner\r\nand XZ Backdoor Detector offer a fast way to check your systems. For containers, there is a vulnerability scanner\r\ncalled ‘Grype’. Up until the time of writing, there has been no known case in which the backdoor was exploited.\r\nSource: https://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nhttps://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://medium.com/@DCSO_CyTec/xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271"
	],
	"report_names": [
		"xz-backdoor-how-to-check-if-your-systems-are-affected-fb169b638271"
	],
	"threat_actors": [],
	"ts_created_at": 1775439142,
	"ts_updated_at": 1775826718,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/889eee7bff4578156b1f4a418bfb6f9868b08cd1.pdf",
		"text": "https://archive.orkl.eu/889eee7bff4578156b1f4a418bfb6f9868b08cd1.txt",
		"img": "https://archive.orkl.eu/889eee7bff4578156b1f4a418bfb6f9868b08cd1.jpg"
	}
}