CI/CD Credential Exposure: What Attackers Steal From Pipelines and What to Rotate

CI/CD credential exposure is the leak of pipeline-held secrets, including cloud keys, access tokens, and signing material, to parties outside the build's trust boundary. CI/CD credential exposure happens through the builds themselves: dependencies, logs, artifacts, workflow files, and the platforms that run them. Exposure differs from confirmed theft, and the difference drives response, since a leaked credential warrants rotation whether or not misuse is proven.

The scale is not theoretical. CloudSEK's AI supply chain breach report reconstructed the March 2026 LiteLLM supply chain attack, attributed to the threat actor group TeamPCP, which potentially exposed more than 2,500 organizations and roughly 434,000 CI/CD pipelines, including a verified set of Indian companies. Poisoned LiteLLM releases, live on PyPI for roughly 40 minutes, let attackers sweep SSH keys, cloud keys, repository tokens, Kubernetes tokens, and AI provider keys straight from build runners. That incident anchors the exposure this article takes apart: what pipelines hold, how it leaks, and what to rotate first.

Pipelines concentrate privilege by design. A deploy job legitimately needs the keys to code, cloud, registries, and production at the same moment, so the automation that ships software doubles as a credential warehouse. Attackers treat it exactly that way.

Where Credentials Live Inside a Pipeline

A pipeline holds secrets in 5 places, and each place fails differently. Secret stores, configuration files, process memory, logs and artifacts, and caches all deserve a line in the exposure inventory.

• Platform secret stores and environment variables: Encrypted at rest inside the CI platform, decrypted into the job's environment at runtime. Any code executing inside the job reads them in plaintext.
• Workflow and configuration files: Hardcoded tokens in YAML, scripts, and .env files committed to repositories. Version history preserves a secret long after a cleanup commit removes it. MCP (Model Context Protocol) configuration files joined this location in 2025, leaking 24,008 unique secrets on public GitHub by GitGuardian's count.
• Runner process memory: Live credentials held by build processes for the duration of a job. Memory scraping recovers values that never touch a log or a file. In the LiteLLM incident, TeamPCP's stealer scraped secrets directly from process memory at /proc/<pid>/mem, including the values GitHub Actions tries to mask.
• Build logs and artifacts: Secrets printed by debug output, error dumps, or misconfigured steps, then stored wherever logs and artifacts persist. Retention settings decide how long a one-time mistake stays readable.
• Caches and runner images: Dependency caches, container layers, and virtual machine snapshots that carry credentials past the job that created them. A cache pull reads yesterday's secrets today.

An inventory that covers only the secret store misses the other four locations. Rotation plans built on partial inventories rotate partially.

What Attackers Steal From Pipelines

Attackers steal 7 major credential classes from pipelines: platform tokens, cloud keys, version control system (VCS) credentials, signing material, registry tokens, Kubernetes tokens, and SaaS (software as a service) and AI provider keys. The table maps each class to the access it grants and the rotation wave it belongs to.

Priorities interact because credential classes chain. A VCS token rewrites a workflow, the workflow reads the secret store, and the store holds every other class in the table. Rotation order exists to break these chains before attackers walk them. The LiteLLM incident began exactly this way: one leaked automation token, rotated but not fully revoked, gave the attacker an approximately 20-day window to push malicious code over the Trivy scanner's published version tags.

How Pipeline Credentials Leak

Pipeline credentials leak through 6 paths, and a documented incident proves each one. A supply chain attack supplies the delivery mechanism in three of the six.

Malicious dependencies and install-time code

A poisoned package executes during installation inside the runner and inherits every secret the job holds. The TeamPCP campaign of March 2026 ran this play at scale. A compromised Trivy security scanner, installed unpinned in LiteLLM's own CI pipeline, poisoned the LiteLLM build, which then published malicious versions 1.82.7 and 1.82.8 to PyPI. 

The payload ran from a malicious .pth file that executes at Python interpreter startup, so installation alone triggered it, no import required, and the ignore-scripts protection teams rely on never applied. No vulnerability is required, just presence in the dependency tree. Cloud keys were read straight from the instance metadata service and Kubernetes tokens from mounted service-account paths, using only the access each runner already carried.

Workflow injection and compromised actions

Attackers with repository access modify workflow files to post secrets outward, or compromise a shared action consumed by thousands of builds. The GhostAction campaign of September 2025 stole 3,325 secrets across 817 repositories through injected workflow files, and the tj-actions compromise of March 2025 dumped secrets into public build logs.

