Gitea EUVD-2026-103982

Exploitation requires ALL of: (1) the target Gitea instance has OpenID login/association enabled and reachable; (2) the victim is actively signed into Gitea at the time; (3) the victim opens an attacker-crafted link that drives the OpenID association callback (UI:R); and (4) the attacker controls or can direct the flow through an OpenID 2.0 provider capable of returning an unsolicited positive assertion. Limiting factors that reduce real-world risk: the required user interaction, dependence on the OpenID feature being enabled (non-universal configuration), and the version ceiling (Gitea ≤28.1.0; fixed in 28.2.0). No standing account or privileges on the Gitea instance are needed by the attacker (PR:N).

This is a moderate, defender-manageable issue rather than an urgent fire. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N, base 5.4) correctly captures a network-reachable, low-complexity, unauthenticated flaw that is gated by user interaction. All exploitation signals point the same direction and are consistent: EPSS is very low (0.11%, 1st percentile), there is no CISA KEV listing, no public exploit code is referenced, and CISA SSVC scores Exploitation=none, Automatable=no, Technical Impact=partial. The 'Automatable: no' rating aligns with the UI:R requirement - an attacker cannot mass-exploit this without tricking individual signed-in victims into opening crafted links, so this is a targeted-only technique, not a wormable or scan-and-spray bug. One point of divergence worth flagging: the vendor-supplied impact (C:L/I:L) understates the outcome, since the described end state is the attacker signing in AS the victim (effective account takeover that also bypasses the victim's TOTP/WebAuthn), which I assess as higher impact (see assessed vectors). Net: a real, legitimate authentication-bypass bug that self-hosting Gitea operators should patch in routine maintenance, but not a drop-everything emergency absent active exploitation.

A victim is logged into a Gitea instance that permits OpenID login. The attacker lures the victim into opening a crafted link that drives Gitea's OpenID association callback; because the pre-patch callback accepted an unsolicited OpenID 2.0 positive assertion without verifying the victim initiated the linking, the attacker's attacker-controlled OpenID identity gets bound to the victim's account. The attacker then logs in via OpenID as the victim, bypassing the victim's local TOTP/WebAuthn. No public exploit code is identified at time of analysis, but the technique relies only on OpenID 2.0's unsolicited-assertion behavior and user interaction.