CircleCI - Malware on an Engineer's Laptop → A Live 2FA-Backed SSO Session Stolen → Production Access → Every Customer Secret Assumed Compromised
On December 16, 2022 malware was deployed on the laptop of a CircleCI engineer. It was not detected by the company's antivirus. What it stole was not a password but a live SSO session cookie - already authenticated, already backed by two-factor authentication - which let the actor impersonate that engineer remotely and escalate into a subset of production systems. CircleCI is a CI/CD platform, so those systems held customers' environment variables, API keys and tokens. A customer flagged suspicious GitHub OAuth activity on December 29; CircleCI began rotating all GitHub OAuth tokens on customers' behalf on December 31, and on January 4, 2023 published an advisory telling every customer to rotate every secret they had stored on the platform. The instruction is what makes this chain worth reading: not "we were breached" but "assume everything you gave us is compromised, and act today."
CircleCI's report is direct about the detection failure: the malware was not caught by the antivirus deployed on the machine. That is worth stating plainly rather than treating as an aside, because signature-based endpoint protection routinely misses current infostealers - the family is cheap, widely available, and repacked constantly to defeat exactly that. It is the same class of tooling that opened Snowflake, Vercel / Context.ai and Megalodon. Here the machine belonged to an engineer at a company whose product holds other companies' deployment credentials.
Target: The laptop of a CircleCI engineer
Detection: None - the deployed antivirus did not flag it
Malware class: Information stealer, the same family behind several other chains here
Why it matters here: That engineer's access reached customers' deployment credentials
This is the mechanism that makes the chain instructive. A session cookie is the artifact issued after authentication succeeds - it is the system's own record that the user proved who they were, including the second factor. Steal it and replay it, and you inherit that proof without repeating any of it. There is no password prompt, no MFA challenge, and no failed login for anyone to alert on. This is the same property that made the Okta HAR file tokens dangerous ten months later, arriving here from an endpoint rather than a support ticket, and it is why "we enforce MFA" and "our sessions cannot be stolen" are unrelated claims.
What it proves: That authentication already succeeded - including the second factor
Bypassed: Password entry, MFA challenge, and any sign-in-based detection
Result: Remote impersonation of the engineer
Same property abused in: The Okta support HAR files, ten months later
A CI/CD platform is a custodian of other organizations' most sensitive credentials by function: to build and deploy on a customer's behalf it must hold that customer's cloud keys, registry tokens and repository credentials. So an engineer with production access at such a company is, transitively, an engineer with access to thousands of other companies' production environments. CircleCI reported that fewer than five customers experienced confirmed unauthorized access to third-party systems - but the exposure was necessarily assumed across the whole customer base, because the compromised systems held all of it. That gap between "confirmed abused" and "must be assumed compromised" is where the real cost of this incident landed.
Held there: Customer environment variables, API keys, and access tokens
Structural point: A CI platform must hold customers' deployment credentials to function
Confirmed downstream abuse: Fewer than five customers
Assumed exposure: The entire customer base
Thirteen days elapsed between the malware landing and anyone noticing, and the notice came from outside. That is the same pattern as Okta, where three customers found the intrusion before the vendor, and it is a consistent enough shape across this library to be worth naming as an expectation rather than an anomaly: your monitoring of a vendor's behaviour in your environment is sometimes better than their monitoring of themselves, because you are watching a smaller surface with more context. The response from December 31 onwards was fast and unusually decisive - rotating tokens on customers' behalf rather than waiting for them to act.
December 29: A customer reports suspicious GitHub OAuth activity
December 31: CircleCI begins rotating all customer GitHub OAuth tokens itself
January 4: Public security alert and customer guidance
Pattern: Customer-side detection beating vendor-side, again
The advisory was the right call and it landed on organizations in wildly different states of readiness. Rotating every secret in a CI platform means knowing what they all are, what each one authorizes, what breaks when it changes, and having a path to replace it - and most teams discovered they had none of that. Some rotated in hours. Others spent weeks, or quietly did not finish. CircleCI's own remediation was substantial: restricting production access to a smaller group, adding authentication requirements, and deploying MDM and endpoint tooling targeting the specific behaviours used. But the transferable question is the one pointed at the customer, and it is worth answering before it is asked: if a platform you depend on told you today to rotate every secret you have given it, how long would that take?
Prerequisite most lacked: An inventory of what those secrets were and what they authorized
CircleCI remediation: Narrowed production access, added authentication requirements, deployed MDM and endpoint detection
The question to answer in advance: How long would a full rotation take you?