Full Report
Mozilla announced today that it updated the GPG key used to sign Firefox and Thunderbird releases after it was accidentally exposed on GitHub. [...]
Analysis Summary
# Incident Report: Mozilla GPG Signing Key Exposure
## Executive Summary
Mozilla rotated and revoked the GPG signing key used for Firefox and Thunderbird releases after an unencrypted copy was accidentally committed to a private GitHub repository. While the key was exposed, Mozilla's audit found no evidence of unauthorized access or malicious use. The primary impact involves manual intervention for Linux users who verify signatures or install via RPM packages to ensure continued receipt of authentic updates.
## Incident Details
- **Discovery Date:** Prior to August 10, 2026
- **Incident Date:** August 10, 2026 (Public Disclosure)
- **Affected Organization:** Mozilla Corporation
- **Sector:** Technology / Software Development
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** Not specified (Historical commit)
- **Vector:** Accidental internal disclosure
- **Details:** An unencrypted GPG subkey was inadvertently committed to a private GitHub repository.
### Lateral Movement
- **N/A:** The incident was an accidental data exposure by authorized personnel within a controlled environment; no lateral movement by external threat actors was detected.
### Data Exfiltration/Impact
- **Data Exposed:** One GPG signing subkey (unencrypted).
- **Scope:** Impacted Linux tarballs, RPM packages, and checksum files for Firefox and Thunderbird.
### Detection & Response
- **Detection:** Discovered via internal audit of GitHub repository records.
- **Response actions taken:** Mozilla performed a forensic review of access logs, revoked the compromised subkey, generated a new subkey, and published manual update instructions for RPM users.
## Attack Methodology
- **Initial Access:** Misconfiguration/Human Error (Internal).
- **Persistence:** N/A.
- **Privilege Escalation:** N/A.
- **Defense Evasion:** N/A.
- **Credential Access:** Exposure of unencrypted private key in version control.
- **Discovery:** N/A.
- **Lateral Movement:** N/A.
- **Collection:** N/A.
- **Exfiltration:** Potential for unauthorized download (none found in audit logs).
- **Impact:** Risk of supply chain compromise (Distribution of malicious signed installers).
## Impact Assessment
- **Financial:** Minimal; limited to internal labor for remediation and support.
- **Data Breach:** Exposure of a cryptographic secret; no user data compromised.
- **Operational:** Disruption for Linux users (specifically RPM-based distros) requiring manual key imports to receive updates.
- **Reputational:** Minor; transparency in reporting helps maintain trust, though accidental exposure of signing keys is a significant security lapse.
## Indicators of Compromise
- **Network indicators:** None.
- **File indicators:** Revoked GPG Key ID (refer to keys.openpgp.org for specific fingerprints).
- **Behavioral indicators:** None reported.
## Response Actions
- **Containment:** Restricted access to the affected GitHub repository (access was already limited to a small group).
- **Eradication:** Revocation of the compromised GPG subkey.
- **Recovery:** Transitioned to a new GPG signing subkey expiring August 5, 2028; updated Nightly KEY files.
## Lessons Learned
- **Sensitive Data Handling:** Private cryptographic keys should never be stored in version control systems, even in private repositories, especially in unencrypted formats.
- **Audit Logging:** Maintaining robust audit logs for repository access allowed Mozilla to confidently determine that no unauthorized parties accessed the key.
## Recommendations
- **Automated Secret Scanning:** Implement pre-commit hooks and repository scanning tools (e.g., gitleaks, GitHub Secret Scanning) to prevent secrets from being pushed to version control.
- **Hardware Security Modules (HSM):** Utilize HSMs or dedicated key management services for signing operations so that private keys are never handled in plain text by developers.
- **Key Minimization:** Continue the practice of using subkeys for specific tasks to limit the impact of a single key exposure.