Gitea CVE-2026-27657

Exploitation requires an authenticated Gitea session (any registered low-privilege user) and reachability of the account settings endpoint /user/settings/account/email; the attacker submits the form parameter _method=PRIMARY with an 'id' referencing an email row owned by another user. What limits exploitation: the attacker must have a valid account (so instances with closed/admin-approved registration greatly restrict the attacker pool), must know or enumerate a target email row's integer ID (feasible because IDs are sequential), and the impact is confined to changing another user's primary email - no code execution, data disclosure, or availability loss. The published PR:N is contradicted by the code path and tests, which require login - treat this as an authenticated (PR:L) flaw despite the NVD vector.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N = 7.5) rates this as unauthenticated network integrity impact, but the vulnerable code path and the patch's integration test (loginUser 'user2') both require an authenticated session, so PR:N appears inaccurate - realistic exploitation needs any valid low-privilege account, i.e. PR:L. This lowers real-world severity somewhat from the 7.5 headline. Supporting signals are consistent and modest: EPSS is 0.17% (6th percentile), CISA SSVC records Exploitation=none, Automatable=yes, Technical Impact=partial, and there is no KEV listing and no public exploit. The Automatable=yes flag is credible given sequential integer email IDs and a simple POST, so an attacker with an account could enumerate/target victims cheaply, but confidentiality and availability are untouched (C:N/A:N) and impact is bounded to integrity of another user's email setting. Net: a legitimate medium-priority patch item, not an emergency - no active exploitation and low probability, but easy to exploit once authenticated.

An attacker registers or uses an existing low-privilege Gitea account, then submits a POST to /user/settings/account/email with _method=PRIMARY and an 'id' value guessed or enumerated from the sequential email-address table that belongs to a victim account. On unpatched versions the server sets that victim-owned email as primary without an ownership check, altering the victim's account email of record. No public weaponized exploit is known, but the patch's own integration tests demonstrate the exact request, so building a proof-of-concept is trivial.