The confused deputy, first described by Norm Hardy in 1988, is the oldest named authorization bug in computing. A privileged program is tricked into using its authority on behalf of an attacker who does not themselves hold that authority. In 2026 the shape of that bug has moved: the deputy is no longer a compiler that writes to a billing file, it is a CI/CD runner that holds a cloud OIDC token, and the attacker is no longer a fellow student sharing a timeshare. The attack surface is larger, the blast radius is wider, and the number of teams treating build systems as ordinary software has not kept pace.
This is a survey of how confused deputy attacks manifest in modern continuous integration and delivery systems, what the public incident record tells us about actual exploitation, and which defensive patterns work under realistic conditions.
What Makes a CI/CD System a Confused Deputy?
A CI/CD runner is by design a highly privileged process executing untrusted-ish code. It holds credentials to push container images to registries, assume cloud roles, read secrets from vaults, open pull requests, merge to protected branches with administrator override, and deploy to production. Its input is a pipeline definition, an artifact, or a commit, any of which can be shaped by a human of varying trust. This is the deputy. The confusion happens when the runner does not correctly distinguish between the principal who requested an action and the authority it holds to perform that action.
The classic modern example: a pull request from a fork triggers a workflow that prints an environment variable into logs. If the workflow holds a cloud credential, the fork author has just convinced the runner to exfiltrate a secret the fork author does not otherwise hold. This is confused deputy in its purest form.
Which Public Incidents Fit the Pattern?
The 2023 CircleCI breach is the textbook case. CircleCI disclosed on January 4, 2023 that a December 2022 compromise of an engineer's endpoint, via malware that bypassed 2FA using a session cookie, had resulted in the attacker accessing CircleCI's internal systems and exfiltrating customer secrets. Customers used CircleCI as their deputy for deployments; the attacker used CircleCI's privilege to read their secrets. Over 5,000 customer-stored secrets were potentially exposed. The incident kicked off industry-wide secret rotations and the accelerated adoption of OIDC-based short-lived credentials in place of long-lived static secrets.
The Codecov bash uploader supply chain attack, disclosed April 15, 2021, is another. Attackers modified the bash uploader script hosted by Codecov and used it to exfiltrate environment variables from CI pipelines that invoked it. Codecov's uploader was the deputy; customers' CI runners, which had pipeline-embedded credentials, were the secrets. Over 29,000 Codecov customers ran the modified script before the tampering was discovered.
GitHub's pull_request_target trigger, documented extensively in Legit Security's research and Trail of Bits' 2023 audit notes, has produced a long tail of confused-deputy-shaped incidents. The trigger runs workflows with the base repository's secrets against code from the head repository, which means a fork PR can influence workflow behavior while holding the privileges of the upstream repo. Specific CVEs and bug bounties tied to this pattern include the 2022 GitHub Actions-based leakage of secrets from popular public repositories documented by Adnan Khan in the "One Supply Chain Attack to Rule Them All" write-up, and the 2024 self-hosted runner takeovers catalogued by Praetorian.
Why Do OIDC Federations Not Solve This Alone?
OIDC federation from CI to cloud, popularized by GitHub Actions and AWS's trust policy support, replaces long-lived static secrets with short-lived tokens issued by the CI provider. On paper this removes the primary Codecov and CircleCI risk: there is nothing durable to exfiltrate. In practice OIDC federation has introduced a new class of confused-deputy bugs, centered on trust policy misconfiguration.
The canonical example is an AWS role whose trust policy allows any GitHub repository in the organization to assume the role because the condition only checks the token's audience and not the repository subject. An attacker who can run workflows in any public repository in that organization, including a repository they created an hour ago, can assume a role intended for the production deployment pipeline. Security researchers at Datadog, Palo Alto Networks' Unit 42, and Rezonate have each published 2024 and 2025 reviews showing that trust policy misconfigurations of this shape remain widespread, in some samples affecting 30-40% of surveyed AWS accounts using GitHub OIDC.
The deputy has changed from a credential store to a federated identity issuer, but the confused-deputy shape persists: the cloud account does not correctly distinguish the specific workflow's authority from the organization's collective authority.
How Do Self-Hosted Runners Amplify the Risk?
Self-hosted runners introduce a second category of confused-deputy risk: runner reuse. GitHub's default behavior on ephemeral self-hosted runners is correct, but a non-trivial number of organizations deploy long-lived runners that serve many workflows sequentially. A workflow that does not clean up after itself leaves behind environment state: cached credentials, SSH agents, registry logins, file-system artifacts, and in-memory daemons. The next workflow, potentially from a different, less-trusted branch or PR, inherits that state.
Trail of Bits' 2023 research on GitHub self-hosted runners, and Praetorian's 2024 follow-up, documented cases where public open-source projects exposed self-hosted runners to fork PRs, giving arbitrary pull-request authors the ability to execute on the runner and exfiltrate secrets belonging to maintainers. The same confused-deputy shape, with a runner taking pull-request code as input and holding maintainer authority as authority.
What Does Defense in Depth Actually Look Like?
Effective defense against CI/CD confused deputy attacks is a multi-layer stack. At the identity layer: OIDC federation with strict trust-policy subject claims, scoped to the repository, the workflow file name, and where possible the branch. Policy simulators from AWS IAM, GCP Security Command Center, and Azure PIM can test trust policies against hostile subject claims before deployment. At the workflow layer: separate privileged pipelines from pull-request-triggered pipelines, run fork PRs with read-only tokens, and never use pull_request_target to run untrusted code with elevated privileges. At the runner layer: ephemeral runners always, with one job per VM and no post-job persistence. At the artifact layer: signed builds with Sigstore or in-toto attestations so that downstream verifiers can detect if a production artifact came from an unauthorized pipeline path.
OpenSSF's SLSA framework, currently at version 1.0, codifies much of this into a graded model. SLSA Level 3 requires hardened build platforms with non-falsifiable provenance, which forecloses the dominant confused-deputy patterns. Fewer than 10% of surveyed open-source projects meet SLSA Level 3, per the OpenSSF Scorecard 2025 survey, but regulated enterprises increasingly require it for vendor software.
Which Guardrails Catch the Real-World Mistakes?
The mistakes that show up in real incidents are rarely the ones security training emphasizes. They are: overly permissive OIDC trust policies that permit any repo in the org, not just the production repo. Workflow files that reuse the same secret for both build and deploy steps. Third-party marketplace actions running with unrestricted permissions, pinned to a mutable tag rather than a commit SHA. Workflows that cat or echo environment variables in debugging steps and then ship that code to production. Self-hosted runners exposed to fork PRs. Secrets scoped at the repository level rather than the environment level, so that a low-trust workflow inherits production keys.
Detective controls that catch these in practice include static analysis of workflow files via tools like Octoscan, Legit Security's secrets-posture scanner, and GitGuardian's CI/CD posture module, combined with runtime detection of anomalous OIDC token exchanges in the cloud provider's audit log. The 2024 AWS re:Invent security track included multiple talks on detecting anomalous AssumeRoleWithWebIdentity calls, which is the specific primitive that OIDC federation uses.
How Safeguard.sh Helps
Confused deputy attacks on CI/CD are fundamentally about transitive trust. Your pipeline reaches upstream marketplace actions, upstream base images, upstream package registries, and downstream cloud identity providers. Any one of them can be the confused deputy. Safeguard.sh's reachability analysis maps the exact set of third-party actions, SDKs, and container layers your pipelines touch, going 100 levels deep into the dependency graph, so you see every confused-deputy candidate before an attacker does. Griffin AI prioritizes advisories affecting CI/CD components based on whether your specific workflows reach the vulnerable code path, not whether the library appears in a lockfile.
Eagle provides continuous scanning of your active workflows and runner fleets, flagging drift when a previously pinned action moves to a mutable tag, or when a self-hosted runner starts serving PR triggers it was never meant to serve. Our guardrails enforce policies like "no fork PR may assume a cloud role with write access to prod" as deploy-time checks, not as checklist items. Container self-healing replaces compromised runner images automatically on the next scheduled cycle. For teams whose CI/CD system is a deputy in every meaningful sense of the word, Safeguard.sh keeps it from getting confused.