"Found no evidence that the key was accessed by an unauthorized party while it was present in the repository," Mozilla said after discovering an unencrypted GPG private subkey had been checked into a private GitHub repository accessible to a small number of employees.
What Mozilla disclosed and the action it took
Mozilla acknowledged that a GPG private subkey used to sign Firefox and Thunderbird releases was accidentally committed, unencrypted, to a private GitHub repository. Although the repository was accessible only to a small set of Mozilla employees — all of whom Mozilla says were already authorized to access the key by other means — the organization revoked the exposed subkey and replaced it. The company also reported it has introduced additional safeguards to prevent a repeat, without providing technical detail about those new controls.
The exposed subkey and exactly what it signed
Mozilla stated the affected subkey was used to sign Linux tarballs, RPM packages, and checksum files for Firefox and Thunderbird releases. Signing keys let users and package managers verify that software really came from Mozilla and has not been tampered with in transit. After revocation, packages signed with the old subkey will be rejected by normal signature verification once the revocation has been imported.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogWhat this means for technologists, package managers, and end users
- Technologists and security teams: If you are performing manual GPG signature verification of Mozilla releases, you will need to import the new signing key and the revocation for the old one; without doing so, verification will fail for artifacts signed by the revoked subkey.
- Package maintainers and automated verification systems: Systems that rely on the revoked subkey for verifying Firefox or Thunderbird artifacts must be updated to trust the replacement key and recognize the revocation to avoid false-positive verification failures.
- End users: For most Firefox and Thunderbird users, Mozilla says no action is required; the key swap should be transparent unless the user is explicitly performing manual signature validation.
RPM repository users: differing procedures across distributions
The change is more involved for users who installed Firefox via Mozilla's RPM repository. Mozilla said that on Fedora 43 and later, DNF should download the updated key during the next Firefox update, though users will be asked to approve importing it. By contrast, users running Fedora 42 or earlier, RHEL, Rocky Linux, AlmaLinux, openSUSE, or SUSE must remove the old key and manually import its replacement. Mozilla noted that Thunderbird users do not face these RPM-specific steps because the organization does not provide official RPM packages for Thunderbird.
Audit results, new safeguards, and remaining operational questions
Mozilla reported that its review of available audit records "found no evidence that the key was accessed by an unauthorized party while it was present in the repository." Beyond that statement, Mozilla did not explain how the unencrypted private key ended up in the GitHub repository or how long the key remained there. The Register asked Mozilla how long the private key was sitting in GitHub, how it got there, and whether its audit logs cover the entire period it was exposed, but did not receive a response.
The company also said it has implemented additional safeguards to prevent a recurrence but did not publish details about those controls or the scope of the audit that produced the quoted finding. Practically, the revocation and key replacement restore a clean trust state for freshly configured verification, but anyone relying on historical signatures or manual verification workflows will need to update their local keyrings and import the revocation to avoid verification failures on artifacts signed with the now-revoked subkey.
Mozilla's prompt revocation removes an exposed credential from active use and signals procedural tightening. At the same time, the lack of public detail about how the key appeared in source control and the duration of exposure leaves operational questions for teams that routinely validate software authenticity — questions they will need answers to from Mozilla if they are to return to fully automated, confident verification for previously signed artifacts.
