A flaw in Gitea Actions caused the approval requirement for a forked pull request workflow run to be based on the user who triggered the event rather than the pull request author. When a maintainer performed ordinary triage actions such as adding a label, a run was created without requiring approval, but the workflow definition was still taken from the fork head. If Actions is enabled and a matching runner is registered, the fork-controlled workflow code could execute on the base repository's runners without explicit approval, allowing unauthorized code to run with the runner's permissions.

The vulnerability affects installations of Gitea, with the precise version range not explicitly enumerated in the advisory. It is likely present in releases prior to the 28.0.0 release, which is referenced as a point of remediation.

The exploit requires Gitea Actions to be enabled and a runner of the appropriate type to be registered. Because the EPSS score is less than 1% and the issue is not listed in the CISA KEV catalog, the current quantitative risk metrics are limited, although the CVSS score of 9.8 indicates a critical severity. However, the nature of the flaw permits execution of arbitrary forked workflow code on the base repository's runners, representing a high‑severity scenario in the absence of an explicit approval gate.