Gitea Actions EUVD-2026-93919

Requires all of: Gitea Actions enabled on the base repository, a matching Actions runner registered for it, an attacker-submitted pull request from a fork whose head contains the malicious workflow, and a repository maintainer who triggers a pull_request activity (such as adding a label) during routine triage. The approval check is keyed to the triggering maintainer instead of the fork author, so maintainer triage inadvertently releases the fork-controlled run. Limiting factors: exploitation cannot proceed without that privileged maintainer action, Actions and a runner must be configured (non-default for many deployments), and only Gitea versions ≤1.27.3 are affected (fixed in 28.0.0).

Signals conflict sharply. The supplied CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) frames this as trivially remote and unauthenticated, but the description makes clear exploitation hinges on a repository maintainer performing a triage action (e.g. adding a label) on an attacker's fork PR, plus Actions being enabled and a runner registered - so PR:N/UI:N overstates reachability. The lower-urgency signals are more consistent with reality: EPSS is 0.15% (3rd percentile), CISA SSVC records Exploitation=none, there is no CISA KEV listing, and no public exploit is identified at time of analysis. Offsetting that, SSVC rates Automatable=yes and Technical Impact=total, and the outcome - fork-controlled workflow code running on the base repository's runners - is genuinely severe, exposing CI secrets and enabling pipeline compromise. Net: this is a real, high-impact confused-deputy flaw that should be patched promptly on Internet-exposed Gitea instances that use Actions, but it is not a drop-everything mass-exploitation event; the maintainer-interaction and configuration preconditions make it opportunistic/targeted rather than widely wormable, and the headline 9.8 should be treated as inflated relative to the actual preconditions.

An attacker opens a pull request from a fork that embeds a malicious workflow in the fork head. When a maintainer performs ordinary triage such as adding a label, Gitea evaluates the approval requirement against the maintainer rather than the fork author, so the fork-controlled workflow runs on the base repository's registered runners without approval and executes attacker code with access to runner secrets. No public exploit is identified at time of analysis.