CVE-2026-104632: Gitea fork workflow approval bypass through cancel and rerun
Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the bypass?
A user with Actions write access can cancel a fork pull request workflow run that is awaiting approval and then re-run it. The issue applies to first-time fork pull request contributors whose workflow jobs would normally be blocked pending maintainer approval.
What conditions are required for fork code to execute?
Actions must be enabled and a matching runner must be registered. The affected run must be a finished run that was awaiting approval, and the user must be able to cancel and re-run it.
What is the security impact of a successful bypass?
Workflow code from the fork pull request head can run on the repository's runners without explicit maintainer approval. This defeats the approval gate intended to prevent untrusted first-time fork contributor workflows from executing.
What can be done while a fix is not available?
Avoid cancelling and re-running workflow checks for first-time fork pull requests that are awaiting approval. Review completed or rerun fork pull request workflows for runs whose approval was still recorded as required but whose jobs were created in a waiting state.