Mozilla has revoked the cryptographic signing key behind downloads of Firefox and Thunderbird on Linux. The reason: an (unencrypted) copy of the key is reportedly said to have been accidentally committed to one of Mozilla’s private code repositories. As a result, the trustworthiness of existing signatures for older packages is no longer valid.
In this update, we explain what the Firefox Linux signing key does, why revoking it affects older downloads, and what steps you may need to take depending on how you install or verify the software.
What does the Firefox Linux signing key do?
When you download Firefox for Linux (for example as a tarball), you want to check whether the file really comes from Mozilla and hasn’t been altered. For this, users—or a Linux distribution that packages it—use OpenPGP signatures.
The signing key is essentially a kind of “signature” that confirms that the downloaded Firefox tarball was signed by Mozilla. If Mozilla revokes the key, signatures created with the old key can no longer be considered trusted after the revocation is imported.
Why revoking the signing key isn’t just about the future
Revocation doesn’t automatically mean that existing files suddenly become “malicious.” But the effect on verification is immediate: once you import the revocation, files that were signed in the past with the old key will stop verifying as trusted.
Mozilla states that this applies to older Firefox and Thunderbird downloads, so it isn’t limited to downloads you might fetch in the future. For people who install only via standard automation, the impact is usually small, but for those who check manually, the outcome can be different.
What Mozilla says: no signs of misuse
Mozilla says there are no signals that third parties actually obtained the key. The repository was private and, according to Mozilla, no one without legitimate access could have viewed the information. Still, Mozilla chooses to revoke the key once an incident is confirmed.
This approach aligns with OpenPGP’s premise: if you can’t be sure that the trust chain is still intact, you should treat the key as potentially compromised—even if you can’t publicly prove that someone abused it.
Which new key and revocation are used?
Mozilla published a replacement subkey. The fingerprint for it is:
827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3
This new subkey is valid until August 5, 2028. In addition, the incident revolves around a subkey revocation (revoking part of the key set), not the complete disappearance of the primary key.
The revocation includes a reason code indicating that key material is compromised. The reporting also mentions a timestamp when the revocation was generated and includes the message “We no longer trust this key.”
What this means for you: check downloads or system administration
Most Firefox and Thunderbird users, according to Mozilla, don’t need to do anything. But there are two scenarios where you should pay attention.
1) You manually verify signatures
Do you check signatures for downloads yourself? Then you generally need to:
- import the new key
- and also import the revocation for the old key
If you don’t, your verification tool may still report inconsistencies. If you do, verification of older files signed with the old signing key will stop—exactly the intended effect of a revocation.
2) You install via RPM packages
Users installing Firefox via Mozilla’s RPM packages may run into a failed update. You might then need to perform a key change manually.
Mozilla says that some distributions automatically handle this process (dnf downloads the update and asks you to confirm the fingerprint). On other systems, it can go wrong—for example if the distribution notices that the imported key doesn’t help, or if there’s a mismatch between installed repository keys and the package set.
To recover, Mozilla describes an order where the old key is removed first, and then the new signing key is imported, including cleanup of caching.
Examples of recovery steps on RPM systems
Mozilla points to an approach where the old key is fully removed before you import a new key. Why? Because an import can report “success” while the outdated key is still present—causing package verification to continue failing.
An example of the command sequence that appears in the reporting:
- remove the old key
- import the new signing key via the Mozilla keypad
- clear the dnf cache
The exact key IDs you use depend on what is installed in your environment. In any case, the update is about replacing the subkey that has been revoked and processing the revocation.
For Thunderbird, no official RPMs were mentioned, so this step isn’t standard for that product. Still, openSUSE users are said to run similar rpm commands and then refresh the repositories.
APT and .deb: a different key path
The news item also highlights that there is likely a distinction between repositories for different package formats. Mozilla does not explicitly say what happens to the APT repository for Debian/Ubuntu users, and it is stated that .deb should not be among the affected formats.
In other words: if you work with APT and .deb packages, the impact may be different from RPM. However, it’s still wise to regularly review your repository keys and updates—especially if your organization manages software centrally.
Why OpenPGP reason codes matter
A key revocation isn’t just “administrative.” In OpenPGP, the key owner can include a machine-readable reason. The source information uses a reason code indicating that key material is compromised.
The key difference is how OpenPGP handles past signatures. If a key was simply replaced by a newer one (superseded or retired), older signatures may still be valid under certain circumstances. But with a revocation due to possible compromise, you should treat all previously signed files as suspicious—even if the incident can’t be proven.
Extra context: the software supply chain remains a target
This announcement didn’t come out of nowhere. In the same news update, it refers to an earlier attack where criminals abused accounts around package and code infrastructure (such as GitHub and cacheable npm packages) and published a worm that can collect information from repositories, registries, cloud systems, and private key material from developers and CI pipelines.
For organizations, this is a reminder: even if an incident is “only” internal (like a private repository), the impact on trust and verification can be significant. That’s why the focus in software supply chain security often shifts to stricter key hygiene, audits, and clear procedures around key rotation and revocation.
Practical checklist for IT teams
Do you have admin roles, or do you verify software source integrity yourself? Use these points as a quick guide:
- Check your verification method: do you verify signatures manually, or through system administration tooling?
- Update repository keys in time (especially in RPM environments) so revocations are processed.
- Assess which distributions behave differently when keys are updated (dnf may do it automatically, other tools may not).
- Document your procedure for key swaps and revocation imports so you can act faster during the next update.
Want to read more about how supply chain attacks and tooling can spread? Then this article is relevant: BdThemes supply chain aanval via JSON: wat je moet weten.
Conclusion
Mozilla has revoked the Firefox Linux signing key after a copy of the key ended up in a private repository by accident. The result is that verification of older Firefox and Thunderbird downloads may stop once you process the revocation.
For most users, there’s little to worry about, but anyone who manually checks, or manages Firefox via RPMs, may need to take action: import the new key and process the correct revocation, or perform a key change manually during updates. In a world where software supply chains are increasingly attacked, this kind of key management remains a core part of distributing software you can trust.
Source: https://thehackernews.com/2026/08/mozilla-revokes-firefox-and-thunderbird.html
