CVE-2026-20779: Gitea TOTP Reuse Vulnerability (2FA Bypass)

Technical summary

CVE-2026-20779 is a TOTP enforcement defect in Gitea's authentication layer. The vulnerability stems from a logic flaw in how the application validates one-time passwords during web-based 2FA flows and the Basic Authentication header path (X-Gitea-OTP). Instead of generating a one-time password enforcement state that persists across authentication attempts, the system accepts the same TOTP code multiple times within its validity window. The issue spans both the primary web interface and the API authentication mechanism, meaning an attacker can use a single intercepted or observed TOTP code to authenticate as the target user through either pathway. The underlying weakness is classified under CWE-294 (Authentication Using a Known Password), reflecting that the 2FA control fails to enforce non-reusability.

Business impact

Self-hosted Gitea instances serve as critical version control and collaboration platforms for many organizations. If a threat actor gains knowledge of a valid TOTP code through interception or observation, they can authenticate as the compromised user without needing the original password or subsequent valid codes. This undermines the security posture of organizations relying on Gitea for code repository access, potentially enabling unauthorized code commits, repository tampering, secret exfiltration, or supply chain attacks. For development teams and enterprises using Gitea internally, this vulnerability directly increases account takeover risk and reduces the protective value of 2FA deployments.

Affected systems

Gitea versions 1.5.0 through 1.26.2 are vulnerable. Organizations running Gitea should determine their deployed version immediately. The issue does not affect Gitea 1.26.3 or later. Self-hosted instances are the primary exposure vector; SaaS offerings managed by third parties depend on the specific version the provider runs.

Exploitability

The vulnerability requires user interaction (UI/R in the CVSS vector) in the sense that an attacker must obtain a valid TOTP code, but exploitation itself is straightforward once a code is acquired. No authentication or special privileges are required—any attacker with access to a valid code can authenticate. The attack surface is broad because TOTP codes can be captured through phishing, network sniffing on unencrypted channels, device compromise, or social engineering. The network-accessible nature of Gitea instances (AV:N) and low attack complexity (AC:L) make this practical for remote attackers.

Remediation

Upgrade affected Gitea instances to version 1.26.3 or later as soon as feasible. The patch corrects the TOTP validation logic to enforce true single-use semantics. Prior to patching, organizations should monitor for suspicious authentication patterns, particularly multiple successful logins using the same TOTP window, and consider temporarily restricting Gitea access to trusted networks or IP ranges if operational constraints allow.

Patch guidance

Gitea administrators should consult the official Gitea release notes and security advisories to confirm patch availability and compatibility with their current deployment. Version 1.26.3 and subsequent releases incorporate the fix. Test the upgrade in a non-production environment first to validate compatibility with custom configurations or integrations. Deployment method (Docker, binary, package manager) will influence the specific upgrade procedure; follow the method appropriate to your installation.

Detection guidance

Monitor authentication logs for repeated successful TOTP authentications from the same user within short time intervals or from disparate IP addresses using the same TOTP timestamp. Implement alerting if a TOTP code successfully authenticates more than once. Audit API access logs (specifically requests bearing the X-Gitea-OTP header) alongside web login logs to correlate unusual patterns. Check for unexpected commits, repository modifications, or administrative actions by user accounts, which may indicate account compromise. Organizations with centralized logging should correlate Gitea logs with endpoint detection and response (EDR) telemetry to identify secondary indicators of compromise.

Why prioritize this

This vulnerability rates HIGH (CVSS 7.1) because it directly degrades a fundamental security control—two-factor authentication—affecting confidentiality and integrity. The network-accessible nature, absence of special privileges, and broad applicability across Gitea user bases make prioritization essential. However, it is not CRITICAL because authentication still requires a valid TOTP code (an attacker cannot authenticate without one), and the impact is limited to a single user's account per compromised code, not systemic code execution or data availability loss. Organizations should patch within days, not weeks.

Risk score, explained

The CVSS 3.1 score of 7.1 reflects: (1) Network-accessible vector (AV:N)—Gitea is typically internet-facing; (2) Low attack complexity (AC:L)—exploiting the flaw requires no special setup beyond obtaining a code; (3) No privileges required (PR:N)—any attacker with a valid code can authenticate; (4) User interaction (UI:R)—an attacker must acquire a TOTP code through observation or interception; (5) High confidentiality impact (C:H)—a compromised account grants access to potentially sensitive repositories; (6) Low integrity impact (I:L)—the attacker can modify repositories but impact is scoped to a single account; (7) No availability impact (A:N)—the vulnerability does not degrade system availability. The score appropriately reflects a serious authentication bypass that is neither the most severe nor trivial in the vulnerability landscape.

Frequently asked questions