Gitea: Approval bypass for fork pull request workflows via cancel and rerun
Summary
Gitea Actions blocks workflow runs from first-time fork pull request contributors until a maintainer approves them. The rerun path ignored this pending approval, so a user with Actions write access who cancelled and re-ran such a run could cause the fork's workflow code to run on the repository's runners without approval. Exploitation requires Actions to be enabled and a matching self-hosted runner to be registered for the repository.
Affected
- Gitea 0 to 1.27.3 (inclusive)
Fixed in
- Gitea 28.0.0 (fix in pull request #39399)
Workaround
Unknown.
Exploitation
- CISA SSVC: exploitation none, automatable no, technical impact total.
- The advisory describes an end-to-end proof of concept on Gitea 1.27.3 with act_runner.
- No reports of in-the-wild exploitation are known.
Our recommendation
- Upgrade to Gitea 28.0.0 or later, preferably the latest 28.x, after a backup.
- Limit Actions write access to trusted users and review cancel and rerun events for fork pull request runs.
- Do not rerun fork pull request checks that are waiting for approval.
- Check whether self-hosted runners are used and keep them away from secrets and sensitive networks.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- GHSA-pvjf-7jrm-6w9g Security Advisory github.com
- Pull request #39399: fix(actions): harden fork pull request run approval github.com
- Gitea 28.0.0 release github.com
- Gitea 28.0.0 release announcement blog.gitea.com
- OSV BIT-gitea-2026-104632 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 31 Oct 2026, 21:41.
Original description (NVD)
Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the 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.