AI analysis
Gitea Actions decided whether a fork pull request workflow needed approval based on the user who triggered the event rather than the pull request author. When a maintainer performed ordinary triage, such as adding a label, the run was created without approval even though the workflow definition still came from the fork head. Where Actions is enabled and a matching runner is registered, an attacker who controls the fork can therefore execute fork-controlled workflow code on the base repository's runners without explicit approval, with access to whatever secrets and permissions those runners have. Gitea instances that enable Actions, register runners, and accept external fork pull requests are affected; no version range was specified. No public proof of concept is known and the issue is not in CISA KEV.
What to do: Until a vendor patch is installed, disable Gitea Actions or unregister runners on repositories that accept fork pull requests, and require explicit approval before any fork workflow can run. Review recent pull_request runs that started from maintainer triage actions such as labeling, and rotate secrets and credentials those runners could access. Apply the fixed Gitea release when it is published; no patched version range was included in the advisory data.
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.