Summary
A critical authorization flaw in Gitea Actions could allow fork-controlled workflow code to run on base-repository runners without explicit approval. The approval decision used the user who triggered a pull request event instead of the pull request author, so routine maintainer actions could bypass the intended fork-workflow review boundary.
A critical authorization flaw in Gitea Actions could allow fork-controlled workflow code to run on base-repository runners without explicit approval. The approval decision used the user who triggered a pull request event instead of the pull request author, so routine maintainer actions could bypass the intended fork-workflow review boundary.
Affected context
The issue occurs in Gitea deployments where Actions is enabled, a matching runner is registered, and fork pull request workflows are subject to approval controls. During certain pull_request activities initiated by a maintainer, the workflow definition may still come from the fork while the approval decision is based on the event triggerer's identity rather than the pull request author's trust context.
The issue occurs in Gitea deployments where Actions is enabled, a matching runner is registered, and fork pull request workflows are subject to approval controls. During certain pull_request activities initiated by a maintainer, the workflow definition may still come from the fork while the approval decision is based on the event triggerer's identity rather than the pull request author's trust context.
Exploit preconditions
- Attack surface: Gitea Actions pull request event processing
- Required access: Ability to contribute a pull request from a fork; successful execution also requires Actions to be enabled and a compatible runner to be available
- Trigger point: A qualifying
pull_requestactivity initiated by a trusted repository user - Why exploitation is possible: Approval logic evaluates the event actor instead of the source pull request author, allowing fork-controlled workflow code to reach a base repository runner without the intended approval
- Attack surface: Gitea Actions pull request event processing
- Required access: Ability to contribute a pull request from a fork; successful execution also requires Actions to be enabled and a compatible runner to be available
- Trigger point: A qualifying
pull_requestactivity initiated by a trusted repository user - Why exploitation is possible: Approval logic evaluates the event actor instead of the source pull request author, allowing fork-controlled workflow code to reach a base repository runner without the intended approval
Why this happens
The authorization decision is derived from the identity that triggered a pull request event rather than from the less-trusted author and source of the workflow being executed. This confused-deputy-style trust-boundary error maps primarily to CWE-863: Incorrect Authorization and is also related to CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'). The insecure pattern is granting execution trust based on an event actor while processing code supplied by another, potentially untrusted repository.
The authorization decision is derived from the identity that triggered a pull request event rather than from the less-trusted author and source of the workflow being executed. This confused-deputy-style trust-boundary error maps primarily to CWE-863: Incorrect Authorization and is also related to CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'). The insecure pattern is granting execution trust based on an event actor while processing code supplied by another, potentially untrusted repository.
Potential impact
- Fork-controlled workflow code could execute on base repository runners
- Repository secrets or tokens available to the runner may be exposed
- Builds, artifacts, or source data could be modified or poisoned
- The runner environment could be compromised
- Downstream systems may be affected if the runner has excessive permissions
- Fork-controlled workflow code could execute on base repository runners
- Repository secrets or tokens available to the runner may be exposed
- Builds, artifacts, or source data could be modified or poisoned
- The runner environment could be compromised
- Downstream systems may be affected if the runner has excessive permissions
General mitigation guidance
Mitigation generally focuses on preserving the trust boundary between fork-supplied workflow definitions and privileged repository runners.
Common defensive patterns include:
- Deriving approval decisions from the pull request author, source repository, and workflow provenance rather than only the event actor
- Requiring explicit approval for workflows originating from untrusted forks
- Separating fork workloads onto isolated, least-privilege runners
- Limiting runner credentials, repository access, and network permissions
- Avoiding exposure of sensitive secrets to unapproved or fork-controlled jobs
- Applying secure-by-default policies for pull request workflow execution
Mitigation generally focuses on preserving the trust boundary between fork-supplied workflow definitions and privileged repository runners.
Common defensive patterns include:
- Deriving approval decisions from the pull request author, source repository, and workflow provenance rather than only the event actor
- Requiring explicit approval for workflows originating from untrusted forks
- Separating fork workloads onto isolated, least-privilege runners
- Limiting runner credentials, repository access, and network permissions
- Avoiding exposure of sensitive secrets to unapproved or fork-controlled jobs
- Applying secure-by-default policies for pull request workflow execution
How teams detect issues like this
Organizations can assess this risk through:
- Code review of authorization decisions for pull request and fork events
- Static analysis and policy checks that compare event actor identity with pull request author and source repository
- Tests covering maintainer-triggered activity on fork pull requests
- Audit logging for approval bypasses and workflow executions sourced from forks
- CI policies that prevent unapproved fork workflows from using privileged runners or secrets
Automated security review tools may help identify trust-boundary mismatches, but deployment-specific authorization tests remain important.
Organizations can assess this risk through:
- Code review of authorization decisions for pull request and fork events
- Static analysis and policy checks that compare event actor identity with pull request author and source repository
- Tests covering maintainer-triggered activity on fork pull requests
- Audit logging for approval bypasses and workflow executions sourced from forks
- CI policies that prevent unapproved fork workflows from using privileged runners or secrets
Automated security review tools may help identify trust-boundary mismatches, but deployment-specific authorization tests remain important.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
