CVE-2024-3094: Urgent alert for Fedora Linux 40 and Rawhide users

A generic blue background appears with the text written, "CVE-2024-3094: Urgent alert for F40 & Rawhide users." The logo of the Tukaani project appears toward the top. The logo is commonly associated with the xz project.

Created by Justin W. Flory. CC BY-SA 4.0. Bob the Toucan used under fair use from the Tukaani project.

The Fedora Council was notified of CVE-2024-3094 on Friday, March 29th related to the xz tools and libraries. At this time, Fedora Rawhide users are likely to have received the tainted package. Fedora Linux 40 pre-release users may have received the tainted package build xz-5.6.0-2.fc40 through the updates-testing repository (5.6.0-2.fc40). Fedora Linux 39 and 38 users are also NOT impacted.

Any instances of Fedora Linux 40 and Fedora Rawhide pre-releases before March 29th should be considered as potentially COMPROMISED. Fedora Linux 40 was updated to xz-5.4.6-3.fc40 on Friday, March 29th at 04:33:13 UTC (see f40 Bodhi update). Fedora Rawhide was reverted to xz-5.4.6-3.fc41 on Friday, March 29th at 15:21:19 UTC (see f41 Bodhi update). As a reminder, Fedora Rawhide is the development distribution of Fedora Linux, and serves as the basis for future Fedora Linux builds (in this case, the yet-to-be-released Fedora Linux 41).

CVE-2024-3094 highlights

Red Hat Product Security published this description of the recently-discovered vulnerability:

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.

A detailed update history of the xz package across all currently-supported Fedora/EPEL branches is available on Fedora Bodhi. While the malicious update was never sent to Fedora Linux 40 stable repositories, Fedora Linux 40 pre-release users (including beta users) may have received it from the updates-testing repositories, which are enabled by default in pre-release versions of Fedora Linux to assist with testing.

Fedora Linux 40 Beta users can mitigate this vulnerability now. The downgraded version is in the Fedora Linux 40 stable repositories. If you update now, you get the downgraded one from the stable repositories. (If the package is not shown in a dnf upgrade, some users report dnf distro-sync as correctly pulling in the downgraded package.)

An extended discussion on the oss-security mailing list provides more detail about the nature of the attack and how it was initially discovered. More information about this vulnerability can also be found on the Red Hat Blog.

Thank you first responders!

Fedora has a reputation on being First, but it would not be possible without the Friends who make it possible. It is difficult to predict when news like this may land. Many Fedora contributors have also already gone on vacation for the upcoming holiday weekend. We appreciate the hours that many have already put in and continue putting in to address this problem and ultimately protect Fedora users from malicious software. Thanks to the timely and prompt action by our packaging and infrastructure community, all users running on stable update channels only were NOT impacted by this vulnerability.

Special recognition goes out to our Fedora Infrastructure Team for coordinating these prompt and timely actions to reduce end-user impact. We could not do it without you!

As a reflection on the upcoming release of Fedora Linux 40, there remains a lot of uncertainty about this exploit. It appears to be a sophisticated breach of trust that may have taken place over an extended period of time. Fedora Linux 40 is around the corner, which is also distinguished from other Fedora releases because Fedora Linux 40 is the branch point for CentOS Stream 10, the next major version of Enterprise Linux. Therefore, if this exploit had been discovered even two or three months later, this vulnerability would also have impacted downstream builds from Fedora and CentOS Stream, including Red Hat Enterprise Linux (RHEL), AlmaLinux, Rocky Linux, Amazon Linux, Oracle Linux, and others.

The prompt actions of our Fedora community first responders and Infrastructure Team are an example of our community working at its best. Thanks for helping keep the Fedora user community safe.

Get in touch about CVE-2024-3094

This is an emerging story and there will be more news and updates about this vulnerability to the xz package set. You can follow your usual channels for updates on security vulnerabilities. You can also reach out to the Fedora developer community on the devel mailing list or on Matrix.

2024-03-30 edit: Fedora community first responders were made aware on Thursday, March 28th.