Logs and artifacts

Secrets echo into build output through debug flags, verbose errors, and careless print statements, then persist wherever logs are stored. Travis CI exposed close to 73,000 tokens and credentials through build logs the platform kept accessible by design. Retention turned a logging decision into a standing breach.

CI platform compromise

A breach of the CI provider itself exposes every customer secret the platform stores. The CircleCI incident of January 2023 started with one malware-infected engineer laptop and a stolen session cookie, and it ended with customers rotating every secret they had ever stored on the platform.

Over-scoped tokens and forked pull requests

Long-lived tokens with broad scopes turn a small foothold into wide access, and pipelines that pass secrets to forked pull requests hand them to strangers. GitLab's vulnerability CVE-2024-9164 allowed unauthorized users to trigger pipelines on arbitrary branches, reaching secrets configured for protected ones.

Self-propagating worms

Malware that steals one developer's tokens and uses them to poison that developer's other packages compounds across the ecosystem. The Shai-Hulud npm worm of 2025 harvested personal access tokens and ran an open-source secret scanner offensively inside victim environments to find more.

Why Detection Lags Behind Theft

Pipeline credential theft evades detection because the theft is a build. The malicious step runs inside a job that was scheduled to run, on a runner expected to execute code, with credentials the job was issued legitimately. No alarm separates reading a secret to deploy from reading a secret to steal.

Log masking deepens the false comfort. Masking redacts secrets from build output, and it does nothing for the process memory where values sit in plaintext during execution. The LiteLLM stealer proved the point, scraping masked GitHub Actions values directly from /proc/<pid>/mem. Stealers read memory, not logs.

Three signals cut through the noise anyway: token use from infrastructure the team never provisioned, workflow file changes no engineer recognizes, and repositories or identities that appeared without a ticket. Each one is checkable today from audit logs. The last signal is not hypothetical: where exfiltration failed, the LiteLLM malware created a public repository inside the victim's own GitHub account, under names like tpcp-docs or docs-tpcp, and uploaded the stolen data there as a release asset.

Scanning covers the wrong path for this problem. Secret scanners watch the write path, flagging credentials as they land in code and logs, while theft happens on the read path inside a running job. Both matter; only one gets tooling by default.

Time completes the cover. Stolen tokens generate API (application programming interface) calls rather than logins, so no failed-authentication signal fires, and attackers commonly validate credentials quietly weeks after the leak. The FBI's July 2026 FLASH advisory on TeamPCP (FLASH-20260702-01) warned that affiliated actors are likely to weaponize the harvested credentials long after the original intrusion. Teams that scope incident review to the day of exposure miss the window where misuse actually happens.

What to Rotate After Pipeline Exposure: Priority Order

After pipeline exposure, teams rotate credentials in 5 waves: platform tokens, cloud keys, VCS credentials, signing material, and downstream service keys. Five verbs order the work: revoke, rotate, replace, reissue, refresh. Waves rank urgency instead of a strict serial order, so separate owners take the later waves in parallel once wave 1 lands.

The order is not arbitrary. On every compromised runner in the LiteLLM incident, TeamPCP's stealer escalated to root and swept SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, .env files, CI/CD secrets, and AI provider keys, and every one of those classes maps to a wave below. The rotation sequence decides which of them an attacker keeps after cleanup.

Revoke platform sessions and tokens first

Revoke every CI platform API token, OAuth app grant, runner registration token, and active session before rebuilding anything. Revocation cuts live attacker access; replacement alone leaves the old value working until expiry. The LiteLLM chain started with a token that was rotated but not fully revoked. Platform audit logs pulled in this wave bound the exposure window that every later wave depends on.

Rotate cloud access keys and hunt new identities 

Rotate every cloud key readable from the pipeline, then audit IAM (identity and access management) for users, roles, and keys created during the exposure window. Attackers plant fresh identities so that rotating the stolen key changes nothing.

Replace VCS credentials and audit repositories

Replace personal access tokens, deploy keys, SSH keys, and webhook secrets, and review commits, workflow changes, and new repositories across the same window. A single surviving repository token restarts the whole incident.

Reissue signing keys and certificates

Treat signing material as the slow, high-consequence wave: revoke certificates, reissue keys, and re-sign current artifacts so consumers reject anything the attacker signed. Consumers need the new trust anchors before the old ones die, so sequencing beats speed here.

