CVE-2026-73535 in Gitea
Summary
by MITRE • 10/14/2026
Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability described constitutes a critical authentication bypass within Gitea’s OpenID Connect integration mechanism, specifically affecting scenarios where multi-factor authentication is enforced for local logins but fails to extend its enforcement logic to federated identity providers. In standard security architectures, when an organization mandates Two-Factor Authentication (2FA) such as Time-based One-Time Passwords (TOTP) or WebAuthn hardware keys, these controls are intended to apply uniformly across all authentication entry points to ensure consistent risk mitigation. However, in this flawed implementation, the OpenID Connect handler accepts a user’s password and proceeds directly to link an external identity provider identifier without verifying that the secondary factor has been successfully presented. This creates a significant gap where the strength of local account security is effectively nullified for users who choose or are forced to use federated login methods.
From a technical perspective, the flaw lies in the sequence validation logic during the authentication flow. When a user initiates an OpenID Connect sign-in, the system authenticates the primary credential (the password) but skips the step that checks for active TOTP or WebAuthn enrollment and verification. Consequently, if an attacker possesses the victim’s plaintext password, they can complete the initial handshake with the identity provider. Upon successful authentication via the external provider, Gitea links this new OpenID identifier to the existing local user account. This linking process is permanent by design in many implementations but becomes dangerous here because it establishes a trusted channel that bypasses the original security controls. The attacker gains immediate access to the victim’s session and repository permissions without ever needing to interact with the second factor.
The operational impact of this vulnerability is severe, as it allows for account takeover through credential stuffing or phishing attacks where only password knowledge is required. Once the linkage is established, the attacker can subsequently sign in using solely the OpenID identifier, completely bypassing both the victim’s password and any enrolled multi-factor authentication methods. This persistence is particularly dangerous because changing the local password does not sever the link between the user account and the attacker-controlled OpenID identity. Therefore, even if the victim detects the compromise and updates their credentials, the attacker retains access through the federated channel. This undermines the fundamental principle of defense in depth, rendering multi-factor authentication ineffective for any users who utilize this specific login path.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to adequately verify identity before granting access or modifying account associations. It also relates to CWE-640, Weak Password Recovery Mechanism for Forgotten Password, in the context of how linked identities can be used to maintain persistent unauthorized access despite credential rotation efforts. From an ATT&CK perspective, this behavior facilitates Account Manipulation (T1098) by allowing attackers to add authorized credentials or identity links that persist beyond standard remediation steps like password changes. It also supports Initial Access via Valid Accounts if the attacker uses stolen credentials to establish the link, followed by Persistence through the maintained OpenID connection.
Mitigation strategies must focus on ensuring parity in security controls across all authentication methods. The primary fix involves modifying the OpenID Connect handler logic to enforce multi-factor verification before allowing any identity linking or session creation. If a user has TOTP or WebAuthn enabled at the account level, the system should require successful completion of that second factor during the federated login flow as well. Alternatively, administrators can restrict which users are allowed to link external OpenID identifiers until this patch is applied. Organizations relying on Gitea for sensitive operations should immediately audit their authentication configurations and ensure that multi-factor enforcement policies are comprehensively applied across all supported login mechanisms, including third-party identity providers. Regular monitoring of account linkage events can also help detect unauthorized associations early in the attack chain.