AI analysis
Gitea Actions is meant to block workflow jobs from first-time fork pull-request contributors until a maintainer explicitly approves the run. The rerun path only checked that a run had finished and created the new attempt's jobs as waiting, ignoring that approval was still required, so cancelling a pending-approval run and re-running it started fork workflow code on the repository's runners. A user with Actions write access can trigger this with a routine cancel-and-rerun, and the first-time contributor's workflow from the fork head then runs without that approval. Impact is remote code execution on registered runners, with high risk to secrets and repository integrity, wherever Actions is enabled and a matching runner exists. There is no known public proof-of-concept and no confirmed in-the-wild exploitation.
What to do: Upgrade Gitea to a vendor-patched release as soon as one is published; the advisory data does not name a fixed version. Until then, do not cancel and re-run workflow runs that are still awaiting first-time fork-PR approval, and treat any such rerun as untrusted. Restrict runner privileges and secrets, and review recent reruns of blocked fork workflows for jobs that executed without an explicit approval.
Affected
| Gitea (Actions) | Versions implementing first-time fork pull-request workflow approval; no fixed or affected version range is stated in the advisory data |
Estimated exposure
moderatethousands to low tens of thousands of Actions-enabled Gitea instances (estimate) — Gitea is a widely used self-hosted Git service, and public scans have historically observed on the order of tens of thousands of internet-facing instances, but only deployments with Actions enabled, a matching runner, and untrusted fork…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.