Mozilla updates GPG signing key for Firefox releases after exposure

Mozilla’s decision to revoke and replace a GPG signing subkey used for Firefox and Thunderbird releases after an unencrypted copy was inadvertently committed to a private GitHub repository demonstrates how seriously software vendors need to treat release-signing infrastructure. Mozilla says its investigation found no evidence that an unauthorized person accessed the key while it was present in the repository, and the repository itself was accessible only to a small number of individuals who already had legitimate access to that key through other channels. Nevertheless, the organization revoked the previous signing subkey and issued a replacement because cryptographic trust depends on confidence that the private key has remained secret. Once that assurance is weakened, even accidentally, continuing to rely on the same key creates unnecessary software supply-chain risk. 

The exposed subkey was used to sign certain Firefox and Thunderbird release artifacts, including Linux tarballs, Firefox RPM packages and checksum files. This distinction is important because it means the incident should not be described as exposing a universal signing key capable of impersonating every Firefox distribution or update channel. Most Firefox and Thunderbird users are not required to take action, and Mozilla has not reported evidence that malicious releases were signed or distributed using the exposed key. The security concern is therefore potential rather than confirmed abuse, but the potential consequences of unauthorized access to a release-signing key are serious enough to justify immediate rotation.

Software signing provides users and package managers with a way to verify that a release genuinely came from the expected publisher and that the artifact has not been modified after signing. The private signing key is what makes that assurance possible. If attackers obtain the private key, they may be able to create a malicious package and generate a cryptographic signature that appears legitimate to systems trusting the corresponding public key. A downloader or administrator could therefore receive malware while signature verification reports that the package was correctly signed.

This is why code-signing and release-signing keys represent an unusually powerful form of credential. Stealing an employee password may compromise one account, while stealing a signing key can potentially compromise trust across an entire software distribution ecosystem. The more widely deployed the software, the greater the leverage available to an attacker who gains signing authority.

Firefox is used by hundreds of millions of people and is distributed through multiple operating-system ecosystems, making its release infrastructure a particularly sensitive target. Even when a particular key is limited to certain Linux packages or manifest files, compromise could affect downstream Linux users, distributions or organizations that rely on GPG verification to establish release authenticity.

The Mozilla incident did not involve a public GitHub repository. The key was committed to a private repository with access limited to a small group inside Mozilla. This significantly reduces the likelihood that an external attacker obtained it, and Mozilla’s review of available audit records found no evidence of unauthorized access. However, private repositories should not be treated as appropriate long-term storage for unencrypted signing keys merely because repository access is controlled.

A source-code repository exists to make information available to developers and automated systems. A signing private key should ideally be usable only within a tightly controlled signing environment. Mixing those security models increases the number of places from which the key can potentially be retrieved and makes accidental exposure easier.

The correct question when evaluating such an event is not simply whether GitHub was public or private, but whether every identity and automated system capable of accessing the repository should also have been capable of obtaining the signing key. Even if those access populations happened to overlap in this particular case, embedding the key in source history creates another uncontrolled copy that must be discovered and revoked.

Git repositories create additional complications because deleting a sensitive file from the latest branch does not necessarily remove it from history. Commits are designed to preserve previous versions, meaning secrets accidentally checked into Git can remain accessible through earlier objects even after developers believe they have removed them. Incident response must therefore assume that once a private key has been committed, every person or system capable of retrieving that repository during the exposure window may potentially have obtained it.

This is one reason secret-scanning systems have become essential within modern development environments. Automated scanners can detect private keys, cloud credentials, API tokens and passwords before or immediately after they are committed. Pre-commit hooks can stop obvious secrets before they enter repository history, while server-side scanning can alert security teams when developers bypass local controls.

Secret scanning should not rely purely on matching known token formats because cryptographic private keys can appear in recognizable PEM or GPG structures that security tools can identify directly. Repositories containing release infrastructure deserve particularly strict policy because one accidental commit can affect the integrity of every downstream customer relying on the software.

Prevention becomes stronger when developers never possess exportable production signing keys on ordinary workstations. If a private key can be copied into a source repository, emailed, placed in a home directory or uploaded to a cloud drive, the organization has already created numerous opportunities for accidental leakage.

Hardware Security Modules and dedicated signing services provide a stronger model. The signing private key remains inside a protected cryptographic environment and software sends signing requests rather than retrieving the raw key. Even highly privileged developers may be able to request approved signatures without ever obtaining the underlying private material.

