Gitea: Approval bypass for fork pull request workflows in Gitea Actions
Summary
Gitea Actions decides whether a fork pull request run needs approval based on the user who triggered the event instead of the pull request author. When a maintainer triggers a pull_request sub-event during routine triage, such as adding a label, the run is created without approval while the workflow is still taken from the fork head. An attacker who submits a malicious fork pull request can therefore execute workflow code on the base repository's self-hosted runners without an explicit approval, provided Actions is enabled and a matching runner is registered.
Affected
- Gitea 1.27.3 and earlier (affected range 0 to <= 1.27.3)
Fixed in
- Gitea 28.0.0 (per the GitHub advisory and the Gitea 28.0.0 release notes; exact fixed version to be confirmed against the vendor advisory)
Workaround
Unknown.
Exploitation
- CISA SSVC: exploitation none, automatable yes, technical impact total
- No public exploitation or known in-the-wild use reported at the time of writing
- Proof of concept described in the vendor advisory; not independently verified
Our recommendation
- Upgrade Gitea to 28.0.0 or a later 28.x release
- Until the upgrade, do not run fork pull request workflows on self-hosted runners and limit runner scope to trusted repositories
- Restrict who can label or triage pull requests where Actions is active
- After upgrading, review runs that were created from fork pull requests during the exposure period
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- GitHub Security Advisory GHSA-xh39-mxw9-34pp github.com
- Gitea 28.0.0 release announcement blog.gitea.com
- Gitea v28.0.0 release github.com
- Pull request #39399: fix(actions): harden fork pull request run approval github.com
- OSV entry CVE-2026-94205 osv.dev
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 30 Oct 2026, 20:54.
Original description (NVD)
Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.