XZ-Vulnerability - Patch your Debian Sid, Fedora 40+, Rawhide, openSUSE Tumbleweed, MacOS Homebrew users, and Arch Systems

If you’re running:

Fedora 40+ / Rawhide,
Debian Sid,
openSUSE Tumbleweed
MacOS using homebrew (see below)

Apparently, there has been some pretty nasty code that made it into xz 5.6.0 and 5.6.1. I’d recommend reading the vulnerability reports below and doing your own research, but it sounds like to me, that systems with systemd and xz version 5.6.0 or 5.6.1 are exposed to an ssh authentication exploit.

You can check your version of xz by running:

xz -V

MacOS Homebrew
@vivante mentions this below for macOS

Homebrew upgrade on MacOS rolled back liblzma and XZ Utils to 5.4.6.
Apparently it is not exploitable but do your rollback just in case.

Your friendly neighborhood fed link:

Rawhide / Fedora

Archbros see:


Tumbleweed folks:


@moderators Can we pin this, this is an actual supply chain attack?


It would be good to know if the systemd was the only vector of attack here. libselinux also have xz as a dependency.


Thanks bud!

So we want to ensure our versions are either downgraded to pre 5.6.0, or upgraded to over 5.6.1

(there might not be a newer version available YET, but internet be sticky yo)

1 Like

Reflections on Trusting Trust, again. :thinking: Thanks for the heads-up, though!


Sure pinned globally for two weeks.


Homebrew upgrade on MacOS rolled back liblzma and XZ Utils to 5.4.6.
Apparently it is not exploitable but do your rollback just in case.


Too busy to research, but this seems to affect bleeding edge distros and rolling release for the most part.

I’d suggest if you have manjaro to also check… if anyone has majaro or could confirm might be helpful to the collective.

God damn this is a clusterfuck.

Project contributor and release manager wormed its to position of trust and then sneakily backdored xz-util. Smells like targeted long con.

If it weren’t for 0.5 sec slowdown in ssh login, it might not have been noticed for quite some time.

Some scary reading from the source:


Don’t run unstable/testing unless you have to!

1 Like

NixOS unstable is unfortunately affected :confused: Though NixOS sshd does not link against liblzma so it’s unlikely to have a practical effect for most people. Roll-back to 5.4.6 is in progress Downgrade xz: 5.6.1 -> 5.4.6 by cpaplham · Pull Request #300059 · NixOS/nixpkgs · GitHub.

Apparently part of the backdoor was in the tarball only but not the source on GitHub. All the more reason for OSS build systems to move away from downloading tarballs and use shallow clones instead.


posted in Lounge…

nice PSA of the thing.

Not any new info

1 Like

I think this has highlighted the need for development of some additional automated testing: testing to verify that there is no addiotnal functionality that was not accounted for.

e.g., maybe automated tests comparing open ports before/after, looking at libraries loaded before/after, etc.

because clearly, relying on the “many eyes, it’s OPEN SOURCE” stuff is just inadequate.

and yes, I just brew upgraded… was impacted.

Funny thing, this backdoor was implemented by custom automated test, not by messing with xz source code directly.

Mindbending, huh?


Ah I missed that.

But I was more referring to the distributions and those responsible for incorporating it.

I’ve had the feeling for some years now that the linux platform is ripe to get fucked over by people like this because whilst it is open source and everyone CAN audit it… nobody (not literally nobody, but very, very few - and mostly focused on the big exposed services) does and everybody assumes others are.


Yeah, thats the brilliantly devious approach here. Malicious commit to source code in something like linux kernel would not succeed here.

  • attacker found critical yet understaffed software component (single unpaid maintainer - the author himself)
  • attacker wormed its way into position of small power, then full power over repository
  • attacker crafted build time testing scenario for to implement backdoor into compiled binary
    • note that xz source code is unchanged, as far as we know, only output binary has some extra pieces bolted on
  • microsoft software engineer notices ssh taking too much resources and investigates why

So social engineering campaign over few years and then side-channel attack.

If it were closed source project, we would not have ever known.

I would say this is early warning shot and also end of era of easy cooperative meritocracy. OSS projects of high value will not have to start verifying contributors in detail.


This isn’t the first time someone has placed a payload or backdoor in a commonly used piece of software! I don’t think it’s nearly that big of a deal.

MSPs might remember this for example… SUNSPOT Malware: A Technical Analysis | CrowdStrike

Installers, testing and packaging rarely gets the same love as the application code especially when under limited resources.

Some kind of automated dependency auditing is needed here. That’s the only thing I can think of offhand on how to stop something like this in the future.

1 Like

This raises some interesting questions though…

“Source as infrastructure”

Consider how many critical systems do run on open source software. At what point does it become the case that national security agencies should consider monitoring or providing protection to individuals involved in maintaining critical software like this? Draconian, sure. One can only imagine the number of ways this attack could have been made easier through the application of coercion or physical violence agains the principal developer. And it really does raise questions as to how common this is/has been.