CVE-2026-109553 in Gitea
Summary
by MITRE • 10/18/2026
Gitea resolved the principals of an SSH certificate by searching the content of all stored public keys instead of only principal keys. When Gitea trusts a user certificate authority (`SSH_TRUSTED_USER_CA_KEYS`) and accepts arbitrary principals (`SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything`), a user could register another user's public key line as their own principal, or a holder of a certificate signed by that authority could list it, and then authenticate as the owner of that key through the HTTP signature API and the built-in SSH server. Instances that do not trust a user certificate authority are not affected.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Gitea represents a critical authentication bypass flaw rooted in the improper validation logic for SSH certificates, specifically when interacting with trusted User Certificate Authorities. In secure systems utilizing SSH public key infrastructure, there is a distinct separation between keys used to authenticate identity (principal keys) and those used solely to verify signatures from a Certificate Authority. The core technical failure lies in Gitea's implementation of principal resolution, where the system erroneously searches through all stored public keys rather than restricting this lookup exclusively to designated principal keys. This architectural oversight creates a scenario where the boundary between authentication credentials and verification material is blurred, allowing an attacker to exploit the trust relationship established by the SSH_TRUSTED_USER_CA_KEYS configuration parameter.
When Gitea is configured to trust a specific user certificate authority and accepts arbitrary principals via the SSH_AUTHORIZED_PRINCIPALS_ALLOW setting set to anything, the security model collapses. An adversary can register another user's public key line as their own principal within the system. By doing so, they create a linkage that allows them to leverage certificates signed by the trusted CA. Since the validation logic incorrectly checks all stored keys against the certificate principals rather than just the authorized principal keys, an attacker holding a valid certificate signed by the trusted authority can list this manipulated entry and subsequently authenticate as the owner of that key. This mechanism effectively permits identity spoofing across different user accounts within the Gitea instance.
The operational impact of this vulnerability is severe, particularly for instances where SSH authentication is enabled alongside HTTP signature API access. An attacker who successfully exploits this flaw gains the ability to impersonate other users by authenticating through both the built-in SSH server and the HTTP signature API. This capability undermines the fundamental integrity of user identity within the platform, potentially leading to unauthorized code commits, repository modifications, or administrative actions depending on the privileges associated with the targeted account. The risk is compounded in environments where automated systems rely on these authentication methods for continuous integration or deployment pipelines, as a compromised service account could be used to inject malicious code into trusted repositories.
Mitigation strategies must focus on correcting the validation logic and tightening configuration parameters. Developers should ensure that Gitea strictly limits principal resolution searches to only those keys explicitly designated as authorized principals, thereby enforcing the necessary separation between authentication credentials and CA verification material. For administrators unable to immediately apply a patch, it is crucial to review instance configurations; specifically, ensuring that SSH_TRUSTED_USER_CA_KEYS is not configured with overly permissive settings or removing the use of arbitrary principal allowances unless absolutely required by specific operational needs. Additionally, implementing strict access controls on who can register public keys and principals within user profiles adds an essential layer of defense against this type of identity manipulation.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to correctly verify the identity of users attempting to gain access. It also relates to CWE-640 Weak Key Implementation in the context of logical key management and validation processes. In terms of attack vectors, this flaw facilitates lateral movement within a compromised environment by allowing an attacker to pivot from one user account to another using valid cryptographic credentials, which corresponds to techniques found in the MITRE ATT&CK framework related to credential access and privilege escalation through identity spoofing. Addressing these logical flaws is essential for maintaining the trust model inherent in SSH-based authentication systems integrated with web applications like Gitea.