Gitea normally blocks workflow jobs in a forked repository until a first‑time contributor is approved. However, in some job transition and dispatch paths the approval check is omitted. By running a second job that shares the same job‑level concurrency group, an attacker can cancel a blocked job and cause its sibling to be re‑emitted without undergoing approval. This enables unreviewed forked workflow code to run on self‑hosted runners; fork secrets are not exposed but the run token remains read‑only.

The vulnerability is present in Gitea releases prior to the 1.27.3 security patch. All self‑hosted Gitea installations that allow fork workflow execution and use job‑level concurrency groups are affected until the bug is fixed in v1.27.3.

The CVSS score of 8.1 indicates high severity. The EPSS score of < 1% indicates a very low but non‑zero likelihood of exploitation, yet the risk remains high due to the straightforward execution path. This vulnerability falls under CWE‑284 (Least Privilege) because it bypasses the intended approval process. While KEV does not list this vulnerability and no public exploit is documented, the high CVSS and the straightforward execution path make it a significant risk for any environment that runs self‑hosted runners from forked repositories.