"We no longer trust this key." That terse line, lifted from the revocation certificate and decoded by The Hacker News, set in motion a small but consequential chain of fixes for some Firefox and Thunderbird users on Linux.
What Mozilla did and why
Mozilla revoked the OpenPGP subkey used to sign Firefox and Thunderbird tarballs for Linux after an unencrypted copy of that subkey was mistakenly committed to one of the company's private code repositories. The company says the repository was private, that audit records showed no sign of unauthorized access, and that everyone who could see the file already had legitimate access — yet Mozilla revoked the subkey anyway.
The decision to revoke is significant because signatures made by a key revoked with a compromise code are treated differently under RFC 4880 than keys retired by normal rotation: a revocation for compromise makes prior signatures suspect, while a routine superseding leaves past signatures valid.
Key details: revoked subkey, replacement, and the revocation reason
The revoked signing subkey carried the fingerprint 09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256 and had been announced in April 2025 with a run until March 2027. Mozilla normally rotates this subkey roughly every two years; the revocation brought that swap roughly seven months early.
Mozilla published a replacement subkey with the fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, valid until August 5, 2028. The revocation certificate, decoded by The Hacker News, shows reason code 2 — "key material has been compromised" — generated on August 6, 2026 at 11:14 UTC with the appended note "We no longer trust this key." That revocation was signed by Mozilla's primary key (14F26682D0916CDD81E37B6D61B7B526D98F0353), which remains in place.
Mozilla's own account stops short of saying the key was exfiltrated; the company describes the incident and the GPG-based effect on verification but does not state whether anyone outside the private repository obtained the key.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scramblePractical impact on Linux users and RPM-based updates
For most Firefox and Thunderbird users, nothing changes: they will not notice any visible effect. Two specific groups must act.
- Users who verify signatures by hand must import the new key and the revocation for the old one in order to keep verifying older tarballs.
- Some users installing Firefox from Mozilla's RPM packages may see failed updates and need to swap the key manually in their RPM keyring.
On the RPM side, behavior varies by distribution. In some cases dnf fetches the updated key at the next update and prompts the user to confirm the fingerprint. On other systems the update fails outright, with errors saying that importing the key did not help or that installed repository keys are wrong for the package.
Because rpm --import can report success while leaving the stale key in place, the correct sequence shown by Mozilla is to remove the old key first: sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353 then sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg and finally sudo dnf clean all. Thunderbird does not publish official RPM packages, so those steps do not apply to Thunderbird installations. openSUSE users should run the same two rpm commands and then zypper refresh.
Historical context inside Mozilla's signing repository
An examination of the full public key kept in Mozilla's signing repository shows five earlier signing subkeys going back to 2015, and each of those earlier subkeys was retired by expiry rather than revoked. This incident marks the first revocation on that primary key.
How distribution maintainers, end users, and security teams should respond
Distribution maintainers will want to ensure their packaging and repository metadata handle the key swap: some package managers update automatically, while others require the removal of the old gpg-pubkey object before importing the replacement. End users who rely on manual signature verification should import both the new subkey and the revocation for the old one to avoid false-positive verification failures. Security teams monitoring developer tooling should note the timing: the disclosure came a week after attackers hijacked a GitHub account behind the keyv and cacheable npm packages and published a worm designed to harvest repository, registry, cloud and private-key material from developer machines and CI pipelines.
Mozilla has not said which internal repository contained the key, how long the unencrypted copy remained there, nor the specific safeguards the company says it added. Mozilla also did not comment on the APT repository used for Debian and Ubuntu, which uses a different key; .deb formats are not among the affected artifacts identified in the revocation notice.
The revocation closes one technical door and opens several procedural questions: how the subkey came to be in plaintext inside a private repository, what controls prevented detection sooner, and whether similar mistakes could exist elsewhere in signing infrastructure. For now, the immediate work is operational — replacing a keyring and confirming fingerprints — but the episode is a reminder that even non-public mistakes to signing material force a choice between silent risk and visible disruption, and Mozilla chose visibility.