2024-04-01 edit: Edited to clarify exposure of Fedora Linux 40 users to the tainted package. The updates-testing repository is enabled on ALL pre-release variants including the beta release of Fedora Linux 40.

2024-04-04 edit: Edited the opening paragraph to clarify the specific Fedora Linux 40 package version vulnerable to the exploit, and that F40 users MAY or MAY NOT have received the tainted version.

Fedora Project community For Developers For System Administrators Using Software


  1. Darvond

    I have a question regarding this: We know this was done by a malicious actor; or at least someone without the best interests of the xz project in mind.

    What or how does one deal with such an actor, aside from simply banning them? Are there repercussions that could be had?

  2. Matt

    This explanation about the upgrade only going to Fedora 40 stable makes sense, but it contradicts what Red Hat said in the advisory.

    They said the Fedora 40 builds (of 5.6.0) appear not to have been affected:

    I guess they mean the builds but not the updates?

    Also, looking at the Bodhi links, it seems the bad builds were pulled on the 28th, people were made aware on Thursday, not Friday?

    • Hi Matt, thank you for your comment. It is complicated with Fedora Linux 40 due to the testing/stable repositories. Depending on when someone first used the officially-branched version of Fedora Linux 40, they may have received this update from the testing repositories without any action from their part. My best understanding is that anyone who installed Fedora Linux 40 Beta after the March 26th announcement are not impacted. As I know more, I will keep this article up-to-date. I made edits to address your feedback.

      Also, good catch on the first notification. I clarified to state that the Fedora Council learned of the CVE on Friday, March 29th and Fedora community first responders learned of the CVE on Thursday, March 28th.

  3. Until the post can be updated, please be aware that this is not really correct:

    “Fedora Linux 40 Beta users may have received the package if they opted into updating from testing repositories.”

    The updates-testing repository is enabled by default on Fedora 40, because it is a pre-release. Anyone who installed Fedora 40, left it in default configuration, and updated it normally between around 2024-03-02 and 2024-03-06 may have received the 5.6.0-2.fc40 build, which Richard Jones (the maintainer) says is potentially vulnerable (though assessment is still ongoing).

    You can use dnf history info xz to see if you ever had that build installed. If so, follow the recommendations for Rawhide.

    • Thanks for the clarification Adam! I edited the article to integrate your feedback. My current understanding is that anyone running f40 branched could have received this update as you describe, but users who started using Fedora Linux 40 after the March 26th Beta announcement are not impacted. Is my understanding correct?

  4. Matt

    It’s not quite true that Fedora 40 “testing” was affected. Essentially what happened went like this:

    The 5.6.0 release caused warnings in the build process, so the package maintainers added –disable-ifuncs to the configure script to it would build properly, effectively disabling the backdoor. So the 5.6.0 version actually pushed to version 40 did not have the backdoor enabled. The very determined attacker actually made a new release, version 5.6.1, and convinced the maintainers to remove the –disable-ifuncs flag, but the Beta Freeze for 40 meant that version never went up.

    So while yes you may have gotten a 5.6.0 package if you had testing repos enabled and were running 40, that package should have been safe, even though it was built from the compromised tarball, the produced package did not have the backdoor.

    A detailed discussion is here:

  5. Michael Catanzaro

    The sentence “Fedora Linux 40 Beta users may have received the package if they opted into updating from testing repositories” is incorrect because, as the article later notes, updates-testing is enabled by default.

  6. realmente muitas vezes ,nas atualizações .temos alguns erros ,mas todo sistema tem este defeito ,ou erros ao ser corregido após atualizações ,gosto muito do sistema Linux e do fedora ,pós aprendemos muito com a tecnologias do mesmo ,obrigado

  7. ilikelinux

    rpm -qi basesystem

    # to see when system was installed and more info’s

    I had to add grep to see just the xz records:
    `dnf history info xz |grep -i xz

    So testing rawhide first in virtual environments is quite handy. I just deleted my rawhide where I saw the 5.6.x version popping up.

    I hope we get soon more advice how we can check the system and assure the backdoor is removed and can not causing harm anymore.

    Seams the attacker(s) studied carefully the release-circles of RHEL based OS ‘es but not counted with the speed a opensource community can act. Congratulations!

  8. Frank

    When I upgraded to Fedora 40 on March 15, I installed xz version 5.6.0-3.fc40. Was this version compromised too?

    • IIUC, 5.6.0-3 was “accidentally” not vulnerable because that release disabled ifunc (rpm -q ‐‐changelog xz should also work to confirm that). The malicious code is present, but supposedly/theoretically not reachable. If possible, it would be best to completely erase and reinstall any system that ever had a version of xz >= 5.6.0-1.

  9. lepotat

    Hey is it safe to download fedora 40 beta now? (March 31st?) Would be nice if some disclaimer or “see this blog” was added to fedora 40 download page if the suggestion is to wait for more information.

  10. lars martin

    “Any running instance of Fedora Rawhide before March 29th should be considered as potentially COMPROMISED. Fedora Rawhide was reverted to xz-5.4.6-3.fc41 on Friday, March 29th at 15:21:19 UTC (see f41 Bodhi update). As a reminder, Fedora Rawhide is the development distribution of Fedora Linux, and serves as the basis for future Fedora Linux builds (in this case, the yet-to-be-released Fedora Linux 41).”

    Sorry i did not understand what issue is here? I use fedora 40 beta with rpm fusion because its did not find virtualbox any way? Its some issue about it and updated xz (XZ Utils) 5.4.6
    liblzma 5.4.6

  11. X_Rawhide24h2

    I was on Rawhide (20240327_ISO) and scratched the install 10 minutes after the alert. Rewrite the BIOS version under Windows_10 and reset to factory setting secure boot keys, PK,KEK,db and dbx. End result shows UEFI dbx default version =77.

    Freshly installed 20240331 ISO_kde-live_F41 from compose finder and it comes with the previous version of xz. All is good now,

  12. TooShyForTea

    For those who want to check quickly, I’ll just leave this here.

    Check if your version of “xz” is one of the affected versions (5.6.0 or 5.6.1) by running –


    which xz

    | grep ‘5.6.[01]’

    Example of a vulnerable output –

    $ strings

    which xz

    | grep ‘5.6.[01]’
    xz (XZ Utils) 5.6.1

    Example of a safe output –

    $ strings

    which xz

    | grep ‘5.6.[01]’


  13. Mario

    It’s all very worrying. Now what will be the next step to prevent mistakes like this from happening again?

  14. lars martin

    Hi i can upgrade to fedora 41 without issue?
    But can someone answer what reason of post warning?

    I did not without this understand why fedora 40 beta or fedora 41 pre-alpha is big risk, i think ReactOS or windows XP/98 or vista may be more unsafe.

    Good i can upgrade without to damage bootloader or break anything, before i get some issue that need reinstall but upgrade to fedora 41 works great, but did not know issue to stay on this to testing what to avoid? what can be risk e.g usage of this distribution stage? I think is good for this stage. but did not sure how to avoid to install package to break up boot?

    • … what to avoid?

      Any version of xz >= 5.6.0. It shouldn’t be present on any mirrors anymore. It should be safe now. It would be great if an official announcement were made that it is safe, but I don’t know if that will happen.

  15. Lars Martin Hambro

    But its safe to use email or account or some that use personal data on fedora 41 prealpha or 40 beta?

    Did not know why its not release, not sure if some bug, get fixed or why its not competed. but want to test.
    First i test more safe usage if some thing happed, but its look its safe do to more risk test.

    • Yes, Fedora 40+ is safe as long as you don’t install a version of xz that is greater or equal to version 5.6.0. There are still a few bugs being worked on for the Fedora 40 release, but they are not CVEs (security bugs).

Leave a Reply

The interval between posting a comment and its appearance will be irregular so please DO NOT resend the same post repeatedly. All comments are moderated but this site is not monitored continuously so comments will not appear as soon as posted.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions