Gitea EUVD-2026-41613

Exploitation requires that the target account has TOTP-based two-factor authentication enabled in Gitea and that the attacker can obtain a currently-valid TOTP code (through interception, logging, phishing relay, or shoulder-surfing) and replay it before its ~30-second time window elapses. Two code paths are affected: the interactive web two-factor authentication flow and the Basic Auth X-Gitea-OTP header path. Limiting factors: the flaw does not by itself let an attacker generate codes, so knowledge of the victim's primary password (for the login flow) plus a captured code is generally needed; the short TOTP validity window constrains the replay opportunity; and only instances running Gitea 1.5.0 through 1.26.2 with 2FA in use are affected. The CVSS UI:R reflects that a legitimate user must produce a valid code for the attacker to capture and reuse.

The published CVSS 3.1 score is 7.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N), a network, low-complexity, no-privilege vector with confidentiality high and integrity low. In practical terms the score is optimistic on complexity: capture-replay of a TOTP requires the attacker to first obtain a currently-valid code and reuse it before its short time window expires, which is closer to a real-world AC:H condition and depends on the attacker already having some path to observe the code - so PR:N is technically correct (the attacker is not authenticated) but exploitation is gated by a prerequisite the base metrics understate. There is no EPSS score, no POC, and no KEV listing provided, so no evidence of active or automated exploitation exists; this reads as a defense-in-depth weakening of 2FA rather than a directly weaponizable remote flaw. Priority is moderate: patch it as part of normal maintenance, elevated only for internet-exposed Gitea instances handling sensitive repositories. Note the conflict to verify: the vector implies easy network exploitation, but the capture-replay root cause implies the attacker must already have access to a live code - treat the raw 7.1 as an upper bound.

An attacker who can observe a victim's live TOTP code - for example by intercepting a request, reading it from a proxy or application log, or capturing it during a phishing relay - resubmits that same code to Gitea's web 2FA form or via the X-Gitea-OTP header on the Basic Auth endpoint while it is still within its validity window. Because Gitea does not reject the already-used code, the replay succeeds and the attacker completes second-factor authentication as the victim. No public POC is identified at time of analysis.