Gitea EUVD-2026-94067

Exploitable by sending a GET request to a user/organization profile route (/{username}) with an 'Accept: application/rss+xml' or 'Accept: application/atom+xml' header, which reaches the profile-feed handler that lacked the visibility check. It works against limited/private users and private organizations and even when the '[other] ENABLE_FEED' setting is disabled, so no special server configuration is required. Limiting factors: only profile details, user/org existence, and already-public activity are exposed, while activity in private repositories is NOT returned, capping impact at metadata/enumeration. Affects Gitea versions through 28.0.0; fixed in 28.1.0.

This is a low-severity information-disclosure issue (CWE-200) that is genuinely a low real-world priority. Most risk signals align downward: EPSS is 0.15% (3rd percentile), it is NOT listed in CISA KEV, and SSVC rates exploitation as 'none', automatable as 'no', and technical impact as only 'partial'. The provided CVSS is 4.3 with confidentiality-only impact (C:L, I:N, A:N). However, there is a notable conflict between signals: the supplied CVSS vector states PR:L (authenticated attacker required), yet the description explicitly says 'Anonymous users, restricted users and non-members' could exploit it, implying PR:N (unauthenticated). This contradiction suggests the vendor vector slightly understates exposure, since an unauthenticated enumeration primitive is somewhat more concerning than PR:L implies; verify the authentication requirement against the vendor advisory. That said, the impact ceiling remains low because only profile metadata, existence confirmation, and already-public activity leak, and activity in private repositories is explicitly excluded. Net: a real but minor privacy/enumeration bug, not an urgent patch-now priority except where Gitea's private-user/private-org visibility is relied upon as a security boundary.

An unauthenticated attacker wanting to confirm whether a specific private Gitea user or private organization exists sends GET /{username} with an 'Accept: application/rss+xml' header instead of browsing the correctly protected profile page or .rss/.atom routes. The server returns the owner's activity feed and profile details, bypassing the visibility check even when [other] ENABLE_FEED is disabled. No public exploit code is identified, but the technique is trivially reproducible from the description with a single crafted request.