CVE-2026-103059: Gitea SSH Server Auth Bypass Vulnerability

CVE-2026-103059 Overview

CVE-2026-103059 is an authentication bypass vulnerability in Gitea's built-in SSH server. When START_SSH_SERVER = true is configured, Gitea looked up presented public keys with an SQL LIKE comparison against their encoded content. On databases that perform case-insensitive matching by default, including SQLite, this allowed a case-variant of another user's RSA public key to match the victim's account. An attacker able to generate a case-variant key whose private counterpart they control could authenticate over SSH as the victim. The flaw is tracked under [CWE-305: Authentication Bypass by Primary Weakness].

Critical Impact
Attackers can authenticate over SSH as arbitrary Gitea users and gain full access to their repositories, breaking confidentiality and integrity of hosted code.

Affected Products

Gitea instances with the built-in SSH server enabled (START_SSH_SERVER = true) prior to v28.0.0
Gitea deployments backed by the default SQLite database or any database with case-insensitive LIKE semantics
Self-hosted Gitea Git servers exposing SSH to untrusted networks

Discovery Timeline

2026-10-06 - CVE-2026-103059 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-103059

Vulnerability Analysis

Gitea's SSH authentication path matched presented public keys against stored keys using an SQL LIKE query on the encoded key material. In SQLite, the default LIKE operator is case-insensitive for ASCII characters. Base64-encoded SSH keys use a case-sensitive alphabet, so case-folding during lookup collapses distinct key encodings into the same match set.

An attacker who obtains a victim's registered RSA public key can search for a case-variant string that both matches the victim's key under case-insensitive comparison and represents a valid RSA key for which the attacker controls the private half. Presenting that attacker-controlled key over SSH causes Gitea to resolve the match to the victim's account and complete authentication as that user.

The upstream fix replaces content-based LIKE lookups with fingerprint-based lookups, which are deterministic and case-sensitive. The vulnerability is classified under [CWE-305] because the primary authentication check itself is bypassed, not a secondary control.

Root Cause

The root cause is an insecure comparison primitive. SQL LIKE without COLLATE BINARY or equivalent is not safe for matching cryptographic material. Combined with SQLite's default collation, the lookup accepted keys that were not byte-equal to the stored key.

Attack Vector

Exploitation requires network access to the Gitea SSH port and knowledge of a target user's public key, which is often exposed through Gitea's public API endpoints. The attacker then constructs a case-variant RSA key they can sign with and connects to the SSH server. No prior authentication or user interaction is required.

See the GitHub Security Advisory GHSA-8pwg-hcgm-54cp and the Gitea Pull Request Update for the technical remediation details.

Detection Methods for CVE-2026-103059

Indicators of Compromise

SSH authentication events in Gitea logs where the connecting key fingerprint does not match any fingerprint stored for the authenticated user account.
Successful SSH logins from source IP addresses or ASNs that have not previously been associated with the target user.
Git operations (clones, pushes, force-pushes) performed over SSH outside the user's normal working hours or from unexpected geographies.

Detection Strategies

Audit the public_key table and correlate stored key fingerprints against fingerprints recorded in SSH session logs for every authentication event.
Enable verbose SSH logging in Gitea and ship events to a central log platform for retrospective fingerprint comparison.
Review repository audit trails for unexpected commits, branch deletions, or webhook changes attributed to users during the exposure window.

Monitoring Recommendations

Alert on any SSH authentication where the presented key fingerprint is not an exact match to a stored user key.
Monitor for new SSH key enumeration patterns against /users/{username}/keys and similar endpoints that expose public keys.
Track Gitea version strings across the estate to confirm all instances are running v28.0.0 or later.

How to Mitigate CVE-2026-103059

Immediate Actions Required

Upgrade all Gitea instances to v28.0.0 or later, where key lookups use fingerprints instead of LIKE comparisons.
If immediate upgrade is not possible, set START_SSH_SERVER = false and front Gitea with an external SSH server or disable SSH access entirely.
Rotate SSH host and user keys, and audit recent SSH authentication events for anomalous fingerprints.

Patch Information

Gitea addressed CVE-2026-103059 in Gitea Release v28.0.0. The change set, published in Gitea Pull Request 39423, replaces encoded-content LIKE lookups with fingerprint-based lookups so that case variants no longer resolve to a stored key. See the Gitea Blog Release Announcement for the full release context.

Workarounds

Disable the built-in SSH server by setting START_SSH_SERVER = false in app.ini and restart Gitea.
Migrate the Gitea database from SQLite to a backend configured with case-sensitive collation for the public_key content column, as an interim hardening step.
Restrict SSH access to Gitea at the network layer using firewall rules or a VPN until the upgrade is applied.

bash

# Configuration example: disable the built-in SSH server in app.ini
[server]
START_SSH_SERVER = false
DISABLE_SSH      = true