Circleci breach lessons for early detection and identity control

At a glance

What this is: This is an analysis of the CircleCI breach showing how stolen credentials, session cookies, and production access tokens let an attacker reach customer data and sensitive system resources.

Why it matters: It matters because IAM and NHI programmes have to control the full exposure window for credentials, sessions, and tokens, not just the first authentication event.

By the numbers:

• On December 16, 2022, unauthorized access to customer data was gained through a breach in CircleCI’s CI/CD platform.

👉 Read Unosecur's analysis of the CircleCI breach and identity control failures

Context

The CircleCI breach is a reminder that identity controls fail when attackers can move from one compromised credential to the next without interruption. In this case, malware on a worker laptop stole 2FA-backed credentials, then session cookies, then access tokens used to reach production systems and customer data.

For IAM and NHI teams, the issue is not only initial compromise. The breach shows how production access, token generation duties, and encrypted data access can all be pulled into the same attack path when identity governance does not limit what a single compromised user can do.

The article’s central lesson is that early detection matters, but identity exposure windows matter just as much. A customer alert triggered investigation, which means the incident was not stopped at the first malicious step; that is a typical failure pattern in environments where credentials, sessions, and tokens are treated as separate controls rather than one lifecycle.

Key questions

Q: What breaks when an attacker steals both session cookies and production tokens?

A: The control boundary between user authentication and machine access breaks. A stolen session cookie can impersonate a valid user, and a production token can extend that access into systems the user never directly touched. That combination turns one compromised endpoint into a wider identity and data exposure event.

Q: Why do misconfigured CI/CD workflows increase credential theft risk?

A: They combine execution, secrets access, and often write permission in a single runtime. If an attacker can influence the trigger or the command path, the runner may expose tokens that were meant for automation, not adversarial use. Once those credentials are stolen, the attacker can persist changes, widen access, or pivot into the broader supply chain.

Q: How do you know if identity monitoring is actually working?

A: Monitoring is working when exceptions surface quickly, owners are assigned, and deficiencies are corrected before the next review cycle. If stale access, failed certifications, or unresolved exceptions remain hidden in spreadsheets or ticket backlogs, the programme is reporting activity, not controlling risk.

Q: When should organisations separate human IAM from NHI governance?

A: Organisations should separate them whenever service accounts, API keys, tokens, or certificates are part of the access estate. Human identity controls are built around user behaviour and interactive authentication, while NHI governance must address secrets, standing privileges, rotation, and offboarding. Treating them as the same model leaves machine access under-governed.

Technical breakdown

How malware moved from endpoint access to production identity abuse

The entry point was a worker laptop infected with malware that stole 2FA-backed credentials. Once those credentials were reused against corporate systems, the attacker gained a second foothold and could continue into production-facing access paths. This is a classic credential relay problem: the first identity event is not the end state, it is the bridge to higher-value privileges when the same operator identity can authenticate into multiple environments. Practical implication: isolate privileged production access from endpoint-exposed user authentication paths.

Practical implication: separate production access from endpoint-exposed user authentication paths.

Why session cookies and access tokens create a wider blast radius than login credentials

The malware also stole session cookies, which let the attacker impersonate the employee remotely without repeating the original authentication flow. Because that employee generated access tokens for production systems, the compromise extended from a live session into reusable machine access. In NHI terms, this is where human identity compromise turns into machine identity exposure: the session becomes the handoff point for tokens, secrets, and keys. Practical implication: treat session theft as a machine identity event, not only a human account event.

Practical implication: treat session theft as a machine identity event, not only a human account event.

How production secrets, environment variables, and encryption keys were exposed

The article says the attacker accessed sensitive customer data from databases and stores, including environment variables, tokens, and keys, and even obtained encryption keys from a running process. That means secret storage, runtime memory, and production data access were all within reach once elevated privileges were obtained. This is not just secret leakage, it is runtime secret exposure plus overly broad operational access. Practical implication: protect secrets at rest and in memory, and separate the privileges needed to run systems from the privileges needed to extract data.

Practical implication: protect secrets at rest and in memory, and separate runtime privileges from data extraction privileges.

Threat narrative

Attacker objective: The attacker’s objective was to reach production systems and extract customer data, credentials, and encryption material for broader access or reuse.

