Gitea EUVD-2026-93925

Requires the repository owner to initiate a transfer of a PRIVATE repository to a Gitea user who lacks prior access to it; that named recipient is then granted read collaboration which is NOT revoked when the transfer is rejected or cancelled. Limiting factors that reduce real-world risk: the attacker must be the SPECIFIC user designated as the transfer recipient (not any arbitrary user), must hold a valid authenticated Gitea account, and a transfer must actually have been initiated toward them - it is not attacker-initiated against default configurations. Pre-existing collaborations are unaffected by the fix. Impacts Gitea versions ≤1.27.3.

This is a stale-permission/access-control flaw (CWE-672) in Gitea where a private-repository transfer recipient retains read collaboration after the transfer is rejected or cancelled. The provided CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) indicates a network-reachable, low-privilege, no-user-interaction issue with confidentiality-only impact - consistent with the description. Risk signals are uniformly low-to-moderate and non-conflicting: EPSS is 0.27% (17th percentile), there is no CISA KEV listing (not actively exploited), and no public exploit code was identified - only the vendor fix PR. The one caveat is impact scoping: NVD rated confidentiality as Low (C:L), but the description states the recipient retains full read of the repository's code, issues, pull requests and wiki and can clone it, which argues for a High confidentiality impact on the affected repository - see assessed vector. Net assessment: a genuine but narrowly-scoped privacy/access-control bug, not a mass-exploitation priority. It matters most to organizations that routinely transfer private repositories and rely on rejection/cancellation to fully revoke access. No data is missing beyond POC status; absence of KEV and low EPSS together suggest no widespread exploitation.

A repository owner initiates a transfer of a private repo to another Gitea user who previously had no access; that user is auto-granted temporary read collaboration. The recipient (or owner) then rejects or cancels the transfer, but the collaboration is never revoked, so the recipient silently keeps read access and clones the full repository, issues, PRs and wiki without the owner being notified. No public exploit code exists; exploitation requires only being the designated recipient of an attempted transfer (PR:L, AC:L, no user interaction by the victim).