Full Report
On February 27, 2025, Zapier detected that an unauthorized user had accessed some of its internal code repositories due to a two-factor authentication (2FA) misconfiguration on an employee’s account. While the breach did not affect production systems, databases, or payment inf...
Analysis Summary
# Incident Report: Zapier Internal Code Repository Access
## Executive Summary
On February 27, 2025, Zapier detected unauthorized access to internal code repositories stemming from a 2FA misconfiguration on an employee account. The breach allowed an attacker to access code, which inadvertently contained some customer debugging data, including plaintext authentication tokens. Zapier immediately revoked access, audited the systems, and notified customers, urging credential rotation.
## Incident Details
- Discovery Date: February 27, 2025
- Incident Date: On or before February 27, 2025
- Affected Organization: Zapier
- Sector: Technology / Workflow Automation
- Geography: Not specified (Online Service)
## Timeline of Events
### Initial Access
- Date/Time: Prior to February 27, 2025
- Vector: End-user compromise facilitated by a Two-Factor Authentication (2FA) misconfiguration on an employee account.
- Details: An unauthorized user gained entry to the network segment containing internal code repositories.
### Lateral Movement
- Vector: Credential harvesting/theft from the accessed code repository.
- Details: The attacker harvested credentials (plaintext authentication tokens embedded in debugging logs) found within the accessed repositories.
### Data Exfiltration/Impact
- Details: Some internal code repositories were accessed. Customer data (plaintext authentication tokens embedded in debugging logs) inadvertently present in the repositories may have been copied. Production systems and databases were **not** affected.
### Detection & Response
- Detection: February 27, 2025, when Zapier detected the unauthorized access.
- Response: Access for the unauthorized user was immediately revoked, and an audit of the incident commenced.
## Attack Methodology
- Initial Access: End-user compromise | Two-factor authentication (2FA) misconfiguration.
- Persistence: Not explicitly detailed, assumed control was maintained until manual revocation.
- Privilege Escalation: Not detailed, implied access leveraged the initial account vulnerability.
- Defense Evasion: Not detailed.
- Credential Access: Credential harvesting from code repositories (plaintext authentication tokens found in debugging logs).
- Discovery: Initial system/repository discovery implied post-initial access.
- Lateral Movement: Movement/access focused on code repositories; no mention of moving beyond that scope.
- Collection: Gathering plaintext authentication tokens/debugging logs.
- Exfiltration: Implied exfiltration of code repository contents and collected tokens occurred.
- Impact: Exposure of customer information/plaintext tokens via internal code repositories.
## Impact Assessment
- Financial: Not disclosed.
- Data Breach: Exposure of some customer data, specifically plaintext authentication tokens embedded in debugging logs copied into affected repositories. Core authentication systems were not compromised.
- Operational: No stated outage or disruption to production systems, databases, or payment infrastructure.
- Reputational: Public disclosure made to customers regarding potential exposure of credentials.
## Indicators of Compromise
- Network indicators: Not provided in the summary.
- File indicators: Not provided in the summary.
- Behavioral indicators: Unauthorized access/consumption of internal code repositories. Exposure of plaintext authentication tokens in source/debug logs.
## Response Actions
- Containment: Immediate revocation of the attacker’s access.
- Eradication: Auditing of the incident and affected repositories.
- Recovery: Urging impacted users to rotate any exposed credentials and activate 2FA on their accounts.
## Lessons Learned
- Critical failure in 2FA enforcement/configuration led to unauthorized access.
- Storing sensitive customer data, even for debugging purposes, within code repositories poses a significant risk.
- Debugging logs should never contain live/plaintext authentication tokens.
## Recommendations
- Immediate and comprehensive review of all employee 2FA configurations to ensure proper enforcement and prevent misconfigurations.
- Implement strict data loss prevention (DLP) policies to scan code repositories and configuration files for sensitive data, especially plaintext credentials, tokens, and customer PII/Auth data *before* committing.
- Audit existing debugging and logging procedures to remove sensitive authentication material from non-production environments or necessary logs.