CVE-2026-103504: Gitea API team demotion not applied to unit permissions
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.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Organizations that change team permissions through the Gitea API using an update containing only the permission field are exposed. Teams changed through the web form are not affected.
What access is required to trigger the issue?
An organization owner must use the API to demote a team's permission level with only the permission field. The impact is that existing team members can retain prior per-unit permissions, such as repository write access, after the demotion.
How can administrators determine whether they are affected?
Review team permission changes performed through the API and identify demotions submitted with only the permission field. Verify the affected team's current per-unit access, particularly repository permissions, to confirm that members no longer retain permissions from the prior level.
What can be done if patching is not immediately possible?
Avoid making team permission changes through the API with only the permission field. Use the web form for team permission changes and manually verify or correct per-unit permissions for teams previously demoted through the API.