Exploiting OIDC Identity Federation in CI/CD Pipelines

TLDR: OpenID Connect (OIDC) identity federation is increasingly used to replace long-lived cloud credentials in CI/CD pipelines, but misconfigured trust policies often allow attackers to forge tokens. By exploiting lax sub claim patterns or wildcard-based trust, researchers can impersonate legitimate CI/CD identities to gain unauthorized access to cloud environments. Security teams must audit their OIDC trust relationships and enforce strict, non-wildcard policies to prevent identity impersonation.

Modern CI/CD pipelines are moving away from static, long-lived cloud credentials. The industry standard is shifting toward OIDC-based identity federation, where the CI/CD provider acts as an identity provider (IdP) and issues short-lived tokens to runners. This is a massive win for security, provided it is implemented correctly. However, the research presented at DEF CON 2024 by Aviad Hahami reveals that the implementation layer is riddled with configuration pitfalls that turn this security feature into an open door for attackers.

The Mechanics of the OIDC Trust Relationship

In a standard OIDC setup for CI/CD, the cloud provider (like AWS or GCP) trusts the CI/CD provider (like GitHub Actions or CircleCI) to assert the identity of a running job. The cloud provider validates the incoming OIDC token’s signature and then evaluates a set of conditions against the token’s claims. These claims, such as sub (subject), repository, or workflow, define the scope of the identity.

The vulnerability arises when the trust policy on the cloud side is too permissive. If a policy uses wildcards or fails to validate specific, non-spoofable claims, an attacker can manipulate the CI/CD environment to generate a token that satisfies the cloud provider’s trust conditions. This is essentially an identity impersonation attack. If you can trigger a pipeline in a target organization, you can often force that pipeline to generate a token that grants you the permissions associated with that organization’s cloud role.

Exploiting Lax Policy Patterns

The most common misconfiguration involves the sub claim. Many developers, when setting up OIDC, use broad patterns to avoid maintenance overhead. For example, a trust policy might look like this:

"StringLike": {
  "token.actions.githubusercontent.com:sub": "repo:my-org/*"
}

This policy trusts any repository within my-org. If an attacker can fork a repository within that organization or find a way to influence the sub claim, they can bypass the intended restrictions. The research highlights that the order of claims is critical when using custom formats. If the trust policy expects repo:org/repo:ref:refs/heads/main but the IdP allows re-formatting, an attacker can manipulate the input to match the expected structure, effectively tricking the cloud provider into granting access.

A particularly dangerous scenario occurs when the CI/CD vendor allows custom claim formats. Some IdPs permit the inclusion of arbitrary data in the sub claim. If the cloud-side policy is not strictly defined, an attacker can inject values that match the expected trust criteria. This is not a bug in the OIDC protocol itself, but a failure in how vendors and users implement the OWASP A01:2021-Broken Access Control principles within their identity federation logic.

Real-World Impact and Testing

During a penetration test, your goal is to identify where OIDC is used and how the trust policies are defined. If you have access to the CI/CD configuration, look for the permissions block. If id-token: write is enabled, the pipeline can request OIDC tokens. Your next step is to examine the cloud-side trust policy. If you see wildcards or broad StringLike conditions, you have a potential path to exploitation.

The attack flow is straightforward:

1. Identify a target pipeline that uses OIDC.
2. Fork the repository or create a pull request if the pipeline configuration allows it.
3. Inject a malicious workflow that prints the OIDC token or uses it to authenticate against the cloud provider.
4. If the trust policy is lax, the cloud provider will accept your forged token, granting you the permissions of the original, legitimate pipeline.

This technique is highly effective because it often bypasses traditional perimeter defenses. You are not breaking into the cloud; you are being invited in by the cloud provider itself because your token is cryptographically valid.

Defensive Hardening

Defending against this requires a shift in how we define trust. First, stop using wildcards in your OIDC trust policies. Every condition should be as specific as possible. If you are using GitHub Actions, ensure your policies are scoped to specific repositories and branches. You can use the github-oidc-utils tool to audit your existing configurations and identify risky claims.

Furthermore, treat your OIDC trust policies as code. They should undergo the same rigorous review process as your application code. If a policy change allows a broader set of identities to assume a role, it should be flagged immediately. The goal is to ensure that the identity being asserted is exactly what you expect, with no room for ambiguity.

Identity federation is the future of cloud security, but it is not a silver bullet. As we move away from static secrets, we must become experts in the nuances of OIDC claims and trust policies. If you are not auditing your OIDC trust relationships today, you are likely leaving the door open for an attacker to walk right through.