Gitea CVE-2026-103059

Exploitation requires ALL of: (1) Gitea's built-in SSH server enabled via START_SSH_SERVER=true (not the default on many deployments, which proxy to the host SSH daemon); (2) a backing database with case-insensitive text comparison, such as the default SQLite, so that the vulnerable 'content LIKE' lookup collapses case; and (3) the attacker possessing or being able to derive a working RSA private key whose corresponding public key is a case-altered but still-matching variant of the victim's registered key. Condition (3) is the dominant limiting factor - generating a valid keypair that differs from a target key only by case is cryptographically very hard - which, together with the non-default SSH configuration, sharply constrains realistic exploitation despite the network, no-user-interaction vector. Fixed in v28.0.0 by matching keys on SHA256 fingerprint instead of encoded content.

The signals here are sharply divided between theoretical severity and practical exploitability. The NVD CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H) and the SSVC rating (Technical Impact: total, Automatable: yes) frame this as a critical remote authentication-bypass allowing full impersonation of another user over SSH. However, the real-world risk indicators pull strongly the other way: EPSS is only 0.16% (4th percentile), SSVC Exploitation status is 'none', there is no CISA KEV listing, and no public exploit was identified. Most importantly, the CVSS AC:L (low complexity) is questionable - the description requires an attacker to construct a *case variant* of the victim's registered RSA public key *for which they can derive the matching private key*. Producing a valid RSA keypair whose base64-encoded public key differs from the victim's only by letter case is a hard, likely intractable cryptographic constraint, which realistically makes this high-complexity (AC:H), not AC:L. CONFLICT TO NOTE: the CVSS vector claims AC:L and PR:N (trivial, unauthenticated), but the cryptographic precondition and the requirement for a non-default deployment (built-in SSH server enabled, case-insensitive DB such as the default SQLite) make low-effort mass exploitation implausible. Net assessment: patch on a normal cadence; this is a high-severity-by-impact but low-probability issue, not an emergency, absent evidence of active exploitation.

An attacker targeting a Gitea instance with the built-in SSH server enabled (START_SSH_SERVER=true) on a case-insensitive database (default SQLite) attempts to authenticate over SSH by presenting a public key that is a case-altered variant of a victim's registered RSA key, having derived a usable private key for that variant. Because the server matched keys with a case-insensitive SQL LIKE comparison rather than by fingerprint, the variant resolves to the victim's account and the attacker is logged in as that user. No public exploit code was identified at time of analysis, and the required ability to derive a private key for a case-variant key is a substantial practical barrier.