This distinction substantially reduces the consequences of workstation or repository compromise. Attackers might abuse the signing service if they obtain sufficient authorization, but they cannot simply steal the key and continue signing malicious software indefinitely from their own infrastructure. Signing operations can also be centrally audited and subjected to additional controls.

A mature release-signing system should require stronger authorization than an ordinary source-code commit. Sensitive production releases can require multiple approvals, verified build artifacts and isolated workflows before the signing service accepts a request. This prevents one compromised developer account from immediately becoming a software-distribution compromise.

The build system itself deserves equal protection because signing a malicious artifact legitimately can be just as damaging as stealing the key. Attackers compromising CI/CD pipelines may modify source code or build outputs before they reach the signer. The cryptographic signature then correctly verifies the malicious artifact because the trusted build process itself has been subverted.

Software supply-chain security therefore requires three separate assurances: the source code is trustworthy, the build process produces the intended artifact, and the signing authority has not been compromised. Protecting only the private key does not solve the other two problems.

Reproducible builds can provide additional assurance by allowing independent systems to verify that distributed binaries correspond to published source code. When multiple trusted environments can generate matching artifacts, compromising one build server becomes less likely to produce undetected modifications.

Mozilla’s response also demonstrates why signing keys should have limited lifetimes. The new subkey expires on August 5, 2028, continuing Mozilla’s practice of periodically rotating signing subkeys. Regular rotation limits how long a secretly compromised key remains valuable and ensures organizations have operational experience replacing keys before an emergency forces them to do so.

Routine key rotation is useful because emergency replacement can expose compatibility problems. Package managers and operating systems do not all handle key updates and revocations identically, as Mozilla’s current guidance demonstrates. Some Linux systems will accept the new key automatically, while others require administrators to remove the previous key manually.

Fedora 43 and later can obtain the updated key through the package-management process, although users should verify the displayed fingerprint before accepting it. Older Fedora releases and RHEL, Rocky Linux and AlmaLinux systems may need the previous key removed manually because their DNF tooling cannot automatically replace it. openSUSE and SUSE systems have similar manual requirements.

This illustrates an operational side of cryptographic incident response that organizations sometimes overlook. Rotating the key is technically straightforward; ensuring every downstream system recognizes the replacement can be much harder. A security response that breaks software updates across large numbers of systems can create another vulnerability by preventing future security releases from being installed.

Organizations distributing signed software should therefore test emergency key-rotation procedures across every supported package ecosystem before an incident occurs. Documentation should explain what administrators need to do when a signing key is revoked, how they can verify the new fingerprint and which trusted channel should be used to obtain replacement key material.

Independent verification of the new key is extremely important. If a user downloads both a software package and its new signing key from the same compromised website, an attacker controlling that website could simply supply a malicious package and their own matching key. The key fingerprint should therefore be confirmed through an independently trusted source.

Mozilla publishes the new fingerprint and makes the public key and revocation information available through official Firefox Nightly KEY files and public OpenPGP infrastructure. Administrators performing manual verification should compare fingerprints rather than trusting a key merely because its user ID contains a familiar organization name.

GPG identities themselves are not sufficient evidence of authenticity. Anyone can create a key claiming to belong to “Mozilla Software Releases.” Trust comes from verifying that the key fingerprint matches a value distributed through an authenticated channel.

The old key’s revocation is just as important as publication of the replacement. If systems continue trusting both the old and new keys indefinitely, an attacker who obtained the previous private key could still sign malicious artifacts successfully. Revocation communicates that signatures generated with the old key should no longer establish trust.

Mozilla notes that due to the way GPG signing and revocation work, releases signed with the previous key will no longer verify after the revocation is imported. This can create inconvenience for organizations that archive historical packages and later attempt to verify them, but it is a deliberate security trade-off. Once a key’s secrecy cannot be guaranteed, preserving its trust indefinitely would create continuing risk.

Organizations that require long-term verification of archived software may therefore need additional mechanisms such as timestamped transparency logs, archived signature metadata or internally maintained provenance records. Long-term software authenticity is a more complicated problem than simply preserving an old detached signature forever.

The incident also provides a useful example of transparent security communication. Mozilla disclosed that the key was exposed, explained where the exposure occurred, clarified that there was no evidence of unauthorized access and published specific steps for affected users. This allows administrators to distinguish between a confirmed malicious supply-chain compromise and a precautionary key rotation.

That distinction matters because exaggerated reporting can cause unnecessary panic. There is currently no evidence that attackers used the exposed Mozilla key to sign malicious Firefox or Thunderbird releases. The security event involved a confidentiality failure affecting the private key, followed by precautionary revocation.

