External risk intelligence

Gitea SSH Public Key Bypass Allows Impersonation.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-103059

The vulnerability exists in Gitea's built-in SSH server, which is frequently enabled to allow developers to interact with repositories remotely. Since Git over SSH is a standard, internet-reachable interface for code hosting platforms, this service is commonly exposed to the internet to facilitate remote access, making the vulnerable authentication path likely to be exposed in many real-world deployments.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability in Gitea's SSH server could allow an attacker to impersonate another user by exploiting how public keys are matched, potentially granting unauthorized access to repositories. This issue affects the built-in SSH server when enabled, and while the main concern is confirming relevance, the potential for unauthorized access means it warrants attention.

SSH key matching issue in Gitea.
Allows unauthorized SSH access as other users.
Confirm Gitea SSH relevance and exposure.

Attack Path

How an attacker could exploit the issue

An attacker could potentially impersonate another user by exploiting a vulnerability in Gitea's SSH server. If the SSH server is active, an attacker could craft a modified version of a legitimate user's public SSH key. By submitting this altered key, the system might incorrectly associate it with the victim's account due to a case-insensitive comparison in some database configurations, allowing the attacker to authenticate as that user.

Attack starts with network access.
Triggered by submitting a modified public key.
Risk of unauthorized SSH access.

Live Threat

Current exploitation, exposure, and threat context

When Gitea's built-in SSH server is enabled, an attacker could potentially authenticate as another user. This could happen if an attacker can craft a case-variant of a victim's registered SSH public key and also possesses the corresponding private key.

User SSH keys could be compromised.
Attacker could spoof another user's SSH key.
Unauthorized SSH access to repositories.

Operational Fix

Recommended remediation, mitigation, and detection steps

The critical vulnerability in Gitea's SSH server impacts teams managing code repositories and their underlying infrastructure. The first practical step is to identify all Gitea instances, confirm their exposure and business criticality, and then assign ownership for remediation planning based on risk.

Identify Gitea instances and confirm exposure.
Assign ownership for risk-based remediation.
Plan maintenance for vulnerability mitigation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Gitea and why is it used?

Gitea is a self-hosted Git service used by development teams to manage, host, and collaborate on software repositories. It provides a platform for version control, issue tracking, and code reviews, often running on infrastructure controlled by the organization. The vulnerability specifically involves its optional built-in SSH server, which developers use to push and pull code securely between their local machines and the server.

What is the vulnerability in CVE-2026-103059?

This flaw is classified under CWE-305: Authentication Bypass by Primary Authentication Facility. It occurs because the application uses a case-insensitive SQL match when verifying SSH keys. This means the system may fail to distinguish between different key formats, potentially accepting a maliciously crafted key as a valid match for a legitimate user's account, allowing an attacker to impersonate them.

How does an attacker trigger this SSH key bug?

An attacker must be able to present a case-variant version of an existing user's RSA public key while also possessing the corresponding private key for that variant. The bug is not triggered by standard, correct key usage. If the SSH server is disabled or configured to use a database that does not perform case-insensitive matching for this lookup, the specific conditions for this bypass are not met.

Is my Gitea instance vulnerable?

According to Halo Surface Signal, this vulnerability is particularly relevant if your Gitea instance has the built-in SSH server enabled and is exposed to the internet. Since Git over SSH is a standard, frequently internet-reachable interface for code collaboration, many production environments face a higher likelihood of being reachable by attackers, increasing the necessity for you to verify your specific configuration.

What steps should I take if I run Gitea?

First, perform an inventory to locate all active Gitea installations within your infrastructure. Once identified, determine if the built-in SSH server is currently running. If it is, evaluate the risk to your business operations and initiate a planning phase to apply authorized updates. Ensure your team confirms whether remediation paths, such as updating to a version that utilizes secure key fingerprinting, are available.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.