CVE-2026-109553: Gitea SSH Certificate Authentication Bypass

CVE-2026-109553 Overview

Gitea contains an authentication bypass flaw in its SSH certificate principal resolution logic. The server resolved principals by searching the content of all stored public keys, rather than restricting the lookup to designated principal keys. When an instance trusts a user certificate authority through SSH_TRUSTED_USER_CA_KEYS and accepts arbitrary principals via SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything, an attacker can register another user's public key line as their own principal. The attacker can then authenticate as the owner of that key through the HTTP signature API or the built-in SSH server. Instances that do not trust a user certificate authority are not affected.

Critical Impact
Authenticated attackers can impersonate other Gitea users and gain full access to their repositories through SSH or HTTP signature authentication.

Affected Products

Gitea versions prior to 28.2.0
Gitea instances configured with SSH_TRUSTED_USER_CA_KEYS
Gitea instances with SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything

Discovery Timeline

2026-10-18 - CVE-2026-109553 published to NVD
2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-109553

Vulnerability Analysis

The flaw resides in how Gitea maps an SSH certificate's principal string back to a user account. Instead of searching only principal-type keys, Gitea queried the full content of every stored public key. A principal is simply a string embedded in a signed SSH certificate. When Gitea accepts arbitrary principal values, that string can be set to the full text of another user's public key line.

During authentication, Gitea matches the principal string against stored key content and returns the owning user. The attacker then authenticates as that user via the SSH server or the HTTP signature API. The vulnerability is categorized as an Authentication Bypass combined with Broken Access Control.

Root Cause

The principal resolution query did not filter by key type. It performed a substring or content match across all public keys stored in the database, including user-uploaded SSH keys that are not intended to serve as principal identifiers. This conflation of key purposes allowed an unprivileged user to influence the mapping between a certificate principal and a target account.

Attack Vector

Exploitation requires an instance that trusts a user certificate authority and permits arbitrary principals. An attacker needs either a certificate signed by the trusted authority or the ability to register a public key containing the victim's key text as a principal. Once registered, the attacker presents the certificate during SSH authentication or signs HTTP requests to the signature API. Gitea resolves the principal to the victim user and grants access to the victim's repositories and permissions.

See the Gitea Security Advisory GHSA-vcp6-2qc6-gvq3 for the technical write-up and the fix in Gitea Pull Request #39839 and Gitea Pull Request #39847.

Detection Methods for CVE-2026-109553

Indicators of Compromise

Public keys registered by users whose content matches another user's existing key line.
SSH authentication events where the authenticated username differs from the certificate owner expected by administrators.
Unexpected successful HTTP signature API calls referencing principals that do not match the requesting account.
Repository access or Git operations originating from accounts whose owners did not initiate them.

Detection Strategies

Audit the public_key table for entries whose content field contains substrings of other users' key lines.
Review Gitea authentication logs for SSH certificate logins that resolve principals through user-uploaded keys rather than configured principal keys.
Correlate IP addresses and user agents across accounts to identify a single actor authenticating as multiple users.

Monitoring Recommendations

Enable verbose SSH and HTTP signature logging on Gitea to capture certificate principal values at authentication time.
Forward Gitea logs to a central SIEM and alert on principal strings that contain the structure of an SSH public key.
Monitor administrative changes to SSH_TRUSTED_USER_CA_KEYS and SSH_AUTHORIZED_PRINCIPALS_ALLOW in app.ini.

How to Mitigate CVE-2026-109553

Immediate Actions Required

Upgrade Gitea to version 28.2.0 or later, which contains the fix shipped in Gitea Release Tag v28.2.0.
Review all user-registered public keys and remove any entries that encode another user's key material as a principal.
Rotate SSH certificates issued by trusted certificate authorities if abuse is suspected.
Audit repository activity for unauthorized clones, pushes, or administrative changes performed through SSH or the HTTP signature API.

Patch Information

Gitea addressed the issue in version 28.2.0. Details are published in the Gitea Release Announcement 28.2.0. The patched code restricts principal resolution to designated principal keys and no longer searches arbitrary public key content.

Workarounds

Unset SSH_TRUSTED_USER_CA_KEYS to stop trusting external user certificate authorities until the upgrade is complete.
Restrict SSH_AUTHORIZED_PRINCIPALS_ALLOW to a strict allowlist such as username or email instead of anything.
Disable the built-in SSH server or the HTTP signature API if neither is required in your deployment.

bash

# Configuration example: disable trust in user CAs and restrict principals in app.ini
[ssh]
SSH_TRUSTED_USER_CA_KEYS =
SSH_AUTHORIZED_PRINCIPALS_ALLOW = username, email