Gitea: Team permission demotion via API not applied to repository unit access
Summary
Gitea does not update the per-unit access of organization teams when a team's permission is lowered through the API with only the permission field. After an organization owner demotes a team, for example from admin to read, its members keep their previous unit permissions, including write access to the team's repositories. An attacker with a low-privilege account would need to be a team member, and the web form is not affected.
Affected
- Gitea 0 to 1.27.3 according to the CNA record (default: unaffected)
- Exact affected range: Unknown, to be confirmed in the GHSA advisory
Fixed in
- Gitea 28.0.0 (fix via pull request #38938)
- Use the latest 28.x release
Workaround
- No vendor workaround documented.
- Until upgrade: review teams lowered through the API, re-save them in the web UI, and audit write access of their members.
Exploitation
- Not known to be exploited.
- CISA SSVC: Exploitation none, Automatable no, Technical Impact total.
- Not listed in the CISA KEV catalog (as far as known).
Our recommendation
- Upgrade to Gitea 28.0.0 or later (latest 28.x recommended).
- Until then, check teams whose permission was lowered through the API and compare their per-unit access.
- Re-save affected teams in the web UI and review repository write access for their members.
- Review team membership regularly and limit organization owner rights.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Gitea 28.0.0 release blog blog.gitea.com
- Gitea pull request #38938 github.com
- Gitea v28.0.0 release github.com
- GitHub security advisory GHSA-x8c3-3rp8-2j46 github.com
- OSV entry CVE-2026-103504 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 1 Nov 2026, 20:43.
Original description (NVD)
Changing an organization team's permission through the API with only the `permission` field did not rebuild the team's per-unit access, and the requested level was not applied as a cap. After an organization owner demoted a team, for example from admin to read, the team's members kept their previous unit permissions, including write access to the team's repositories. The web form was not affected.
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.