Gitea EUVD-2026-93914

Exploitation is triggered specifically when an organization owner changes a team's permission level through the Gitea REST API submitting only the permission field (e.g., demoting admin→read); the code neither rebuilds the team's per-unit access nor applies the requested level as a cap, so previously granted unit permissions (including write to team repositories) persist. Prerequisites/limits: the target team must have existing per-unit repository access, an administrator must perform the API-based demotion, and the beneficiary must already be an authenticated member of that team. The web UI form path is explicitly NOT affected, so organizations that manage team permissions only through the web form are not exposed. Affected versions are Gitea ≤1.27.3; upgrading to v28.0.0 remediates.

This is a genuine but conditional broken-access-control flaw (CWE-272, Incorrect Privilege Assignment) in Gitea rather than a mass-exploitable remote code execution issue. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, 8.1 High) indicates network-reachable, low-complexity exploitation by an already-authenticated low-privilege actor with high confidentiality and integrity impact and no availability impact - consistent with a team member retaining write/read repository access they should have lost. The exploitation-enabling signals are weak: EPSS is only 0.16% (5th percentile), there is no CISA KEV listing, and no public exploit code is identified, so this is best treated as a lower-urgency patch-management item than the 8.1 score alone implies. A key nuance the CVSS score cannot capture is that the elevated access does not arise from an attacker action but from an administrator mistake: the flaw only manifests after an organization owner demotes a team via the API supplying only the permission field, so the real-world risk is concentrated in environments that programmatically manage team permissions. No signals are in direct conflict, but note the input Tag 'Information Disclosure' understates the issue - the retained access includes write (C:H AND I:H), making this a privilege-retention/least-privilege-violation problem, not merely disclosure.

An organization owner uses the Gitea API to demote a team (e.g., from admin to read) by sending only the permission field, intending to reduce the team's access. Because the per-unit access is not rebuilt and the new level is not applied as a cap, the team's members silently keep their previous unit permissions - including write access to the organization's repositories - and can continue reading and pushing to repos they should no longer control. No public exploit code is identified at time of analysis; exploitation requires an existing low-privileged team account plus the triggering administrative API call.