At the same time, the absence of observed misuse does not justify retaining the key. Audit logs can show who accessed a repository through expected mechanisms, but they cannot always prove conclusively that no unauthorized copy was made through every possible route. Cryptographic incident response should therefore err toward eliminating uncertainty when rotation is operationally feasible.

The Mozilla event illustrates the difference between credentials that can simply be monitored and credentials that must be replaced after exposure. If a password appears in a repository, the appropriate response is to change it. A private signing key should be treated similarly: once confidentiality is uncertain, the safe state is a new key.

Deleting the secret alone is inadequate because an attacker who already copied it retains the credential. Security teams occasionally focus on removing leaked material from Git history without performing rotation. That improves future confidentiality but does nothing about copies already obtained.

Organizations should maintain automated processes for revoking and replacing production secrets after repository exposure. Manual incident response becomes slow and error-prone when developers have to determine individually which systems depend on a credential and how to update them.

A central secrets inventory can dramatically improve this process. Security teams should know which signing keys, API credentials and certificates exist, what systems use them, who can access them and when they expire. Without this information, the discovery of one exposed secret can turn into a frantic search across pipelines and production environments.

Signing keys deserve especially strict inventory because organizations may maintain different keys for operating systems, package repositories, source archives and release channels. One product can therefore depend on numerous cryptographic identities whose ownership and rotation requirements need to remain clear.

Access to signing infrastructure should follow least privilege. Developers who need to submit code changes do not automatically need permission to sign production releases, while systems that sign Linux RPM packages should not necessarily possess keys for unrelated Windows or macOS distribution channels.

Separating signing keys by platform and artifact type limits blast radius. Mozilla’s incident itself illustrates some benefit from this architecture because the exposed GPG subkey related to particular Linux artifacts and checksums rather than every software-signing mechanism associated with Firefox and Thunderbird.

Key separation also improves incident response. If one subkey becomes suspect, the organization can revoke that specific credential without replacing every signing identity across the product ecosystem.

Network isolation is another valuable control. Signing infrastructure should not be broadly reachable from developer networks or the public internet. Jobs can submit artifacts through carefully authenticated interfaces while the cryptographic service remains within a restricted environment.

Signing systems should generate tamper-resistant logs recording every artifact hash, identity requesting the signature and timestamp. Security teams can then compare historical signing activity against official releases and detect unexpected operations.

Transparency logs provide an even stronger model by making signatures publicly auditable. Software vendors can publish signed artifact metadata into append-only systems where customers and researchers can detect unauthorized releases. Similar principles have dramatically improved certificate transparency within the web PKI and can be applied to software supply chains.

Organizations consuming software also have responsibilities. Enterprises should verify package signatures rather than assuming that HTTPS alone guarantees authenticity. TLS protects the download session but cannot prove that the file stored on the vendor’s server was generated by the legitimate release process.

Linux distributions already rely heavily on package-signing systems for exactly this reason. Repository metadata and packages are checked cryptographically before installation. The Mozilla key rotation may create additional administrative work on some RPM systems, but signature validation is what allows those systems to detect unauthorized modifications in the first place.

Administrators should avoid disabling signature verification simply to bypass key-rotation errors. If Firefox updates suddenly fail because the repository key has changed, the correct response is to import and verify the new Mozilla key following official instructions. Disabling GPG checks turns a temporary update inconvenience into a permanent supply-chain weakness.

This behaviour becomes particularly important during security incidents because attackers may deliberately exploit user frustration. A malicious forum post telling administrators to use an insecure package-manager option to bypass signature errors could undermine the very protection key rotation was intended to restore.

Enterprises should distribute new trusted keys centrally through configuration-management systems rather than requiring every administrator or endpoint to retrieve them independently. Central validation reduces the opportunity for users to import the wrong key and makes future rotation easier.

The Mozilla incident also highlights the value of repository access logging. The organization was able to review audit records and establish that repository access was restricted to individuals already authorized to use the signing key. Without reliable audit logs, the uncertainty around potential exposure would have been considerably greater.

Private Git hosting should therefore log repository clones, token usage, unusual downloads and permission changes, particularly for repositories containing security-sensitive infrastructure. Organizations should retain these records long enough to support investigations discovered months after the original event.

Developer credentials protecting sensitive repositories should use phishing-resistant MFA. A private repository provides meaningful security only if attackers cannot easily steal one authorized user’s session and retrieve its contents.

