Summary
A GitHub Actions workflow in the Salty documentation repository can execute attacker-controlled code from a fork pull request within a privileged base-repository workflow. If the workflow installs dependencies from the checked-out fork content, that code may access repository and deployment secrets and use write-capable tokens for further compromise.
A GitHub Actions workflow in the Salty documentation repository can execute attacker-controlled code from a fork pull request within a privileged base-repository workflow. If the workflow installs dependencies from the checked-out fork content, that code may access repository and deployment secrets and use write-capable tokens for further compromise.
Affected context
The issue occurs in documentation build workflows that process fork pull requests through a separate workflow_run job with access to sensitive credentials. Risk arises when an untrusted fork commit is selected for checkout and package installation runs against attacker-controlled project files before the workflow's secrets and token permissions have been sufficiently isolated.
The issue occurs in documentation build workflows that process fork pull requests through a separate workflow_run job with access to sensitive credentials. Risk arises when an untrusted fork commit is selected for checkout and package installation runs against attacker-controlled project files before the workflow's secrets and token permissions have been sufficiently isolated.
Exploit preconditions
- Attack surface: GitHub Actions workflows triggered by fork pull requests
- Required access: Ability to submit and control content in a fork pull request
- Trigger point: Dependency installation or build initialization in the privileged workflow
- Why exploitation is possible: Attacker-controlled repository metadata causes a fork commit to be checked out, allowing package installation logic and build hooks from that commit to execute with workflow privileges and exposed secrets
- Attack surface: GitHub Actions workflows triggered by fork pull requests
- Required access: Ability to submit and control content in a fork pull request
- Trigger point: Dependency installation or build initialization in the privileged workflow
- Why exploitation is possible: Attacker-controlled repository metadata causes a fork commit to be checked out, allowing package installation logic and build hooks from that commit to execute with workflow privileges and exposed secrets
Why this happens
The workflow crosses a trust boundary by combining untrusted fork content with a secret-bearing workflow_run execution context. Installing Python dependencies from the checked-out content can invoke attacker-controlled packaging code, such as build configuration or backend hooks, before the workflow has established that the code is trusted. This maps primarily to CWE-94: Improper Control of Generation of Code, with related concerns involving execution of untrusted functionality and unsafe CI/CD workflow design.
The workflow crosses a trust boundary by combining untrusted fork content with a secret-bearing workflow_run execution context. Installing Python dependencies from the checked-out content can invoke attacker-controlled packaging code, such as build configuration or backend hooks, before the workflow has established that the code is trusted. This maps primarily to CWE-94: Improper Control of Generation of Code, with related concerns involving execution of untrusted functionality and unsafe CI/CD workflow design.
Potential impact
- Attacker-controlled code could execute with the permissions of the workflow runner
- Deployment, repository, or third-party service secrets may be disclosed
- Write-capable tokens could enable repository or artifact tampering
- Documentation and supply-chain content could be poisoned
- Additional systems may be compromised through exposed credentials or workflow permissions
- Attacker-controlled code could execute with the permissions of the workflow runner
- Deployment, repository, or third-party service secrets may be disclosed
- Write-capable tokens could enable repository or artifact tampering
- Documentation and supply-chain content could be poisoned
- Additional systems may be compromised through exposed credentials or workflow permissions
General mitigation guidance
Mitigation generally focuses on maintaining a strict separation between untrusted pull-request content and privileged workflow contexts.
Common defensive patterns include:
- Avoiding execution or dependency installation from fork-controlled commits in secret-bearing jobs
- Using trusted, repository-controlled workflow inputs for privileged builds
- Separating untrusted validation jobs from release, deployment, and publication jobs
- Applying least-privilege permissions and withholding secrets from untrusted execution paths
- Pinning and reviewing dependencies while using isolated, disposable build environments
- Treating artifact metadata as untrusted and validating commit ownership and provenance before checkout
Mitigation generally focuses on maintaining a strict separation between untrusted pull-request content and privileged workflow contexts.
Common defensive patterns include:
- Avoiding execution or dependency installation from fork-controlled commits in secret-bearing jobs
- Using trusted, repository-controlled workflow inputs for privileged builds
- Separating untrusted validation jobs from release, deployment, and publication jobs
- Applying least-privilege permissions and withholding secrets from untrusted execution paths
- Pinning and reviewing dependencies while using isolated, disposable build environments
- Treating artifact metadata as untrusted and validating commit ownership and provenance before checkout
How teams detect issues like this
Organizations can identify similar risks through:
- Static analysis of workflows for
workflow_run, fork pull-request handling, checkout references, and secret exposure - Code review checks for dependency installation or build commands after checkout of untrusted revisions
- Policy enforcement that blocks secrets and write permissions in jobs processing fork content
- Detection rules for privileged workflows whose inputs or artifacts determine source revisions
- Audit-log monitoring for unusual token use, secret access, repository writes, or deployment activity from documentation jobs
Automated CI security scanners and workflow policy tools can help flag these trust-boundary violations during review.
Organizations can identify similar risks through:
- Static analysis of workflows for
workflow_run, fork pull-request handling, checkout references, and secret exposure - Code review checks for dependency installation or build commands after checkout of untrusted revisions
- Policy enforcement that blocks secrets and write permissions in jobs processing fork content
- Detection rules for privileged workflows whose inputs or artifacts determine source revisions
- Audit-log monitoring for unusual token use, secret access, repository writes, or deployment activity from documentation jobs
Automated CI security scanners and workflow policy tools can help flag these trust-boundary violations during review.
