Mozilla reissued the GPG key signing Firefox and Thunderbird on Linux after a leak, voiding old signatures

The headline everyone ran is that Mozilla leaked a signing key. The event that actually changes your work is the revocation. Early on August 6, 2026, Mozilla published a revocation certificate for the GPG subkey that signs its Firefox and Thunderbird builds on Linux. The certificate carries reason code 2, the value that declares the key material itself compromised. That code is not a formality. It tells every tool that checks signatures to stop trusting the key retroactively, so a signature the key produced last year is now as untrusted as one it would produce tomorrow.

The leak itself is almost boring. An unencrypted copy of the subkey was committed by mistake to one of Mozilla's own private GitHub repositories. Access was limited to a small group who already held the key, Mozilla says its audit turned up nothing pointing to outside access, and it calls the overall supply-chain risk low. Nothing so far points to abuse. So this is not a breach story. It is a key-hygiene story, and the useful part is what a defender can take from how it was handled and from what the fix breaks.

What Mozilla changed

Mozilla retired the old signing subkey and issued a new one covering the Linux tarball downloads, the RPM packages, and their checksums. The retired subkey, whose fingerprint ends C1A2 0256, was announced in April 2025 and had been set to run until March 2027; it is dead early. Its replacement, ending 7676 7AA3, is valid until August 5, 2028. The primary key that anchors both, ending D98F 0353, did not change, so the trust anchor above the subkey holds. The full fingerprints are below, and the new public key and the revocation sit on keys.openpgp.org and in the Firefox Nightly KEY files.

One scope note that saves a lot of people a scare: the Debian and Ubuntu APT repositories sign with a different key and are untouched, and the Windows and macOS builds do not use this key at all. This is a Linux tarball and RPM event.

A private repo is not the reassurance it sounds like

Mozilla is right that limited access lowers the odds anyone stole the key. But the phrase private repository hides the real lesson. Most teams lean on automated secret scanning to catch exactly this mistake, and that tripwire is tuned for public exposure and known token shapes: a cloud key, an API token, a webhook URL pushed to a public branch. A raw text-armored PGP private key sitting in a private repo slips under the control that would have caught the public version. The mechanism you trust to find leaked keys was structurally blind to this one.

A valid signature is a claim about provenance, not proof a file is safe, and the trust rests entirely on the key behind it. We have seen signed npm packages ship malware with valid provenance, so a signing key is one of the highest-value secrets an organization holds. The durable fix is not scan harder. It is that a release-signing key should never exist as an exportable file on disk in the first place. Keep the private key in a hardware security module or a signing service, where signing happens behind an API and the key material never becomes bytes a developer can copy, paste, or accidentally git add. Secrets committed to source are a recurring own-goal; a project has shipped with a password printed into its own source code before. If your build pipeline signs artifacts with a key checked out onto a runner, you have the same exposure Mozilla just cleaned up, minus the audit team that caught it.

Reason code 2 is retroactive, and that has a cost

Because the revocation says compromised rather than superseded, it invalidates every signature the old subkey ever made. For the person downloading Firefox today, that is invisible: they get the new key and move on. It bites in the places that verify old artifacts. If you rebuild from an archived tarball, mirror Mozilla releases into an air-gapped environment, or keep a golden copy of an installer and re-check its signature before deployment, that check now fails against the old key, and it should. A failed verification here does not mean the file is bad. It means the key that vouched for it is no longer trusted. The right response is to re-verify against the new key or a fresh checksum, not to wave the file through.

What to actually do

Most Firefox and Thunderbird users do nothing. Two groups act.

• Anyone who checks signatures by hand. Import the new signing key and the revocation for the old one before your next manual verification, or the check will fail on a legitimate download.
• Anyone installing from Mozilla's RPM packages. Your next update may fail with a signature error. Remove the old key and import the new one; Mozilla published steps for Fedora 43 and newer, Fedora 42 and older, RHEL and its rebuilds like Rocky and AlmaLinux, and openSUSE. Thunderbird's RPM path needs no separate action.

The trap is in automation, not on the laptop. Config-management and image-build pipelines that pin Mozilla's old fingerprint, or auto-import its RPM key, will start throwing verification errors on the next run. The dangerous reflex under a red build is to switch off the signature check to unblock the pipeline. Do the opposite: rotate the pinned fingerprint to the new subkey, the one ending 7676 7AA3, and keep verification on. A pipeline that fixes a key rotation by turning off signing checks is how a real supply-chain compromise walks in next quarter.

There is a detection takeaway for your own estate too. The mistake here, a cleartext private key committed to a repo, is one you can hunt for on your side. Scan commit history and build hosts for private-key markers such as -----BEGIN PGP PRIVATE KEY BLOCK----- and -----BEGIN OPENSSH PRIVATE KEY-----, put pre-commit secret scanning in front of every repo, private ones included, and treat any signing key that lives as a file as a finding to remediate. Leaked repo credentials are how a self-spreading npm worm harvested cloud and GitHub tokens, and a code-signing key is a far higher-value target than any of those.