Organizations should also restrict personal access tokens and CI/CD credentials according to repository scope. A token used by an unrelated automation job should not automatically permit cloning repositories that contain release infrastructure.

The fact that the private key was stored unencrypted is another important lesson. Encryption at rest would not necessarily prevent every form of exposure, particularly if decryption credentials were stored nearby, but raw signing keys should not normally exist as ordinary plaintext files within developer repositories or workspaces.

Encrypted key material protected by a strong passphrase can add another barrier, although unattended production signing often requires automation that makes local passphrase management difficult. Hardware-backed signing remains the stronger design where practical.

Developer training also matters because accidental secret commits are extraordinarily common. Git commands make it easy to add an entire directory without noticing that it contains credentials, local configuration or private material. Automated controls need to compensate for this ordinary human behaviour rather than relying on every developer remembering every sensitive filename.

Repository templates should include default ignore rules for common key and credential formats. IDE plugins and pre-commit security checks can provide warnings before potentially sensitive content reaches a remote repository.

Security teams should treat secret exposure metrics as an engineering signal rather than merely blaming the individual responsible. If developers repeatedly commit sensitive credentials, the organization’s workflow is allowing secrets to exist too close to ordinary source development.

The correct long-term response is reducing opportunities for developers to access exportable production credentials in the first place.

The incident also provides a broader lesson about software supply-chain trust. Users rarely inspect the source code of every software update they install. Instead, they depend on a chain of evidence: the package came from the expected repository, its signature matches the publisher’s trusted key and the publisher has protected that key.

A single exposed signing credential can weaken that entire chain because cryptographic verification cannot distinguish between a legitimate publisher using the private key and an attacker who has copied it. Cryptography proves possession of the key, not the identity or intent of the person using it.

That is why key management is ultimately as important as the strength of the cryptographic algorithm itself. RSA, EdDSA or another strong algorithm provides little protection if the private key sits unencrypted inside a repository accessible to an attacker.

Organizations developing software should therefore classify signing keys at the same security level as root cloud credentials, domain-administration credentials and other high-impact secrets. They should use dedicated signing services, limited access, independent approvals, immutable logs and rapid revocation procedures.

Incident-response exercises should include signing-key compromise scenarios. Teams need to know how to stop release publication, revoke the affected key, issue a replacement, update repositories and communicate the change to customers. Discovering these dependencies for the first time during a real exposure can significantly delay remediation.

Customer communication must also anticipate compatibility problems. Mozilla’s detailed instructions for different RPM distributions demonstrate that key rotation is not merely a cryptographic exercise. Users need practical guidance for restoring normal update functionality securely.

Thunderbird users face fewer package-management complications because Mozilla does not distribute official Thunderbird RPM packages, but users who manually verify Thunderbird GPG signatures still need to update their trusted key information. This distinction should be communicated clearly so users do not perform unnecessary changes.

Most Firefox users receiving updates through ordinary supported mechanisms do not need to take action. The event therefore should not cause users to uninstall Firefox or distrust previously installed releases without evidence of malicious signing. Mozilla’s available audit data does not indicate that the exposed subkey was abused.

The incident instead provides a good example of precautionary security engineering. The cost of rotating the key and helping some Linux users update their configuration is lower than accepting continuing uncertainty around a credential capable of validating software releases.

For enterprises, the lesson is equally relevant regardless of whether they develop consumer software. Internal package repositories, container registries, firmware builds and configuration bundles increasingly rely on cryptographic signing. Compromise of those signing identities can allow attackers to distribute trusted malware internally without defeating endpoint security through conventional methods.

Organizations adopting software provenance technologies such as signed containers and build attestations should remember that the assurance remains dependent on protecting the signing identity. Adding cryptography to the pipeline improves security only when the associated keys are managed more carefully than ordinary files.

The broader objective should be to make unauthorized signing both technically difficult and operationally visible. No single person or developer workstation should contain everything necessary to produce a trusted production release secretly.

Mozilla’s decision to revoke the exposed subkey despite finding no evidence of unauthorized use is therefore the correct security posture. Signing systems exist to establish trust, and once the confidentiality of the key becomes uncertain, the trust decision should be reset rather than defended through optimism.

The strongest lesson from this incident is simple: private signing keys should remain private not merely through policy but through architecture. They should not be exportable into places where an accidental Git command can turn them into repository content. 

Mozilla announced today that it updated the GPG key used to sign Firefox and Thunderbird releases after it was accidentally exposed on GitHub. [...]

Source: Mozilla updates GPG signing key for Firefox releases after exposure via Bleeping Computer — published 11 Aug 2026.