Summary
Gitea's pull request review notifier can omit pull request context from Actions notifications, causing the fork workflow approval gate to misclassify fork-originated runs. Review events may then allow workflow code controlled by a fork to execute on base repository runners without the required maintainer approval.
Gitea's pull request review notifier can omit pull request context from Actions notifications, causing the fork workflow approval gate to misclassify fork-originated runs. Review events may then allow workflow code controlled by a fork to execute on base repository runners without the required maintainer approval.
Affected context
The issue affects Gitea repositories that use Actions workflows involving pull requests from forks and approval gates intended to protect base repository runners. It becomes risky when review comments or approval and rejection events are processed without preserving enough pull request context to identify the workflow as fork-controlled.
The issue affects Gitea repositories that use Actions workflows involving pull requests from forks and approval gates intended to protect base repository runners. It becomes risky when review comments or approval and rejection events are processed without preserving enough pull request context to identify the workflow as fork-controlled.
Exploit preconditions
- Attack surface: Pull request review notifications and Actions workflow approval handling
- Required access: Ability to create or control a fork pull request and cause relevant review events
- Trigger point: Processing of a review comment, approval, or rejection event
- Why exploitation is possible: The notifier does not attach the pull request to the Actions notification, so the approval gate may fail to recognize the fork origin and permit execution without the intended maintainer approval
- Attack surface: Pull request review notifications and Actions workflow approval handling
- Required access: Ability to create or control a fork pull request and cause relevant review events
- Trigger point: Processing of a review comment, approval, or rejection event
- Why exploitation is possible: The notifier does not attach the pull request to the Actions notification, so the approval gate may fail to recognize the fork origin and permit execution without the intended maintainer approval
Why this happens
The underlying flaw is an authorization-context failure. A security decision that should distinguish fork-originated workflows from base-repository workflows is made without reliably carrying the associated pull request metadata.
This maps to CWE-863: Incorrect Authorization, because the system can grant permission to execute workflow code without correctly evaluating the resource's origin and the approval requirement. The insecure pattern is treating an incomplete event context as sufficient evidence that a protected workflow run is authorized.
The underlying flaw is an authorization-context failure. A security decision that should distinguish fork-originated workflows from base-repository workflows is made without reliably carrying the associated pull request metadata.
This maps to CWE-863: Incorrect Authorization, because the system can grant permission to execute workflow code without correctly evaluating the resource's origin and the approval requirement. The insecure pattern is treating an incomplete event context as sufficient evidence that a protected workflow run is authorized.
Potential impact
- Fork-controlled workflow code may execute on base repository runners
- Repository secrets or other runner-accessible resources could be exposed
- Attackers could modify build, test, or release activities
- The repository environment may be used for unauthorized actions or lateral movement
- CI/CD integrity and software supply-chain trust could be weakened
- Fork-controlled workflow code may execute on base repository runners
- Repository secrets or other runner-accessible resources could be exposed
- Attackers could modify build, test, or release activities
- The repository environment may be used for unauthorized actions or lateral movement
- CI/CD integrity and software supply-chain trust could be weakened
General mitigation guidance
Mitigation generally focuses on preserving authorization context across event processing and enforcing approval decisions against the verified pull request origin.
Common defensive patterns include:
- Carrying immutable pull request and fork-origin metadata through notification and approval workflows
- Denying protected workflow execution when repository origin or approval state cannot be verified
- Applying explicit, fail-closed authorization checks before scheduling jobs on privileged runners
- Separating fork jobs from trusted repository jobs and limiting their access to secrets, tokens, and sensitive resources
- Running automation with least privilege and using isolated runners for untrusted contributions
- Treating review events as untrusted inputs rather than implicit authorization
Mitigation generally focuses on preserving authorization context across event processing and enforcing approval decisions against the verified pull request origin.
Common defensive patterns include:
- Carrying immutable pull request and fork-origin metadata through notification and approval workflows
- Denying protected workflow execution when repository origin or approval state cannot be verified
- Applying explicit, fail-closed authorization checks before scheduling jobs on privileged runners
- Separating fork jobs from trusted repository jobs and limiting their access to secrets, tokens, and sensitive resources
- Running automation with least privilege and using isolated runners for untrusted contributions
- Treating review events as untrusted inputs rather than implicit authorization
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static analysis and code review checks for authorization decisions made from incomplete event objects
- Review of notification schemas to confirm that pull request identity, source repository, and approval state are preserved
- Tests covering fork pull requests, review comments, approvals, rejections, and missing or malformed context
- Policy enforcement requiring fail-closed behavior when workflow provenance is ambiguous
- Runtime auditing that correlates workflow runs with their pull request origin, approval state, runner class, and accessed secrets
- Automated security review tools that flag trust-boundary crossings between fork-controlled code and privileged runners
Organizations can assess for this class of issue through:
- Static analysis and code review checks for authorization decisions made from incomplete event objects
- Review of notification schemas to confirm that pull request identity, source repository, and approval state are preserved
- Tests covering fork pull requests, review comments, approvals, rejections, and missing or malformed context
- Policy enforcement requiring fail-closed behavior when workflow provenance is ambiguous
- Runtime auditing that correlates workflow runs with their pull request origin, approval state, runner class, and accessed secrets
- Automated security review tools that flag trust-boundary crossings between fork-controlled code and privileged runners
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