1. Entry began on a worker laptop when malware stole the employee’s 2FA-backed credentials and bypassed normal trust boundaries.
2. Credential harvesting continued when the malware captured session cookies, allowing remote impersonation of the employee and reuse of the active session.
3. Escalation occurred when the employee’s role for generating production access tokens exposed higher-value system access and sensitive customer data.
4. Impact followed when the attacker extracted databases, environment variables, tokens, keys, and encryption material from production environments.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity compromise did not stop at the user account boundary. This breach shows how quickly a human login can become a production access problem when session cookies and access tokens are reachable from the same compromise path. The governance lesson is that identity assurance cannot be measured only at authentication time. Practitioners must treat session replay and token generation rights as part of the same control surface.

Early detection is necessary, but it does not compensate for uncontrolled exposure windows. CircleCI learned about the intrusion through a customer report, not through immediate internal containment. That delay matters because every additional hour extends the attacker’s opportunity to move from credential theft to data extraction. The breach reinforces the need to think in terms of exposure duration, not only detection capability.

Ephemeral session trust debt: session cookies, access tokens, and runtime secrets create a short-lived trust debt that becomes material the moment the endpoint is compromised. The breach worked because those artefacts were enough to impersonate an employee and reach production resources. That means identity teams have to govern the lifetime and reuse conditions of session material with the same seriousness as passwords and API keys.

Production token issuance is a privileged function and should be governed as such. The employee responsible for generating production tokens sat on a control point that turned one compromised workstation into a path toward sensitive stores. This is a governance failure in privilege design, not just an endpoint security issue. The practical conclusion is that token issuance authority needs tighter separation, auditability, and containment than ordinary user access.

The CircleCI case is a machine-identity problem reached through human compromise. Once the attacker moved from the employee’s identity into tokens, environment variables, and keys, the breach crossed into NHI territory. That boundary crossing is increasingly common in CI/CD environments, where human sessions can mint machine credentials. Practitioners should read this as a warning that human IAM and NHI governance now share the same blast radius.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Ephemeral credential trust debt: once a human session can mint or reach machine credentials, the organisation inherits a trust window that is easy to overlook and hard to recover from. Programme owners should design for the fact that session cookies, access tokens, and running-process secrets all become part of the same attack surface once endpoint compromise occurs.

The operational signal to watch is not only failed logins but unusual token generation, secret reads, and access from processes that should never inspect encryption material. A breach like this shows that identity monitoring has to span user access, production token issuance, and runtime secret exposure in one control model.

For practitioners

• Lock down production token issuance Move token creation and high-value credential generation into tightly monitored workflows with separate approvals and audit trails. A workstation compromise should not grant the ability to mint credentials for production systems.
• Reduce session replay value Shorten the usable lifetime of session cookies and bind high-risk sessions to stronger context so that a stolen cookie cannot be reused as a durable impersonation token.
• Segment endpoint identities from production access Keep laptop-authenticated user sessions away from the privileges needed to reach production secrets, keys, and databases. One compromised endpoint should not expose both user access and machine credentials.
• Treat runtime secrets as high-risk assets Inventory environment variables, access tokens, and encryption keys that can be reached from running processes, then restrict who can read or extract them during incident response.
• Build customer-triggered investigation playbooks Use external suspicious-activity reports as a trigger for immediate scope review, because customer-detected anomalies may be the first reliable sign of token abuse or session theft.

Key takeaways

• The breach showed how a stolen human session can become a machine-access problem when tokens, cookies, and runtime secrets are reachable from the same compromise path.
• The incident was detected after a customer raised suspicious GitHub OAuth activity, which is a reminder that internal monitoring may lag behind attacker movement.
• Stronger control over token issuance, session reuse, and runtime secret exposure would have narrowed the blast radius even after the initial laptop compromise.

Key terms

• Session Cookie Replay: The reuse of an authenticated session cookie by someone other than the original user. In identity governance terms, it means the login succeeded legitimately, but the trust boundary moved from authentication to session possession, making post-authentication monitoring and revocation central to defence.
• Production Token Issuance: The controlled act of creating access tokens that permit production-system actions or data access. In mature programmes, this is a privileged identity function, not an ordinary user task, because one compromised issuer can mint access that survives the original login boundary.
• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
• Identity Exposure Window: An identity exposure window is the period between when a credential or account becomes risky and when governance actually removes or contains it. The longer that window stays open, the more likely attackers can reuse the identity, escalate access, or turn a leak into a breach.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The attacker sequence from laptop compromise to production token abuse, with more detail on how each identity layer was reached.
• The platform's description of how anomaly detection and behavioral analysis are used to spot suspicious access patterns.
• The incident response framing around real-time monitoring, automated response, and scope determination after suspicious GitHub OAuth activity.
• The vendor's own explanation of how to prioritise vulnerabilities and compare user and entity behavior signals.

👉 The full Unosecur post covers the attack chain, identity exposure windows, and response lessons in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.