Gitea CVE-2026-109844

Exploitation requires an authenticated Gitea user who PREVIOUSLY had legitimate access to a private repository, starred or watched it while access was granted, and subsequently LOST that access (e.g., team permission downgrade or collaborator removal) while retaining a valid account/API token. The specific condition is that the star/watch record persists after access revocation, and the GET /api/v1/user/subscriptions and /user/starred endpoints failed to re-check current access. Limiting factors that reduce real-world risk: the attacker must hold valid credentials (PR:L, not anonymous), must have had prior legitimate access to the target repo, only repository METADATA is exposed (name, description, clone URLs, owner, counters) and not repository contents, and the affected Gitea version must be ≤1.26.4 (fixed in 1.27.0 and 28.0.0).

This is a genuine but low-severity broken-access-control issue (CWE-862, Missing Authorization), and every available signal agrees it is NOT a high-priority threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3 MEDIUM) shows the only impact is a limited confidentiality leak (C:L) with no integrity or availability effect, and it requires an authenticated account (PR:L). EPSS reinforces this with a 0.15% exploitation probability (4th percentile), and CISA's SSVC framework rates Exploitation: none, Automatable: no, Technical Impact: partial - all consistent with each other. The vulnerability is not in CISA KEV and no public exploit code was identified; only the vendor's own regression test demonstrates the behavior. There is no conflict among the signals here: network vector plus low privilege is accurate because this is a REST API endpoint callable by any authenticated user holding a retained token. The practical ceiling is low: an attacker only recovers repository METADATA (name, description, clone URLs, owner, counters) for private repos they ONCE legitimately accessed and still star/watch - not file contents, and not arbitrary repositories. Treat this as a routine patch-management item, not an emergency.

A contractor is added to a team with read access to a private repository, stars or watches it, then is removed from the team (or downgraded). Although their access was revoked, their valid API token still returns the repo's name, description, clone URLs, owner, and counters via GET /api/v1/user/subscriptions (and the starred-repos endpoint), leaking metadata about a project they should no longer see. No public exploit code exists; the attack simply requires calling the endpoint with a retained token.