This vulnerability allows a contributor to inject custom workflow files into a forked pull request that targets a repository with Actions enabled. The workflow is submitted under a shared run‑level concurrency group, causing the run to be queued waiting for approval. If a later run in the same group cancels the queued job, the run remains in a terminal state yet still marked as pending approval. When a repository maintainer subsequently approves the run, Gitea re‑enqueues the cancelled job, places it back into the waiting state, and permits any runner that accepts jobs from the repository to claim and execute it. The forked workflow code is thereby executed on the runner with the permissions granted to that runner, giving an attacker the ability to run arbitrary code on the infrastructure that hosts the runner. The flaw is rooted in improper management of concurrency groups (CWE‑841) and results in a high‑impact remote code execution risk.

The flaw exists in Gitea repositories that host Actions, with the earliest affected releases being indicated in the advisory as versions preceding 28.0.0. The release notes for v28.0.0 contain the fix, so any Gitea project running a version older than 28.0.0 is vulnerable. The impact is limited to repositories where the attacker can open a fork pull request and where the repository maintainer later approves that pull request. The runner must be configured to accept jobs from the repository, which is a common configuration in open source projects.

The CVSS score is 8.8, indicating a high severity. The EPSS score is 0.00156 (0.156%), indicating a very low but nonzero exploitation probability, and the vulnerability is not listed in CISA KEV. Despite the lack of publicly available exploitation metrics, the description implies a serious flaw: the attacker can gain code execution by leveraging a legitimate maintainer action. The technical requirements—an enabled Actions workflow, a shared concurrency group, and a runner that accepts jobs from the repository—are typical in many open source projects. Because the attack requires the maintainer’s approval, the exploitability is conditional, but the potential damage from executing rogue workflow code on a runner is substantial. Overall, the risk remains high due to the remote code execution potential, even without quantified detection rates.