Mozilla has revoked the cryptographic subkey (subkey) used to sign Firefox and Thunderbird downloads for Linux, after an unencrypted copy of the key material was accidentally committed to one of the company’s private repositories. The replacement affects users who manually verify signatures of downloaded files, as well as those who install Firefox from Mozilla’s official RPM packages. Most users do not need to take any action, but after importing the revocation for the old key, all files previously signed with it will no longer pass verification.
What happened
According to the official Mozilla Security Blog announcement, an unencrypted copy of the private release-signing subkey ended up in one of the company’s private repositories. This key is used so that users and Linux distributions can verify that a downloaded Firefox archive was indeed released by Mozilla and has not been modified.
Mozilla stated that a review of available audit logs did not reveal any signs of unauthorized access to the repository, and that everyone who had access to it held legitimate permissions. Nevertheless, the company decided to revoke the key as a precautionary measure.
Notably, the rotation happened roughly seven months earlier than planned. The revoked subkey with fingerprint 09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256 was put into production in April 2025 and was supposed to remain valid until March 2027. Mozilla rotates the signing subkey approximately every two years as protection against undiscovered leaks.
Technical details and revocation semantics
The revocation affects only the subkey, not the primary key. The main key with fingerprint 14F26682D0916CDD81E37B6D61B7B526D98F0353 remains valid. The new replacement subkey has fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 and is valid until 5 August 2028.
A key nuance is the choice of revocation reason code. According to RFC 4880, the OpenPGP standard defines several key revocation reasons. Code 0 (superseded — key has been replaced) or code 1 (key is no longer used) preserve the validity of past signatures. Code 2 (key material has been compromised) makes every signature ever created with that key suspect.
Researchers report that the revocation certificate published by Mozilla uses revocation reason code 2 with the note “We no longer trust this key,” generated on 6 August 2026. This means that all previously downloaded Firefox and Thunderbird files signed with the old subkey will fail signature verification after the revocation certificate is imported — not only future downloads.
Available data shows that analysis of the public key material in Mozilla’s repository reveals five earlier signing subkeys, in use since 2015 — all of them were retired upon expiration. The current situation is the first revocation in the entire history of this key.
Who is affected and impact scope
The incident affects two categories of users:
- Users who manually verify GPG signatures of Firefox and Thunderbird archives for Linux — they must import the new key and the revocation certificate for the old one.
- Users of Mozilla’s Firefox RPM packages — they may encounter update errors and need to manually replace the key in the package management system.
Debian and Ubuntu users who install Firefox from Mozilla’s APT repository are not affected: that repository uses a different key, and the .deb format is not on the affected list. Thunderbird does not publish official RPM packages, so the RPM key replacement procedure does not apply to it.
Practical recommendations
For users of Firefox RPM packages (Fedora, RHEL, openSUSE)
On some distributions, dnf will automatically download the updated key during the next update and prompt for fingerprint confirmation. If this does not happen or the update fails with an error, you need to perform a manual replacement:
- Remove the old key:
sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353 - Import the new key:
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg - Clear the cache:
sudo dnf clean all
Important: the rpm --import command may report success while leaving the obsolete key in place. Therefore, removing the old key as the first step is mandatory. openSUSE users run the same two rpm commands, then execute zypper refresh.
For users who verify signatures manually
You need to import the new public subkey with fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, as well as the revocation certificate for the old subkey. After that, previously downloaded files signed with the old key will no longer pass verification — this is expected behavior, dictated by the semantics of revocation code 2 in OpenPGP.
Open questions
Mozilla has not disclosed several important details: which specific repository contained the key, how long the unencrypted copy remained there, how the exposure was discovered, and what concrete protective measures were implemented after the incident. The choice of reason code 2 (key material compromised) in the absence of confirmed unauthorized access creates a contradiction between the formal semantics of revocation and the company’s official position, which does not assert that the key was stolen.
Users of Mozilla’s Firefox RPM packages should promptly replace the key following the above procedure, making sure that the fingerprint of the new subkey matches the published value 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3. Those who manually verify download signatures need to update their keyring before their next Firefox or Thunderbird download. Users of Mozilla’s APT repository for Debian and Ubuntu do not need to take any action.
