Summary
Gitea may resolve a local reusable workflow from a fork's head commit when a trusted base-branch workflow handles a pull_request_target event. A fork author could use this behavior to run attacker-controlled workflow code with repository or organization secrets available to that event.
Gitea may resolve a local reusable workflow from a fork's head commit when a trusted base-branch workflow handles a pull_request_target event. A fork author could use this behavior to run attacker-controlled workflow code with repository or organization secrets available to that event.
Affected context
The issue occurs in Gitea-based CI workflows when a pull_request_target workflow invokes a reusable workflow stored in the repository. It becomes risky when the reusable workflow is resolved from the fork's head commit rather than trusted base-branch content, allowing untrusted fork changes to cross the intended workflow trust boundary.
The issue occurs in Gitea-based CI workflows when a pull_request_target workflow invokes a reusable workflow stored in the repository. It becomes risky when the reusable workflow is resolved from the fork's head commit rather than trusted base-branch content, allowing untrusted fork changes to cross the intended workflow trust boundary.
Exploit preconditions
- Attack surface: Pull request automation using the
pull_request_targetevent - Required access: Ability to submit or modify a fork-based pull request
- Trigger point: Execution of a trusted workflow that references a local reusable workflow
- Why exploitation is possible: Gitea may load the reusable workflow from the fork's head commit, allowing untrusted workflow definitions to execute in a privileged event context
- Attack surface: Pull request automation using the
pull_request_targetevent - Required access: Ability to submit or modify a fork-based pull request
- Trigger point: Execution of a trusted workflow that references a local reusable workflow
- Why exploitation is possible: Gitea may load the reusable workflow from the fork's head commit, allowing untrusted workflow definitions to execute in a privileged event context
Why this happens
The underlying flaw is an unsafe trust-boundary decision during reusable workflow resolution. Instead of consistently selecting workflow content from the trusted base branch, the system may use content controlled by the fork author.
This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced workflow content is treated as executable automation logic. It also relates to CWE-829: Inclusion of Functionality from Untrusted Control Sphere, since a trusted workflow incorporates functionality from an untrusted fork context.
The underlying flaw is an unsafe trust-boundary decision during reusable workflow resolution. Instead of consistently selecting workflow content from the trusted base branch, the system may use content controlled by the fork author.
This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced workflow content is treated as executable automation logic. It also relates to CWE-829: Inclusion of Functionality from Untrusted Control Sphere, since a trusted workflow incorporates functionality from an untrusted fork context.
Potential impact
- Attacker-controlled code execution in CI runners
- Exposure of repository, environment, or organization secrets
- Modification of build artifacts or release outputs
- Repository content tampering or data exfiltration
- Potential lateral movement through permissions granted to the workflow
- Attacker-controlled code execution in CI runners
- Exposure of repository, environment, or organization secrets
- Modification of build artifacts or release outputs
- Repository content tampering or data exfiltration
- Potential lateral movement through permissions granted to the workflow
General mitigation guidance
Mitigation generally focuses on preserving a strict separation between trusted base-branch automation and untrusted fork content.
Common defensive patterns include:
- Resolve reusable workflows from explicitly trusted, immutable references
- Avoid granting secrets or elevated permissions to workflows that process fork-controlled content
- Use least-privilege workflow tokens and runner identities
- Separate validation jobs from privileged deployment or release jobs
- Require explicit review and policy checks for changes to workflow definitions
- Treat local reusable workflows invoked by privileged pull request events as trusted code
Mitigation generally focuses on preserving a strict separation between trusted base-branch automation and untrusted fork content.
Common defensive patterns include:
- Resolve reusable workflows from explicitly trusted, immutable references
- Avoid granting secrets or elevated permissions to workflows that process fork-controlled content
- Use least-privilege workflow tokens and runner identities
- Separate validation jobs from privileged deployment or release jobs
- Require explicit review and policy checks for changes to workflow definitions
- Treat local reusable workflows invoked by privileged pull request events as trusted code
How teams detect issues like this
Detection approaches commonly include:
- Static analysis for
pull_request_targetworkflows that invoke local reusable workflows - Policy checks identifying reusable workflow references resolved from pull request or fork content
- Code review rules for workflow changes that alter secret access, permissions, or runner selection
- Audit logging for unexpected workflow revisions, secret access, and privileged runner activity
- Automated CI policy tools that enforce trusted references and restricted permissions
Detection approaches commonly include:
- Static analysis for
pull_request_targetworkflows that invoke local reusable workflows - Policy checks identifying reusable workflow references resolved from pull request or fork content
- Code review rules for workflow changes that alter secret access, permissions, or runner selection
- Audit logging for unexpected workflow revisions, secret access, and privileged runner activity
- Automated CI policy tools that enforce trusted references and restricted permissions
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
