CVE-2024-3094: Malicious code in xz 5.6.0 and 5.6.1 tarballs

There is currently an ongoing discussion on various platforms about a security issue in xz/liblzma, and here is what we know at this time. This post serves as a way to inform the community about our assessment of the impact on nixpkgs.


It was discovered that xz from version 5.6.0 started shipping malicious code that would only be executed through its release tarballs. A malicious code path would be executed when running configure and modify the resulting liblzma library.


NixOS 23.11 is unaffected since it ships with xz 5.4.4.

NixOS Unstable currently ships with xz 5.6.1 but is unaffected, since the malicious code path exits early, and liblzma remains unpatched.




The security team and other stakeholders agreed that downgrading xz to 5.4.6 for NixOS Unstable was the safest choice for now. The downgrade needs to pass through staging-next, which will likely require another 10 days.



For those that waiting for the downgrade is not within their risk tolerance, another option would be to rollback your nix stuff to the last nixpkgs revision before 5.6.0 / 5.6.1 versions

That can be checked on the following links: - (nixpkgs), and - (NixOS) Last evals before xz 5.6.x are - Nixpkgs: (input nixpks revision `9a9dae8f6319600fa9aebde37f340975cab4b8c0`) - NixOS: (input nixpkgs revision `73de017ef2d18a04ac4bfd0c02650007ccb31c2a`) Disclaimer: Those are 1 month old and depending on the circumstances rolling back to such a version might be worse. Your mileage may vary.

A good part of packages have been built on the staging-next branch after the xz downgrade; it has the following rev: d6dc19adbda4fd92fe9a332327a8113eaa843894 ( from )


Is there a way to move updates to the head of the queue, for security events?


This is currently at the head of the queue, but since xz causes a stdenv rebuild on all four supported platforms, we are talking about a 220,000 packages in the queue that need to be built.


I’ve looked into this briefly and it doesn’t seem Nixpkgs is affected at all, since we use github tarballs malicious code didn’t get in.


Note that the malicious code is in the test artifacts, the known execution vector currently only has been found in the bespoke tarballs they publish from their website.

I think that’s not the case, the ones generated by github are not affected (the Source ones), the release artifacts published on the release page are affected and it looks like it’s what nixpkgs is using. Their website just links to github releases.


When I look at XZ Utils the tarballs linked from there are from Github. My understanding from the writeup on xz-utils backdoor situation · GitHub is that the tarball contents do not correspond to the Github git repository contents.

1 Like

To what degree was nixpkgs affected by this? My understanding is that the backdoor was only injected to rpm and deb builds, which nixpkgs doesn’t use. Is that merely conjecture at the moment?

It’s a bit more subtle than that because part of the chain is present in the Git repository in “fake” test fixtures: Tests: Update two test files. · tukaani-project/xz@6e63681 · GitHub

The issue can only be triggered when using the official release tarball because it requires a change to a Makefile that is not present in the Git repository.

To the current knowledge of the community for packages using the xz nixpkgs package:

  • even with the backdoored tarball the script injecting the backdoor does not work in our build context. Basically the script injecting the backdoor runs but it exits without doing anything because the required conditions do not match: the backdoor is not injected in the built binaries
  • the backdoor itself has a certain number of conditions that are not met in a NixOS environment and as such is not effective

Note that the situation is evolving and more knowledge is being acquired thanks to people looking more closely to the backdoor itself but if you rollback to a nixpkgs unstable pin from before the upgrade to xz 5.6.x you need to consider, according to your threat model, that other security issues have been fixed in the meantime.


Note: the same guy also made some suspicious “contributions” to libarchive:

I would git revert every single one of these, just in case.
I checked their entire github log and, fortunately, it looks like only libarchive and xz are affected.


Skimming through the linked FAQ I found this:

The payload only activates if the running program has the process name /usr/bin/sshd.

… so I guess that’s good for NixOS users, right?

1 Like

/usr/bin/sshd might show up for things using buildFHSEnv | nixpkgs. steam, for example, includes xz but no copy of sshd.


10 days for a high security risk , Can we do better ?

OpenMandriva has already taken out the corrupted code and is distributing xz 5.6.1-2 to their users …

1 Like

Debian is considering going back two years, before Jia Tan started committing to the project:


Maybe system.replaceRuntimeDependencies can help.


Given that the XZ repo was nuked, what should we do?

1 Like

I don’t see that as really impeding stuff around NixOS / NixPkgs. It already downloads from a mirror.

There’s not much we can do, it’s a downside of how Nix handles package dependencies. You can’t simply swap out one core package without rebuilding everything that depends on it, otherwise the resulting packages won’t pure.

If you’re on NixOS you can use system.replaceRuntimeDependencies to rewrite all the references to the infected xz, until the revert commit reaches the unstable channel.