Full Report
Audit logs found no unexpected visitors, but release verification still needs an update
Analysis Summary
# Incident Report: Mozilla Signing Key Exposure on GitHub
## Executive Summary
Mozilla discovered that an unencrypted GPG private subkey used for signing Firefox and Thunderbird releases was accidentally committed to a private GitHub repository. While audit logs indicated no unauthorized access occurred, Mozilla revoked the compromised key and issued a replacement to maintain the integrity of their software distribution pipeline. The incident primarily affects users who manually verify Linux packages or use Mozilla’s RPM repositories.
## Incident Details
- **Discovery Date:** August 10, 2026 (Public Disclosure)
- **Incident Date:** Unknown (Duration of exposure not disclosed)
- **Affected Organization:** Mozilla
- **Sector:** Technology / Software Development
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** Unknown
- **Vector:** Insider Mishap / Misconfiguration
- **Details:** An unencrypted copy of a GPG private subkey was checked into a private GitHub repository.
### Lateral Movement
- **N/A:** No evidence of unauthorized lateral movement was detected; access was limited to Mozilla employees already authorized to handle the key.
### Data Exfiltration/Impact
- **Data Exposed:** One GPG private subkey used for signing Linux tarballs, RPM packages, and checksum files for Firefox and Thunderbird.
- **Exfiltration:** Audit logs suggest no unauthorized parties accessed or exported the key.
### Detection & Response
- **Discovery:** Identified via internal review or automated scanning (specific discovery method not disclosed).
- **Response Actions:** Immediate revocation of the exposed subkey, generation of a new signing key, and public notification of the incident.
## Attack Methodology
- **Initial Access:** Accidental commit of sensitive credentials to source control.
- **Persistence:** N/A (No active threat actor identified).
- **Privilege Escalation:** N/A.
- **Defense Evasion:** N/A.
- **Credential Access:** Unencrypted private key stored in a repository.
- **Discovery:** Internal audit/scanning.
- **Lateral Movement:** N/A.
- **Collection:** N/A.
- **Exfiltration:** N/A.
- **Impact:** Potential for supply chain compromise (software spoofing/tampering), though no evidence suggests this was exploited.
## Impact Assessment
- **Financial:** Minimal; costs related to incident response and infrastructure updates.
- **Data Breach:** Exposure of a cryptographic subkey (no user data breached).
- **Operational:** Disruption for users of Fedora, RHEL, and SUSE who must manually update keys; updates required for build pipeline verification.
- **Reputational:** Moderate; highlights a lapse in secret management protocols.
## Indicators of Compromise
- **Network indicators:** None.
- **File indicators:** Revoked GPG Key ID (specific ID not provided in text).
- **Behavioral indicators:** Unauthorized access attempts in GitHub audit logs (none found in this instance).
## Response Actions
- **Containment:** Revoked the compromised GPG subkey.
- **Eradication:** Removed the unencrypted key from the GitHub repository history.
- **Recovery:** Distributed a new public signing key and a revocation certificate for the old subkey. Updated documentation for manual verification.
## Lessons Learned
- **Key Management:** Private keys should never be stored in source control, even in private repositories.
- **Secret Scanning:** Implementation of automated pre-commit hooks or CI/CD scanners could have prevented the commit before it reached the server.
- **Audit Logging:** Comprehensive logging proved essential in verifying that no unauthorized access occurred during the exposure window.
## Recommendations
- **Secret Management:** Utilize dedicated hardware security modules (HSMs) or secret management services (e.g., HashiCorp Vault, AWS Secrets Manager) where keys are never exported in unencrypted form.
- **Automated Scanning:** Deploy tools like `trufflehog` or GitHub Secret Scanning to detect high-entropy strings and credentials in real-time.
- **Mandatory Encryption:** Ensure all offline backups or shared copies of keys are encrypted with strong, unique passphrases.
- **Policy Enforcement:** Update developer training and repository policies to strictly forbid the inclusion of "dotfiles" or configuration files that might contain secrets.