Gitea EUVD-2026-103990

Requires a valid signed-in account on the target Gitea instance (PR:L) - self-registration, if enabled, satisfies this. The target user must have configured a private/limited-visibility profile; public profiles leak nothing new. Exploitation is performed against the POST /{username} follow/unfollow endpoint, whose visibility check was absent (it was enforced only on GET). Limiting factors: only users with private profiles are affected, only a bounded set of profile fields (full name, location, website, description) is exposed, and an authenticated session is mandatory, so unauthenticated internet-wide exploitation is not possible. Fixed in 28.1.0 (disclosed 28.2.0).

This is a genuine but modest-priority information-disclosure flaw (CWE-200). The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5) correctly reflects network-reachable, low-complexity access requiring an authenticated account (PR:L) with no user interaction and no integrity/availability impact. All exploitation signals point toward low real-world urgency: EPSS is 0.16% (4th percentile), the CVE is NOT on CISA KEV, and no public exploit code is referenced - so exploitation status is 'no public exploit identified at time of analysis.' The one point of tension is the Confidentiality rating: the vendor/NVD vector claims C:H, but the data actually disclosed is limited profile metadata (full name, location, website, description of users with private profiles), which is closer to C:L in my independent judgment - this inflates the 6.5 base score somewhat. Net assessment: a real, vendor-confirmed authorization gap worth patching on normal cycles, but NOT an emergency - it requires a valid account, affects only users who deliberately set a private profile, and leaks non-credential PII rather than enabling takeover.

An attacker who holds any valid (even self-registered) account on a Gitea instance targets a user who has set their profile to private. Instead of a GET to the profile (which enforces visibility), the attacker sends POST /{username} (the follow/unfollow action), which only checked for a signed-in session, and reads the private user's full name, location, website and description from the response. No public exploit code is referenced, but the request is trivial to craft manually.