When forked pull requests can reach sensitive workflow variables, a low privilege external contributor can use the build process to exfiltrate secrets from the repository environment. That turns a collaboration feature into a credential theft path. Security teams should treat this as a configuration risk and disable secret exposure to forks unless there is a clear, reviewed business need.
How forked pull requests turn CI secrets into an exposure path
Forked pull requests are meant to let external contributors collaborate without inheriting full repository trust. The break happens when a workflow exposes sensitive variables, because the build job can then read, print, or forward material that should have stayed inside the trusted repo boundary. That is not just a convenience problem, it is a secret-handling failure.
In practice, the dangerous point is not the fork itself, but the workflow context. If the job runs with repository secrets, cached credentials, or tokened integrations available to untrusted code, the pull request can become a delivery mechanism for exfiltration. The control question is whether the workflow ever gives an unreviewed fork access to anything that can authenticate elsewhere.
This is why CI secret exposure to forks is usually treated as a configuration issue first and a code review issue second. A contributor does not need elevated repository rights if the pipeline assembles those rights on their behalf. Once the secret is available in the job environment, the attacker only needs a way to cause it to be emitted, copied, or reused.
What makes the exposure especially dangerous in CI/CD
CI systems combine automation, build-time trust, and broad integration surface area, which makes secret leakage easier to operationalise than in a normal application request path. A single workflow may touch source, dependency managers, package registries, cloud APIs, deployment targets, or signing systems, so one leaked credential can create more blast radius than the original repository permission implies.
The main failure mode is overtrusting the pull request context. Teams often assume that because code is still “under review”, the workflow is safe to run with secrets. In reality, the runner is executing untrusted input, and any secret reachable in that environment should be treated as already exposed to the contributor unless the job is explicitly hardened.
That is also why short-lived, narrowly scoped credentials matter. If a secret is long-lived or broadly reusable, leakage from a forked pull request can outlive the review window and be replayed elsewhere. The Secret Sprawl Challenge and Secrets Management Guide both reinforce the operational point: reduce how often secrets exist in workflow context at all, and prefer secretless or tightly bounded access where possible.
What teams should do when forks need to participate
If external contributors must be able to trigger CI, treat secret access as an exception, not a default. The safest pattern is to split untrusted validation from trusted deployment, so forked code can run tests without ever seeing production secrets. When a workflow truly needs privileged access, move the privileged step behind a reviewed gate or a separate trusted workflow that is not executed directly from the fork.
OWASP Non-Human Identity Top 10 is relevant here because CI credentials are identity-bearing material, not just configuration values. The practical issue is controlling what the pipeline identity can do, how long its credentials live, and whether the workflow context can exercise those credentials in an untrusted branch build.
Good practice is to scope every CI credential to the minimum repository, environment, and action required, then rotate it aggressively if fork access was ever possible. For teams using token-based integrations, limit write permissions, prefer short-lived tokens, and make secret exposure a revocation event rather than a later hygiene task. OWASP Cheat Sheet Series is useful as a companion reference for session, authentication, and secret-handling discipline in implementation.
Risk and Threat Considerations
Forked pull requests create a low-friction path from external code contribution to credential theft when workflow secrets are reachable. The security problem is not theoretical access, but the attacker’s ability to use normal build behaviour, logs, environment inspection, or chained actions to capture material that should have stayed confined to the trusted repository environment.
Failure mechanism: A workflow exposes sensitive variables or tokens to an untrusted fork, and the forked code, or something it invokes, reads and exfiltrates those values before review can stop it.
Impact: Leaked CI secrets can enable repository takeover, registry abuse, cloud access, signing abuse, or lateral movement into connected systems, so the blast radius often extends far beyond the pull request itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Forked PRs can expose workflow secrets to untrusted code. |
| NHI-07 — Long-Lived Secrets | Long-lived CI secrets widen the impact of fork-based leakage. | |
| NHI-05 — Overprivileged NHI | CI credentials often grant more access than fork jobs need. | |
| Recommendation — Prevent secret exposure in untrusted fork workflows and rotate any exposed credentials. Replace long-lived CI secrets with short-lived or dynamically issued credentials. Scope CI identities to the minimum permissions needed for each workflow step. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI secrets and tokens need lifecycle control, rotation and revocation. |
| AC-6 — Least Privilege | Forked jobs should not inherit unnecessary workflow access. | |
| AU-9 — Protection of Audit Information | Secrets often leak through logs or artifacts in CI pipelines. | |
| Recommendation — Manage CI credentials with strict issuance, rotation, and revocation rules. Limit fork-executed jobs to the minimum access required for validation. Protect logs and artifacts so secrets cannot be disclosed through build output. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Leaked CI tokens can be replayed as authentication material elsewhere. |
| API5 — Broken Function Level Authorization | A leaked CI token may grant actions beyond its intended workflow scope. | |
| Recommendation — Harden token handling so exposed CI credentials cannot be reused against APIs. Restrict token capabilities to the exact functions the pipeline must perform. | ||
Practitioner Guidance
What to verify: Check whether forked pull requests inherit any environment variables, deployment tokens, cloud credentials, package keys, or signing secrets. If they do, confirm exactly which jobs can read them and whether those jobs can be triggered by untrusted code.
Decision rule: If a workflow secret can authenticate to anything outside the build job, do not expose it to forks by default. Allow access only when the business case is reviewed, the privilege is tightly scoped, and the workflow cannot leak the secret through logs, artifacts, or reusable actions.
What good looks like: Forks can validate code, but only trusted, bounded workflows can touch secrets. Trusted steps use the smallest viable credential surface, and any secret that was exposed to an untrusted context is rotated immediately.
Practitioner takeaway: The right mental model is that a forked pull request is untrusted execution, not a safer version of the same repository access. If secrets are reachable there, assume they are reachable by the contributor unless proven otherwise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
