CVE-2026-103059

Gitea is a self-hosted tool many small teams use instead of GitHub to store and manage their code. This bug is like a building's key-card reader accepting a badge with the name typed in the wrong capitalization — someone with a similarly-shaped key could get treated as a different, trusted employee and walk right in under that person's identity.

This matters to you if you self-host Gitea and have its built-in SSH server enabled (the setting START_SSH_SERVER = true). If you only use Gitea's web interface, or disable the SSH server, or rely on an external SSH service instead, you are not exposed. It is especially relevant if your Gitea database is SQLite, since that database's case-insensitive comparisons make the flaw exploitable there.

This is a critical-severity authentication bypass that requires no password and no user interaction to exploit, so it should be treated as a top priority even though there is no confirmed active exploitation or public exploit code yet. Because the flaw lets one user silently impersonate another over SSH, waiting to patch leaves your source code and commit history exposed to tampering. Treat this as act-now rather than wait-and-see.

Confirm exposure by checking your app.ini for START_SSH_SERVER = true; instances with the SSH server disabled, or using an external OpenSSH-based setup instead of the built-in server, are not affected. Upgrade to Gitea 28.0.0 or later, which replaces the case-insensitive SQL LIKE key lookup with fingerprint-based matching (see PR go-gitea/gitea#39423 and advisory GHSA-8pwg-hcgm-54cp). There is no official workaround short of disabling the built-in SSH server (START_SSH_SERVER = false) and switching SSH access to an external, properly-configured sshd if you cannot upgrade immediately; this fully mitigates the issue since the vulnerable lookup only exists in Gitea's internal SSH handler. No CISA KEV listing or due date applies currently, and EPSS predicts low near-term exploitation likelihood, but given the CVSS 9.1 score and trivial exploitation logic, prioritize patching over relying on that prediction. After upgrading, review SSH authentication logs for mismatched key/user pairs as a retrospective check.

CWE-305 (Authentication Bypass by Primary Weakness), CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) — network-exploitable, low complexity, no privileges or interaction required, with high confidentiality and integrity impact but no availability impact. Not listed in CISA KEV, no public exploit code identified, and EPSS places predicted exploitation likelihood in the 19th percentile with a flat trend — i.e., not currently a predicted hot target, though this reflects prediction rather than confirmed activity. Root cause: the SSH server resolved presented public keys via a case-insensitive SQL LIKE match against stored key text (notably on SQLite), rather than an exact/fingerprint comparison, enabling cross-account key-matching collisions for attackers who can derive a private key matching a case-folded variant of a victim's registered public key. Fixed in Gitea 28.0.0 via fingerprint-based key lookup.