Mozilla announced on Monday, August 11, 2026, the rotation of the GPG key used to sign certain deliveries of Firefox and Thunderbird, after an unencrypted copy of the previous subkey was accidentally committed to one of its own private GitHub repositories. The publisher revoked the old key as a precaution, while deeming the risk of a supply chain attack to be low.

What Happened

In a post published on Monday, Mozilla explained that it has "moved" its signatures to a new GPG signing subkey, used for certain Firefox and Thunderbird artifacts — namely, Linux tarballs, RPM packages, and checksum files. The reason: "an unencrypted copy of the previous subkey was inadvertently committed to a private GitHub repository."

The organization immediately strives to reassure: "Our review of the available audit logs found no evidence that the key was accessed by an unauthorized party while it was in the repository. Access to the repository was limited to a small group within Mozilla, all of whom already had authorized access to the key through other means."

In other words, the circle of people who could theoretically see the exposed key corresponded to those who already had legitimate access to it. The risk that a malicious actor took advantage of it to sign counterfeit installers is therefore considered minimal — but Mozilla revoked the key nonetheless, as a principle.

Technical Detail: a "reason code 2" revocation, not a mere rotation

The detailed analysis of the revocation certificate, published alongside the new key, is informative. As decoded by The Hacker News, the revocation carries the reason code 2 ("key material has been compromised"), generated on August 6, 2026, at 11:14 UTC, with the explanatory note: "We no longer trust this key."

This is an important point under the OpenPGP standard (RFC 4880): a key revoked for compromise renders all signatures it ever produced suspect, whereas a key simply "deprecated" (superseded) would leave its past signatures valid. Practically, as soon as a user imports the revocation certificate, previous downloads signed with the old key stop verifying — not just future ones.

Some useful fingerprints to remember:

  • Primary key (unchanged): 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353 — it remains in place and is unaffected.
  • Revoked subkey: 09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256 (created on March 13, 2025, was supposed to last until March 2027).
  • New subkey: 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, valid until August 5, 2028.

A rotation seven months ahead of schedule

Mozilla rotates this signing subkey approximately every two years, precisely to guard against a leak that it might not detect. An examination of the full public key, kept in Mozilla's signature repository, reveals five previous subkeys dating back to 2015, all retired due to expiration — this is the first revocation ever recorded on this key.

The revoked subkey was announced in April 2025 and was not supposed to expire until March 2027. The rotation thus occurs about seven months ahead of the normal schedule, a direct consequence of the incident.

What is concerned... and what is not

Affected by the rotation: the Linux tarballs, the RPM packages, and the checksum files of Firefox and Thunderbird.

Not affected:

  • the .deb packages and the APT repository (Debian/Ubuntu), which use a separate key;
  • the Windows and macOS installers, which rely on signing mechanisms specific to each operating system;
  • Thunderbird on RPM, since the email client does not publish official RPM packages — no specific action is therefore required on this side.

What users need to do

For the vast majority of users: nothing. Automatic updates and regular distribution channels are not impacted.

Two categories must, however, take action:

  1. Those who manually verify GPG signatures must import the new signing key along with the revocation certificate of the old one. The new public key and the revocation are available via the KEY files of the latest Firefox Nightly builds and on keys.openpgp.org.

  2. Linux users installing Firefox via RPM packages may encounter an update failure and need to manually replace the key. On some distributions, dnf handles the switch automatically by fetching the new key and requesting confirmation of the fingerprint; elsewhere, the import fails outright.

The pitfall, highlighted by The Hacker News: the command rpm --import may report success while leaving the old key in place. Therefore, you must first remove the old key, then import the new one:

sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo dnf clean all

On openSUSE/SUSE, you execute the same two rpm commands, then zypper refresh. Mozilla has shared detailed instructions per distribution (Fedora 43 and later, Fedora 42 and earlier, RHEL/Rocky/Almalinux, openSUSE/SUSE).

One notable technical detail, visible in the Mozilla RPM key file: unlike the sibling KEY file, this RPM version does not intentionally include the revocation of the March 2025 subkey. The stated reason: "some RPM-based distributions do not handle a revoked GPG key well." A practical compromise between cryptographic rigor and compatibility.

What Mozilla didn't say

Several questions remain unanswered in the announcement: Mozilla did not specify which GitHub repository hosted the key, how long it remained exposed, how the incident was discovered, and does not describe the corrective measures it claims to have put in place to prevent such a case from happening again.

A tense supply chain context

The announcement comes just a week after the hacking of the GitHub account behind the npm packages keyv and cacheable, after which a worm was released to harvest secrets, private keys, and cloud credentials on developers' machines and in CI pipelines. In this context of heightened vigilance regarding the security of the software supply chain, Mozilla's transparency — revoking as a precaution and communicating within the day — contrasts with the more discreet practices of some publishers.

Mozilla's response illustrates a basic principle of asymmetric cryptography: when a signing secret is (or could be) taken out of its trusted perimeter, you revoke, even without evidence of exploitation. The succinct note on the certificate — "We no longer trust this key." — summarizes the philosophy: in the realm of software signing, doubt does not benefit the key.