Mozilla has released a new `GPG signing subkey` used for some Firefox and Thunderbird artifacts after it discovered that a previous signing key was accidentally exposed in a GitHub repository. The company is taking this step to reduce supply chain risk and to prevent the same type of mistake from happening again.
While this kind of incident can sound alarming, the impact is limited by how the exposed material was handled and by the actions Mozilla has taken. Still, if you verify signatures yourself—or use certain package formats—you may need to update what you trust.
What happened with the Firefox GPG key
Mozilla said that the issue involved a new (previously used) signing subkey tied to the release process. A copy of the key was committed without encryption to a GitHub repository.
In principle, a compromised GPG private signing key can be misused. An attacker who obtains such a key may be able to produce signatures that look valid—on malicious software instead of legitimate releases.
Why exposed signing keys matter for software supply chain
GPG signatures are one of the tools used to prove that downloaded artifacts match what the publisher intended. If an attacker can sign modified or malicious files with a real, trusted key, those files can appear authentic to downstream users and automated checks.
That said, exploitation still requires additional steps. Even with a valid signature, an attacker would need a way to deliver the signed, altered files to users. Mozilla highlighted example paths such as compromised mirrors, alternative download locations, or social engineering.
Mozilla’s risk reduction factors
Mozilla emphasized that the exposure was contained in a way that reduced the chance of unauthorized access. According to the company, the key was committed to a private GitHub repository that was accessible only to a small group of Mozilla developers.
Importantly, those developers already had access to the signing key through other, legitimate channels. In addition, Mozilla reviewed available audit records and found no evidence that the key was accessed by an unauthorized party while it was present in the repository.
What Mozilla changed: revoke and issue a new subkey
Even with the mitigating circumstances, Mozilla decided to treat the situation seriously. The organization revoked the exposed key and issued a new signing subkey to restore a clean trust path for releases.
Mozilla also implemented additional protections intended to prevent similar incidents going forward. The goal is to reduce the odds of unencrypted key material being accidentally stored in places where it could be retrieved.
Which artifacts were signed with the affected key
The exposed signing subkey was used for various Firefox and Thunderbird release artifacts. Mozilla specifically referenced items such as:
- Linux tarballs
- RPM packages
- Checksum files
Because these artifacts rely on signature verification, updating the trusted keys helps ensure that your verification process aligns with the current release signing setup.
Do you need to take action?
For most people, Mozilla noted that no action is required. The majority of users simply download Firefox and install it without manually verifying GPG signatures.
However, there are two main cases where you may need to update your setup.
If you manually verify GPG signatures
If you use GPG to check release signatures yourself, you’ll need to import the new Firefox GPG key and also apply the revocation for the old one. This ensures your local keyring reflects the current trust model.
If you use Firefox RPM packages
Mozilla also pointed out that users who install Firefox via RPM packages may have to follow additional steps. The company shared detailed instructions for this scenario, which typically involve updating your local key trust and aligning your verification tooling with the new signing information.
Why key rotation is becoming standard practice
Mozilla’s response aligns with a broader trend across software development and security teams: rotate signing keys when there is any credible indication of exposure. Over the past year, software supply chain attacks have become more prominent, making key hygiene and rapid response critical.
By revoking the exposed key and issuing a replacement, Mozilla reduces the window in which an attacker could potentially use stolen signing material, even if the evidence suggests that unauthorized access likely did not occur.
How to think about the threat—without panic
It’s understandable to worry when release keys are mentioned in a security context. But this incident also illustrates why structured controls and monitoring matter.
Mozilla’s audit findings, the private nature of the repository, and the act of key rotation all point to a measured response. Even so, the company’s decision to revoke immediately is the practical part of the story: it protects users by removing any lingering trust in a compromised signing path.
Practical next steps
If you fall into a group that verifies signatures manually or relies on RPM packages, treat this update as a routine—but important—maintenance task.
- Import the new Firefox GPG key.
- Revoke or remove trust in the old exposed key.
- Follow Mozilla’s specific guidance for RPM-based workflows, if applicable.
- Re-check your signature verification steps to make sure they use the updated key material.
For everyone else, the update should be transparent: you can continue using Firefox as usual, and Mozilla’s key changes work behind the scenes.
Conclusion
Mozilla issued a new Firefox GPG key after discovering that a previous GPG signing subkey was accidentally exposed in a GitHub repository. Although Mozilla found no evidence of unauthorized access during the exposure, it chose to revoke the affected key, issue a replacement, and add safeguards to prevent similar mistakes.
Most users do not need to do anything. If you manually verify signatures or use Firefox RPM packages, update your trusted keys accordingly so your checks remain accurate and reliable.
Source: https://www.securityweek.com/mozilla-issues-new-firefox-gpg-key-following-exposure/
