Gitea Actions EUVD-2026-93907

Requires all of: Gitea Actions enabled on the repository; a runner configured to accept that repository's jobs; the attacker able to open a fork pull request (so a low-privileged external account on an instance permitting fork contributions); a workflow that defines a shared run-level concurrency group so the fork run lands in an approval-gated, blocked state; and a second (sibling) run in the same concurrency group that cancels the blocked job, driving the run terminal while it is still marked as needing approval. The decisive limiting factor is that a maintainer with Actions write permission must subsequently approve the run - exploitation cannot complete without that human approval action - which, combined with the need to orchestrate the concurrency-group race and have an available accepting runner, substantially narrows realistic exploitation beyond what the raw 8.8 score implies.

Signals point in different directions. CVSS is 8.8 (AV:N/AC:L/PR:L/UI:N/S:U with C:H/I:H/A:H), which on its face suggests an easily exploitable network RCE, but every other source tempers that: EPSS is only 0.16% (4th percentile), CISA SSVC rates Exploitation as 'none' and Automatable as 'no' (while Technical Impact is 'total'), the CVE is not in CISA KEV, and no public exploit was identified at time of analysis. The description also conflicts with the published vector on two points: it states exploitation requires the maintainer's later approval action, yet the vector encodes UI:N (no user interaction); and the attack depends on orchestrating a concurrency-group race (a sibling run cancelling the blocked job) rather than a single low-complexity request, which argues for higher attack complexity than AC:L - verify these with the vendor advisory. Taken together this is a genuine but conditional RCE, not a drive-by: the total-impact code execution on a runner makes it worth patching, but the low EPSS, 'none' exploitation status, absence of KEV/POC, and the dependency on a privileged maintainer approval place it as an important-but-not-emergency fix, most relevant to instances that enable Actions, accept fork pull requests, and use approval gating.

On a Gitea instance with Actions enabled and fork PRs allowed, an attacker opens a fork pull request containing a workflow that shares a run-level concurrency group, producing a run gated behind maintainer approval. The attacker triggers a later run in the same concurrency group so it cancels the still-blocked job, leaving the run terminal yet marked as needing approval; when a maintainer later clicks approve, the already-cancelled fork job is pushed back through concurrency preparation, set to waiting, and picked up by a matching runner, executing attacker-controlled code. No public exploit code was identified at time of analysis, and the chain requires low attacker privileges (the ability to open a fork PR) plus the maintainer's approval action.