CircleCI, 2023: a stolen session, and every customer rotates their secrets.
Malware on one engineer's laptop stole a single sign-on session that already had two-factor authentication behind it. The attacker used it to reach production and extract customer secrets. What CircleCI's own incident report says.
Last updated Published by TryTrustableNot legal advice
On 16 December 2022 malware on a CircleCI engineer's laptop, not detected by antivirus, stole a valid single sign-on session cookie backed by two-factor authentication. The attacker used the session to reach production systems and, on 22 December, exfiltrated customer environment variables, tokens and keys, extracting the encryption keys from a running process. A customer alerted CircleCI on 29 December; it disclosed on 4 January 2023 and asked every customer to rotate their secrets.
What happened
| Date | What happened |
|---|---|
| 16 December 2022 | Malware is deployed to a CircleCI engineer's laptop. |
| 19 December 2022 | Unauthorised reconnaissance activity begins. |
| 22 December 2022 | Data is exfiltrated from production databases. |
| 29 December 2022 | A customer alerts CircleCI to suspicious GitHub OAuth activity. |
| 4 January 2023 | CircleCI discloses the incident and tells customers to rotate secrets. |
| 12 January 2023 | CircleCI publishes its incident report. |
Root cause
CircleCI's incident report sets out the chain. An engineer's laptop was infected with malware that "was not detected by our antivirus software". The malware stole a session cookie, which let the attacker impersonate the engineer. Because the session had already passed single sign-on and two-factor authentication, the second factor did not stop the attacker: they did not need to log in, they reused a session that was already logged in.
The engineer had privileges to generate production access tokens, so the attacker could reach a subset of production databases and stores. Customer data there was encrypted at rest, but the attacker extracted the encryption keys from a running process, which made the encryption ineffective against them.
Three control areas meet here: the security of the endpoint, the lifetime and binding of sessions for privileged staff, and the value of what a CI platform holds. A CI system stores the secrets that reach everything else, which is why the recommended response was to rotate all of them.
Impact and regulatory outcome
- Data: customer environment variables, tokens and keys stored in CircleCI.
- Onward harm: at the time of the report, fewer than five customers had told CircleCI of unauthorised access to third-party systems as a result.
- Response: CircleCI rotated GitHub OAuth tokens, project and personal API tokens and Bitbucket tokens on customers' behalf where it could, and asked customers to rotate the rest, including SSH keys and cloud credentials.
- Regulator: no regulator decision or court ruling about the incident was found in official sources, so the account here rests on CircleCI's own report.
CircleCI's report lists its own changes: detection and blocking of the malware's behaviour through its device management and antivirus tools, production access restricted to a very limited number of employees, additional step-up authentication for those who keep it, and monitoring for the behaviour patterns seen.
The controls that address it
| Control | SOC 2 criteria | ISO 27001:2022 Annex A |
|---|---|---|
| Endpoint protection and device management for staff laptops | CC6.8 | A.8.1, A.8.7 |
| Short session lifetimes and re-authentication for privileged actions | CC6.1 | A.8.5 |
| Privileged access limited to the people who need it | CC6.3 | A.8.2 |
| Secrets management: scoped, short-lived and rotated credentials | CC6.1 | A.5.17, A.8.24 |
| Monitoring for anomalous use of production access | CC7.2 | A.8.16 |
| Incident response that includes customer communication | CC7.4, CC2.3 | A.5.24, A.5.26 |
SOC 2 references are the 2017 Trust Services Criteria (points of focus revised 2022); Annex A references are ISO/IEC 27001:2022. These are the usual mappings: agree yours with your auditor.
How TryTrustable checks these controls
- Session lifetime: the Okta check tests the configured session lifetime, so long-lived sessions show up as a finding.
- Privileged accounts: super-admin counts in Okta and Google Workspace, GCP project owner count and service accounts holding Owner or Editor.
- Secrets: GCP Secret Manager rotation and user-managed service-account keys; AWS access key age; GitHub secret scanning; the SDK's secret scan in CI.
- Third-party grants: risky OAuth grants in Google Workspace.
- Monitoring: AWS GuardDuty and CloudTrail; GCP Data Access audit logs and Security Command Center.
- Response: the incident management module records the incident timeline and post-mortem.
TryTrustable does not detect malware on laptops and is not an endpoint protection product. The endpoint control in the table above needs a separate tool; TryTrustable can hold the policy and the evidence you collect from it.
These are the checks TryTrustable runs today. None of them is a claim about what would have happened in this incident: they test whether the control is in place in your environment, continuously, and record the result as audit evidence.
Sources
Every figure on this page is taken from the official documents listed here, read in October 2026. Regulatory findings quoted are the regulator's; where a company neither admitted nor denied them, or where proceedings are still open, the page says so. Not legal advice.
More case studies: all breach case studies · Research
The things people ask us
How did the CircleCI breach happen?
Malware on an engineer's laptop, undetected by antivirus, stole a single sign-on session cookie that was already backed by two-factor authentication. The attacker used it to impersonate the engineer and reach production systems.
Why did two-factor authentication not stop the CircleCI attack?
Because the attacker did not log in. They stole a session that had already passed single sign-on and two-factor authentication, and reused it. Short session lifetimes and re-authentication for privileged actions reduce that risk.
What data was taken from CircleCI?
Customer environment variables, tokens and keys. They were encrypted at rest, but the attacker extracted the encryption keys from a running process, according to CircleCI's report.
What should CircleCI customers have done?
CircleCI asked all customers to rotate their secrets, including OAuth tokens, project API tokens and SSH keys. Using short-lived credentials in CI limits how much a stolen secret is worth.
Check these controls in your own environment.
We connect GitHub and one cloud account in a demo and show which of these checks pass, with the evidence an auditor would ask for.