CVE-2026-94205

Think of your code repository's automation system like a mailroom that runs any package instructions attached to incoming mail — but only after a supervisor signs off. This flaw means that if a staff member does something unrelated, like stamping a label on an incoming package, the system mistakenly treats that as the supervisor's sign-off and runs the attacker's instructions anyway, directly on your office's own equipment.

This matters to you if you self-host Gitea and have the built-in Actions (CI/automation) feature turned on with a runner registered, especially for repositories that accept pull requests from outside contributors or forks. It does not require the attacker to have any account or credentials — they only need to submit a pull request from a fork, and the trigger happens when any maintainer does normal triage like labeling it.

This is a critical, easy-to-trigger flaw: no authentication or special access is needed, and it can be set off by a maintainer's completely ordinary action like adding a label to a pull request. While no confirmed real-world attacks or public exploit code have been reported yet, the low effort required and full server compromise potential mean you should patch now rather than wait for signs of active abuse.

Confirm exposure by checking: (1) is Gitea Actions enabled, (2) is at least one runner registered for the base repository, and (3) does the repository accept pull requests from forks/external contributors. If all three are true, you are exposed by default — no special configuration is needed beyond having Actions enabled. Upgrade to Gitea 28.0.0 or later, which fixes the approval logic in PR #39399 by basing approval decisions on the PR author rather than the event-triggering user. Review the vendor advisory (GHSA-xh39-mxw9-34pp) for interim mitigations if immediate upgrade isn't possible — options generally include disabling Actions for externally-contributed repos, de-registering shared runners from public-facing repos, or requiring explicit manual approval for all fork PR runs regardless of triggering actor. After patching, audit Actions run logs for any fork-triggered workflow runs that executed without an approval step, particularly around label/assignment events on PRs from unknown contributors. No CISA KEV listing or confirmed in-the-wild exploitation exists as of this writing, so there's no regulatory due date, but the low barrier to exploitation argues for prioritizing this over EPSS-driven triage.

CVSS 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N, full confidentiality/integrity/availability impact. Weakness class: CWE-441 (Unintended Proxy/Intermediary) combined with CWE-863 (Incorrect Authorization) — the approval-gate check binds to the event's triggering actor rather than the content author, allowing fork-origin workflow code to run on trusted runners without the intended manual-approval control. No KEV listing, no dated news reporting of active exploitation, and no public exploit code are on record as of 2026-10-20; EPSS predicts low near-term exploitation likelihood with a flat trend. Exploit maturity is currently theoretical/PoC-absent, but the vulnerability is remotely reachable with default configuration (Actions enabled + any registered runner) and requires no authentication or user interaction beyond routine maintainer triage activity. Fixed upstream in Gitea 28.0.0 via PR #39399; vendor advisory GHSA-xh39-mxw9-34pp documents interim workarounds.