Mozilla Revokes Firefox GPG Signing Key After Accidental GitHub Exposure

In a recent security update, Mozilla announced that it has revoked and replaced the GPG signing subkey used to verify software artifacts for Mozilla Firefox and Mozilla Thunderbird. The proactive key rotation followed the discovery that an unencrypted copy of the private signing subkey had been inadvertently committed to a GitHub repository.

While code signing key exposures pose significant software supply chain risks, Mozilla’s audit indicated that the risk was strictly contained. The affected GitHub repository was private and accessible only to a restricted group of internal Mozilla developers who already possessed legitimate access to the key via other means. Furthermore, Mozilla confirmed that a review of available audit logs revealed no evidence of unauthorized access to the key during the window it remained in the repository.

Accidental Private Key Leak in Internal Repository

The incident occurred when an unencrypted version of the cryptographic signing subkey was included in a git commit pushed to a private GitHub repository. Cryptographic keys used in build pipelines are typically stored in secure hardware security modules (HSMs) or secrets management vaults with strict access controls. When private keys end up stored in plaintext within source control, automated secret scanners or developer checkouts can permanently record them in git history, making revocation the only safe remedy.

The affected subkey was specifically responsible for signing non-Windows and non-macOS release artifacts. This included Linux source tarballs, Red Hat Enterprise Linux and Fedora RPM packages, and associated cryptographic checksum files (SHA256SUMS).

Upon identifying the committed secret, Mozilla initiated incident response protocols to revoke the compromised subkey, generate a replacement GPG signing subkey, re-sign affected release assets, and implement additional automated safeguards to block secrets from being checked into internal repositories in the future.

Supply Chain Risks of Compromised Code Signing Keys

In software distribution architectures, GPG signatures serve as the primary mechanism for end-user verification of package integrity and publisher authenticity. When a downstream user downloads an RPM package or source tarball, their package manager or local GPG installation validates the file’s digital signature against the vendor’s public key.

If an adversary obtains an unencrypted private GPG signing key, they gain the technical capability to sign arbitrary binaries or modified installation scripts. This enables classic software supply chain attacks, including:

• Malicious Software Injection: Attackers can alter legitimate release tarballs or RPM binaries to embed backdoors, infostealers, or persistence mechanisms while maintaining a cryptographically valid signature.
• Bypassing Integrity Checks: Standard Linux package managers (such as dnf, yum, or zypper) and manual verification workflows (gpg --verify) will recognize poisoned binaries as legitimate releases published by Mozilla.
• Mirror Compromise Exploitation: If an attacker combines a leaked signing key with a compromised download mirror, malicious DNS redirection, or a man-in-the-middle position on unencrypted mirrors, they can push infected updates to end users without triggering signature alerts.

Given the sharp rise in supply chain attacks targeting open-source development ecosystems, rotating cryptographic material immediately upon potential exposure is standard security hygiene, even when evidence suggests external threat actors never accessed the credential.

Impact and Mitigation Context

Mozilla emphasized that the vast majority of Firefox and Thunderbird users remain unaffected by this key rotation:

• Standard Desktop Users: Users on Windows and macOS, as well as Linux users updating through default system package managers configured with vendor-managed repositories (such as Ubuntu’s apt), rely on different code signing certificates and distribution channels that were not involved in this incident.
• Audit Findings: Internal audit logs confirmed that no external or unauthorized accounts accessed the private repository during the exposure window.
• No In-the-Wild Exploitation: There is no indication that malicious software signed with the exposed subkey was ever created or distributed.

Required Actions for Linux Users and Package Maintainers

While automated updates handle safety for most mainstream users, administrators, Linux package maintainers, and users who manually verify software releases must update their local trust store.

1. Manual GPG Verification: Users who download Firefox or Thunderbird source tarballs, binaries, or checksum files directly from Mozilla and verify signatures manually using gpg must import the newly published Mozilla public key and import the revocation certificate for the old subkey.
2. RPM Package Users: Users relying on official Firefox RPM packages should import the updated GPG public key into their system keyring using their distribution’s package management tool (e.g., rpm --import <path-to-new-mozilla-key>). This ensures future software updates sign-checked by dnf or yum succeed without trust validation failures.
3. Repository Administrators: Organizations hosting internal mirrors or repackaging Mozilla binaries for enterprise deployment should immediately flush cached signatures and re-verify incoming packages against Mozilla’s updated signing key pair.

Mozilla has published detailed step-by-step instructions and updated public keyring files on its official distribution portal.