Gitea EUVD-2026-103983

Exploitable ONLY when the Gitea instance is configured to trust a user certificate authority via SSH_TRUSTED_USER_CA_KEYS AND to accept arbitrary certificate principals via SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything; instances that do not trust a user CA are explicitly not affected. The attacker must either be able to register a public key line as a principal (requiring a low-privilege account, consistent with PR:L) or hold a certificate signed by the trusted authority. Limiting factors: this trusted-CA-plus-permissive-principals combination is non-default and uncommon, no user interaction is needed, and affected versions are Gitea ≤28.1.0 (fixed in 28.2.0).

This is a genuine but highly conditional authentication-bypass/impersonation flaw rather than a broadly exploitable crisis. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.5) correctly captures network reach, high attack complexity, and the requirement for low-privilege attacker access, with total C/I/A impact because successful exploitation lets an attacker authenticate AS another user. The exploitation signals strongly agree on LOW real-world urgency: EPSS is 0.10% (1st percentile), there is no CISA KEV listing, no public POC, and CISA SSVC scores Exploitation=none and Automatable=no - only Technical Impact=total is elevated, which reflects severity-if-exploited, not likelihood. The dominant risk-limiting factor is configuration: per the vendor advisory, instances are ONLY affected when they trust a user certificate authority (SSH_TRUSTED_USER_CA_KEYS) AND accept arbitrary principals (SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything), a non-default and uncommon hardening-sensitive setup. No signals conflict, but note one labeling discrepancy: the input Tags call this 'Information Disclosure' whereas the mechanism is account impersonation/authentication bypass - the impact is unauthorized access as another user, not mere data leakage. Bottom line: a legitimately high-impact bug with a narrow precondition and near-zero observed exploitation - patch during normal maintenance unless the specific trusted-CA configuration is in use, in which case prioritize.

On a Gitea instance configured to trust a user certificate authority and to accept arbitrary principals, a low-privileged attacker registers a victim's public key line as their own principal key (or presents a CA-signed certificate listing it). Because Gitea matched the certificate principal against ALL stored public keys rather than only principal-type keys, the attacker then authenticates as the victim through the HTTP signature API or the built-in SSH server, taking over the victim's account and repositories. No public exploit identified at time of analysis.