On 6 August 2026 at 11:14 UTC, Mozilla generated a revocation for the GPG subkey used to sign Firefox and Thunderbird Linux releases:
09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256
The reason is one sentence long. An unencrypted copy of the private key was committed by mistake to one of Mozilla's own private code repositories.
Not a public repo. Not a leak. A private repository, visible to people who already had legitimate access.
Mozilla revoked it anyway.
The timeline
| Date | Event |
|---|---|
| April 2025 | Subkey announced, expiry set for March 2027 |
| 6 Aug 2026, 11:14 UTC | Revocation generated |
| 10 Aug 2026 | New key published |
The replacement fingerprint is 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, valid until 5 August 2028.
What Mozilla found, and what it did anyway
A review of audit records showed no sign of unauthorised access. Everyone with visibility into the repository already had legitimate access. Nothing points to anyone outside the company obtaining the key.
That is a fairly comfortable set of findings, and there was a defensible argument for leaving a key with nineteen months of validity in place.
Mozilla revoked it regardless.
This is the correct handling of a signing key and it is worth being explicit about why. A signing key's value is not that it is secret; it is that its secrecy is provable. Once an unencrypted copy has existed somewhere it was not supposed to exist, that property is gone. Audit logs can tell you nobody accessed it through the paths you log. They cannot tell you nobody copied it.
"No evidence of compromise" and "evidence of no compromise" are different statements, and only one of them justifies keeping a key.
What users have to do
| You are | Action |
|---|---|
| Checking signatures manually | Import the new key and the revocation certificate |
| On RPM (Fedora, RHEL, openSUSE) | Updates may fail; swap keys manually using Mozilla's commands |
| On APT (Debian, Ubuntu) | Nothing — different key infrastructure |
The RPM case is the one that will generate support noise. A failed update on a browser is the kind of thing users work around by disabling verification, which is the worst possible outcome of a well-handled key rotation.
Why the "private repo" detail is the whole story
The instinct on reading "signing key exposed" is to look for an attacker. There isn't one here, and that is what makes it useful.
Private repositories accumulate secrets because they feel like a safe place to put them. They are access-controlled, they are not indexed, and the people in them are colleagues. Every one of those things is true, and none of them changes the fact that a private repo is a durable, replicated, searchable, backed-up store that outlives the reason the secret was put there.
Git makes this worse in a specific way: a commit is not undone by a later commit. Removing the file leaves it in history. Rewriting history leaves it in every clone that already fetched.
This is the same structural issue behind the npm dropper that flooded the registry with 846 malicious packages and behind the U-Boot FIT signature flaws Binarly documented — the trust in a software distribution chain rests on a small number of keys, and the failure modes are rarely cryptographic. They are operational.
The reference point
If you need an internal example of how to handle this, use this one:
- Assume the copy is a compromise even without evidence of access.
- Revoke rather than expire. A key left to run out on schedule is a key you are still asserting is trustworthy.
- Publish the revocation certificate, not just the new key. Consumers need to be able to invalidate the old one, not merely add the new one.
- Say what happened in plain terms. Mozilla's disclosure names the mechanism — committed by mistake, unencrypted, private repo — which is more useful to everyone else than a sentence about an abundance of caution.
Four days from revocation to replacement key, with a public explanation. That is a good number.
