GitHub Actions OIDC Token Compromised: Detection, Scope Assessment, and Rotation Playbook

GitHub Actions OIDC works by having GitHub issue a short-lived JWT that your workflow can exchange with a cloud provider for cloud credentials. The attack pattern observed in the TanStack incident exploited the pull_request_target trigger: a workflow that runs in the context of the base repository (with access to secrets and OIDC token issuance) can be triggered by a pull request from a fork. If that workflow checks out and executes code from the fork, the fork's code runs with the base repository's permissions.

A second vector is direct memory scraping on the Actions runner. The payload that hit TanStack read /proc/{PID}/mem on the Linux runner to extract the OIDC token from the node runtime's memory while the workflow was executing. This requires code execution on the runner, achieved by injecting a malicious dependency that the workflow installs as part of its normal operation.

A third vector is GitHub Actions cache poisoning: a malicious actor poisons the Actions cache with a modified dependency that executes on cache restore, before the OIDC token exchange has occurred.

Check your GitHub audit log immediately. Navigate to your organization's Settings > Audit log and filter for these events:

• workflow_run.completed for any workflow using the id-token permission in the last 30 days
• pull_request_target triggers from external contributors
• package.published events, especially rapid sequential publishes (the TanStack attack published 84 versions in 6 minutes)

For the OIDC-specific check, pull your workflow files and look for jobs with:

permissions:
  id-token: write

Any workflow with this permission can request an OIDC token. Review every such workflow for the past 30 days of run history.

Also check your cloud provider. In AWS, look for AssumeRoleWithWebIdentity calls in CloudTrail with the principalId pattern matching your GitHub Actions OIDC provider (token.actions.githubusercontent.com). Filter for calls that occurred outside your normal deployment windows.

An OIDC token grants exactly what your IAM trust policy allows. Retrieve the trust policy for every IAM role your workflows can assume:

aws iam get-role --role-name YourDeployRole --query 'Role.AssumeRolePolicyDocument'

For each role, check whether the trust policy uses condition keys to restrict which repositories and branches can assume it. A correctly scoped trust policy looks like:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub": "repo:yourorg/yourrepo:ref:refs/heads/main"
  }
}

A dangerously broad trust policy might only check the repository, not the ref, allowing any branch or pull request to assume the role. If your policies are not ref-scoped, assume every AWS action the role permits was potentially available to the attacker.

Document the full set of AWS permissions attached to each assumable role. This is the blast radius of a successful OIDC token theft.

Rotate in order of blast radius, not alphabetical order of service.

npm publish tokens first, if the attacker published packages, every downstream consumer is at risk. Revoke your npm automation token immediately (npmjs.com > Access Tokens), generate a new one, update it in GitHub Secrets.

AWS credentials second, revoke any long-lived IAM access keys that the compromised role could have generated. If the role had iam:CreateAccessKey permission, the attacker may have created persistent credentials. Check for unexpected access keys: aws iam list-access-keys for every IAM user, and check CloudTrail for CreateAccessKey events.

Container registry third, if workflows push to ECR, GHCR, or Docker Hub, rotate those credentials and audit recent image pushes for unexpected layers.

GitHub deploy keys and PATs last, audit every token with repo write access in your organization. Any token stored as a GitHub Secret in an affected repository should be considered potentially exposed.

Three controls close the most common attack paths:

Pin all third-party Actions to commit SHA, not a tag. Tags are mutable, a compromised action maintainer can point a tag at malicious code. Pinning to a full commit SHA ensures you run exactly the code you audited:

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

Add StepSecurity Harden-Runner to every job. This GitHub Action monitors runner activity in real time, blocks outbound network requests to unexpected destinations, and detects file system writes to sensitive paths. It would have caught the /proc/mem scraping in the TanStack attack.

Restrict OIDC token claims at the provider. In AWS, update your IAM trust policy conditions to require both repo and ref match. In addition, use the sub claim format that includes environment when possible (repo:org/repo:environment:production) to prevent development branches from assuming production roles.

Set up automated monitoring for these GitHub audit log events using the GitHub Audit Log Streaming feature (available on Enterprise) or the audit log API:

• Unusual package publish frequency: more than 3 publishes in 60 seconds from a workflow
• pull_request_target workflow runs triggered by first-time contributors
• Workflow runs that request id-token permissions from non-default branches
• Secret access events (secret.access) outside normal deployment windows

Pair this with CloudTrail alerts in AWS for AssumeRoleWithWebIdentity calls from your OIDC provider at unusual times or from workflows you did not expect.