Gitea versions from 1.5.0 before 1.26.3 have a TOTP single-use enforcement defect that allows a valid TOTP code to be accepted more than once across web two-factor authentication flows and the Basic Auth X-Gitea-OTP path.

Affected: Go: code.gitea.io/gitea

### Summary

I'm reporting **two related TOTP one-time-use defects** in Gitea that survive the CVE-2021-45331 fix. The 2018 fix (PR #3878) introduced the `TwoFactor.LastUsedPasscode` field and added an in-memory inequality check on the web 2FA login path. That check works correctly in the single-request case, but it leaves two follow-up gaps:

1. **A TOCTOU race on the web surfaces (Defect 1).** The read-validate-check-save sequence against the `two_factor` row is not atomic. Two parallel submissions of the same passcode each load their own in-memory copy where `LastUsedPasscode` still holds the prior value; both pass the inequality check, both authenticate, and both then write the same new value back. Net effect: the same OTP redeems for two independent logged-in sessions.

2. **No `LastUsedPasscode` check at all on the Basic-Auth API surface (Defect 2).** `services/auth/basic.go` calls `twofa.ValidateTOTP(...)` for `X-Gitea-OTP` without ever reading or writing `LastUsedPasscode`. The same six-digit code is replayable for the full `totp.Validate` acceptance window (~60–90 s with the default `Skew=1`). This is a clean [RFC 6238 §5.2](https://datatracker.ietf.org/doc/html/rfc6238#section-5.2) violation independent of timing, shaped identically to the pre-CVE-2021-45331 behaviour but scoped to the API / Git-over-HTTPS basic-auth path instead of the web form.

Both defects post-date the 2018 fix; neither is referenced in any published Gitea advisory I could find. I'm filing thi…

Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um erweiterte Berechtigungen zu erlangen, sich als Benutzer auszugeben, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.