Refresh downstream and service credentials

Finish with registry tokens, Kubernetes service-account tokens, SaaS integrations, AI provider keys, and recreated environment variables. AI keys deserve their own check, since leaked AI API keys rarely trigger login alerts when reused. Downstream systems accept old values until each one is individually replaced.

Inventory precedes all 5 waves, since teams rotate only what they know exists. The CircleCI rotation advisory set the template, walking customers through tokens, variables, contexts, SSH keys, and runner tokens one location at a time, paired with log review from the first day of intrusion. The 2025 Salesloft Drift token theft forced the same drill on hundreds of connected Salesforce tenants, which is how a rotation template proves it transfers. GitGuardian's retesting shows why the discipline matters: 64% of credentials that leaked in 2022 still worked in January 2026.

Hardening: Make Stolen Credentials Worthless

Hardening rests on 5 controls that shrink what a stolen credential is worth. Prevention here means devaluation, not just protection.

Replace Static Secrets With Short-Lived Identity

Issue pipeline credentials through OIDC (OpenID Connect) federation so each job receives a token scoped to itself that expires within minutes. A stolen token that dies before validation is a stolen nothing. Bind each token's subject claims to the repository, branch, and environment it serves, and a token minted for one job fails everywhere else.

Scope Every Token to a Single Job

Grant each token the minimum role, repository, and environment its job requires, and separate privileged deploy steps from unprivileged build steps. Scoping converts a full compromise into a partial one. Protected environments and branch rules put deploy credentials behind conditions a hijacked build step fails to meet.

Isolate Secrets From Untrusted Steps

Withhold secrets from forked pull requests, third-party actions, and any step that installs unreviewed code. Pin dependencies and shared actions to verified hashes, since LiteLLM's pipeline pulled its compromised scanner unpinned and inherited the poison automatically. 

Require approval gates before workflows from outside contributors touch secret-bearing contexts. Workflow triggers that run external contributions with elevated permissions deserve close review, since they hand fork code a privileged context.

Plant Honeytokens in Pipeline Stores

Seed secret stores with decoy credentials that alert the moment anything uses them. A customer's decoy AWS key surfaced the CircleCI breach before the platform itself detected the intrusion. 

Field evidence rarely favors a control this clearly. Place decoys beside real credentials in stores, variables, and configuration files, and route their alerts to a channel someone watches.

Scan Repositories, Logs, and Artifacts Continuously

Run secret scanning across commits, git history, build logs, and published artifacts, since cleanup commits delete nothing from history. Teams that track leaked credentials across public code and paste sites catch the exposures internal scanners never see. Pair scanning with push protection so a detected secret blocks the commit instead of documenting it.

Where CloudSEK Sees Pipeline Credentials Resurface

Rotation closes the internal loop while leaving one question open: whether rotation beat the attacker. Answers to that question live outside the pipeline, because stolen credentials resurface in stealer logs, dark web markets, paste sites, and public repositories. The LiteLLM incident made the point literally, with victims' own GitHub accounts hosting their stolen secrets in public repositories the attackers created.

CloudSEK XVigil monitors that external surface, detecting an organization's leaked credentials across dark web sources, code platforms, and underground markets, and turning rotation from an act of faith into a verifiable outcome. CloudSEK Threat Intelligence tracks the campaigns behind the leaks, including TeamPCP, so a surfaced credential arrives with attacker context attached. For the AI layer specifically, CloudSEK AIVigil monitors the AI attack surface where these credentials concentrate, including exposed AI infrastructure, MCP servers, and leaked AI provider keys.

XVigil complements pipeline hardening instead of replacing it. OIDC, scoping, and scanning shrink what leaks; external monitoring answers the question those controls leave open: what leaked anyway, and who holds it now.

Conclusion

CI/CD credential exposure turns one trusted build into a warehouse of cloud, code, registry, and production keys. The LiteLLM incident showed how short the fuse is: one un-revoked token became a poisoned release, a package window measured in minutes became an exposure set measured in hundreds of thousands of pipelines, and the FBI assesses the stolen credentials will outlive the malware that took them.

The working assumption that survives contact with real incidents is simple: treat any credential reachable from a compromised pipeline as already exposed, revoke before rotating, order the waves by blast radius, and monitor external sources for the ones that leaked anyway.