**Mozilla** has announced the revocation of the cryptographic key responsible for signing **Firefox** and **Thunderbird** downloads for Linux. The decision was prompted by the inadvertent exposure of an unencrypted copy of the key within one of the company's private code repositories. This signing key is fundamental for users and Linux distributions to verify the authenticity and integrity of downloaded **Firefox** tarballs, ensuring they originate from **Mozilla** and remain untampered. ### The Cost of Revocation The revocation carries a significant implication for users who meticulously check signatures: files signed with the old key will cease to verify once the revocation is imported. This applies to both historical and future **Firefox** and **Thunderbird** downloads. **Mozilla** states that there's no evidence suggesting external access to the key. The repository was private, internal audit logs show no unauthorized activity, and all individuals with access already had legitimate permissions. Despite this, the company opted for revocation as a precautionary measure. ### User Action Required for Some Most **Firefox** and **Thunderbird** users will not need to take any action. However, two specific groups are affected: * Users who manually verify signatures must import the new key and the revocation for the old one. * Those installing **Firefox** via **Mozilla**'s RPM packages might encounter failed updates and will need to manually swap the key. The new replacement subkey, published on Monday, bears the fingerprint **827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3** and is valid until August 5, 2028. ### Understanding the Compromise Flag **OpenPGP** allows key owners to specify a machine-readable reason for revoking a key. **RFC 4880** distinguishes between keys that are superseded or retired (where past signatures remain valid) and those revoked due to compromise (rendering all past signatures suspect). Analysis of the revocation certificate, published alongside the [new key](https://blog.mozilla.org/security/2026/08/10/updated-gpg-key-for-signing-firefox-and-thunderbird-releases/), revealed reason code 2: "key material has been compromised." This was generated on August 6, 2026, at 11:14 UTC, with the note "We no longer trust this key." While **Mozilla**'s official account avoids explicitly stating the key was 'taken,' the reason code clearly indicates a security concern. This is a subkey revocation, signed by the primary key **14F26682D0916CDD81E37B6D61B7B526D98F0353**, which remains active. The use of reason code 2, rather than a simple key rotation, is what invalidates older downloads. ### An Early Rotation This key swap occurs approximately seven months ahead of schedule. **Mozilla** typically [rotates this subkey every two years](https://blog.mozilla.org/security/2021/06/02/updating-gpg-key-for-signing-firefox-releases/) as a proactive measure against undetected leaks. The revoked subkey, **09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256**, [announced in April 2025](https://blog.mozilla.org/security/2025/04/01/updated-gpg-key-for-signing-firefox-releases-2/), was originally slated to expire in March 2027. Review of **Mozilla**'s own [signing repository](https://github.com/mozilla-releng/scriptworker-scripts/blob/master/signingscript/src/signingscript/data/gpg_pubkey_prod.asc) shows five previous signing subkeys dating back to 2015, all of which were retired by expiry. This marks the first instance of a key revocation due to compromise. ### RPM Package Management Adjustments For RPM users, some distributions' `dnf` package managers may handle the key update automatically, prompting for fingerprint confirmation. However, in other scenarios, updates may fail, requiring manual intervention. Users may need to explicitly remove the old key before importing the new one, as `rpm --import` can report success while leaving the stale key in place. The recommended commands are: **Thunderbird** does not offer official RPM packages, so this step is not applicable. **openSUSE** users should execute the two `rpm` commands followed by `zypper refresh`. **Mozilla** has not disclosed the specific repository where the key was exposed, the duration of its presence, or how the exposure was discovered. Details on new safeguards are also pending. The **APT** repository for Debian and Ubuntu users, which uses [a different key](https://support.mozilla.org/en-US/kb/install-firefox-linux), is not affected. This disclosure comes shortly after attackers compromised **GitHub** accounts associated with the `keyv` and `cacheable` npm packages, deploying a worm designed to [harvest sensitive developer credentials and data](https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html) from development environments and CI pipelines, highlighting the ongoing risks in the software supply chain.