CircleCI fork PR config exposes every project secret to outsiders

TL;DR - If a CircleCI project has both Build forked pull requests and Pass secrets to builds from forked pull requests enabled, anyone who opens a fork PR can read every environment secret in that project. Turn off secret passing for fork PRs. Rotate anything that was reachable.

What happened

CircleCI runs pipeline configs on hosted runners - it's the CI/CD layer between your repo and your deploys. On May 2, 2026, CircleCI posted a security advisory flagging a supported but dangerous configuration pair.

The mechanics are simple and brutal. When Build forked pull requests is on, CircleCI runs the .circleci/config.yml from the fork. When Pass secrets to builds from forked pull requests is also on, every project environment variable is injected into that build. The attacker controls the config. They modify .circleci/config.yml to exfiltrate the secrets. Done.

This is the same failure mode behind several recent CI/CD supply-chain incidents: a low-trust trigger - an outsider's fork PR - gets access to high-value credentials like publish tokens and deploy keys. The blast radius depends entirely on what secrets are in scope.

Who is impacted

• CircleCI projects where both of these settings are enabled under Project Settings -> Advanced:
  • Build forked pull requests
  • Pass secrets to builds from forked pull requests
• Any secret injected into the job environment. CircleCI's advisory specifically calls out npm tokens, GitHub PATs, AWS access keys, GCP service account keys, signing keys, deploy tokens, and third-party API keys.
• Highest risk: projects where exposed secrets carry publish, deploy, or write scope - registry publish tokens, cloud deploy credentials, anything with an action attached.

What to do now

• Check every project: go to Project Settings -> Advanced and look at both fork PR settings.
• Turn off Pass secrets to builds from forked pull requests. Forks will still build - they just won't see your project's environment values. As CircleCI puts it:

  "This is the right setting for most projects."

• If you genuinely need secrets in fork PR builds, CircleCI's guidance is to replace long-lived tokens with short-lived credentials:

  "Replace long-lived tokens with OIDC-issued, short-lived credentials scoped to jobs in your repository, where the integration supports it." "Move remaining long-lived sensitive credentials into a restricted context."

• Rotate every secret that was reachable from untrusted fork PR builds - unconditionally:

  "There's no way to know retroactively whether a malicious PR has already extracted them."

• If you suspect active exposure, assume unauthorised reads have already happened. Audit downstream activity - npm publishes, deploys, commits - for anything anomalous. Contact CircleCI Support if you need help scoping the investigation.