CVE-2026-123002 in Gitea
Summary
by MITRE • 11/15/2026
Gitea accepted an unlimited number of wrong TOTP passcodes during sign-in, in the password reset flow and for Basic authentication with the `X-Gitea-OTP` header. An attacker who already knows an account's password could guess the six-digit passcode by trying codes at a high rate and sign in despite two-factor authentication. After five failed passcodes, further attempts for the account are now refused for 15 minutes.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified involves a critical weakness in Gitea’s implementation of Two-Factor Authentication (2FA) specifically regarding Time-based One-Time Passwords or TOTP verification during sign-in operations. This flaw affects multiple authentication pathways, including the standard password reset flow and Basic authentication mechanisms that utilize the X-Gitear-OTP header for passing the one-time passcode to the server. The core technical issue stems from a lack of effective rate limiting on the validation endpoint responsible for checking TOTP codes against the user’s secret key. In a secure system, even if an attacker possesses valid credentials such as a username and password, they should be unable to bypass the second factor without significant computational effort or time constraints. However, due to this implementation gap, an adversary who has already compromised the primary authentication credential can attempt to brute-force the six-digit numeric passcode with minimal restriction on the frequency of requests sent to the server.
From a technical perspective, TOTP codes are typically designed to be resistant to guessing attacks because they change every thirty seconds and have a limited window of validity. A standard six-digit code presents one million possible combinations. While this might seem secure against online brute-force attempts if strict rate limiting is enforced, Gitea’s previous behavior allowed an unlimited number of incorrect passcodes to be processed in rapid succession. This effectively reduces the security model from requiring possession of a physical device generating unique codes to merely guessing a static or semi-static value within a short timeframe. The attacker can script automated requests to cycle through potential codes until one matches, thereby gaining unauthorized access to the account despite the presence of two-factor authentication controls intended to prevent exactly this type of credential stuffing or brute-force attack.
The operational impact of this vulnerability is severe for any organization relying on Gitea for source code management and version control with sensitive intellectual property. An attacker who successfully guesses the TOTP code gains full administrative access equivalent to someone possessing both factors, including the ability to push malicious code, exfiltrate private repositories, or modify project settings. This undermines the fundamental purpose of multi-factor authentication, which is to add a layer of security that survives credential theft. The risk is exacerbated in environments where password reuse is common; if an attacker obtains passwords from other breaches and finds them valid on Gitea, they can easily bypass 2FA without needing physical access to the victim’s authenticator app or hardware token. This creates a significant trust deficit in the authentication infrastructure and exposes critical development assets to compromise.
To mitigate this risk, immediate action must be taken by system administrators to ensure that the software is updated to the patched version where rate limiting has been implemented. The fix introduces a mechanism that refuses further attempts for an account after five failed passcode entries, imposing a fifteen-minute lockout period. This change aligns with industry best practices outlined in CWE-307 Improper Restriction of Excessive Authentication Attempts and ATT&CK technique T1110 Brute Force. By enforcing this delay, the system significantly increases the time required for an attacker to guess all possible combinations, rendering online brute-force attacks computationally impractical within a reasonable timeframe. Organizations should also verify that their deployment configurations do not override these security defaults and consider implementing additional controls such as account lockout policies at the network perimeter or Web Application Firewall level to provide defense in depth against automated guessing tools.