Gitea: TOTP TOCTOU race on web 2FA paths + missing replay check on Basic-Auth `X-Gitea-OTP` surface

Defect 1 — same shape, password-reset 2FA re-auth

routers/web/auth/password.go:179-196 shows the identical pattern in the password-reset flow:

179  passcode := ctx.FormString("passcode")
180  ok, err := twofa.ValidateTOTP(passcode)
...
185  if !ok || twofa.LastUsedPasscode == passcode {           // same check-against-in-memory pattern
...
192  twofa.LastUsedPasscode = passcode
193  if err = auth.UpdateTwoFactor(ctx, twofa); err != nil {

Same shape, same race window.

Defect 2 — Basic-Auth API / Git-over-HTTPS (stateless replay — no check at all)

services/auth/basic.go:170-185:

func validateTOTP(req *http.Request, u *user_model.User) error {
    twofa, err := auth_model.GetTwoFactorByUID(req.Context(), u.ID)
    ...
    if ok, err := twofa.ValidateTOTP(req.Header.Get("X-Gitea-OTP")); err != nil {  // :179
        return err
    } else if !ok {
        return util.NewInvalidArgumentErrorf("invalid provided OTP")
    }
    return nil
}

LastUsedPasscode is neither read nor written on this path. The same six-digit code in X-Gitea-OTP succeeds for the full totp.Validate acceptance window on every request.

Why the existing failed-login counter doesn't catch either defect

Gitea's loginAttempts counter increments on failed sign-ins. A successful replay is a success — the counter is never touched, and two parallel successes produce two access tokens with no anomaly logged at the auth layer.

Race-window analysis (Defect 1)

Inside TwoFactorPost, the critical region between (A) GetTwoFactorByUID and (E) UpdateTwoFactor covers:

1. one DB SELECT round-trip,
2. base64-decode + AES-decrypt of the secret (models/auth/twofactor.go:108-118),
3. totp.Validate (HMAC-SHA1 over the secret + time-step),
4. user_model.GetUserByID (a second SELECT),
5. optional linkAccountFromContext / OpenID link branch,
6. the assignment + UPDATE.

On a non-CPU-bound deployment this window is a few milliseconds on the fast path, tens of ms when linkAccount / OpenID branches are taken. An attacker who already holds both factors and can submit two POST /user/two_factor requests in parallel (HTTP/2 multiplexing, or two backgrounded curls) hits the race reliably — both goroutines enter step (C) with the same stale LastUsedPasscode, both reach step (D), both write the new value back. The two responses each set the user's session and KeyUserHasTwoFactorAuth = true.

The same window exists on the password-reset flow (routers/web/auth/password.go:179-193).

Defect 2 (basic-auth) is a different shape: no race needed. Every request that supplies the correct passcode within totp.Validate's skew window succeeds, indefinitely, until the time-step rolls.

Reachable HTTP routes

Proof of concept

Pre-conditions: attacker has the victim's password (credential dump, phish, separate vuln) and one live TOTP value within the RFC 6238 window (AiTM relay such as Evilginx2, malicious browser extension, infostealer log, shoulder-surf). Network reach to the Gitea HTTP listener.

Defect 1 — Web 2FA race (parallel curl)

# Step 1 — start a 2FA-pending session (password phase).
curl -c jar.txt -b jar.txt -d 'user_name=alice&password=<known>' \
     https://gitea.example.com/user/login

# Step 2 — fire two identical POSTs to /user/two_factor with the captured passcode.
PASS=654321
( curl -sS -c jar1.txt -b jar.txt -X POST \
       -d "passcode=${PASS}" https://gitea.example.com/user/two_factor & )
( curl -sS -c jar2.txt -b jar.txt -X POST \
       -d "passcode=${PASS}" https://gitea.example.com/user/two_factor & )
wait

# Step 3 — both cookie jars now hold authenticated sessions for Alice.
curl -b jar1.txt https://gitea.example.com/user/settings  # 200
curl -b jar2.txt https://gitea.example.com/user/settings  # 200

Repeated trials succeed often enough to be exploitable; a kit firing N=5 parallel attempts hits the race on virtually every iteration. Note that the legitimate browser tab counts as one of the racers — the attacker's request only needs to arrive between the victim's (A) and the victim's (E).

Defect 2 — Basic-Auth API replay (no race needed)

# Attacker captured Alice's password + one live OTP (654321).
# Within the RFC 6238 window (~60–90 s):
curl -u "alice:<known-password>" \
     -H "X-Gitea-OTP: 654321" \
     https://gitea.example.com/api/v1/user
# → 200 OK. Repeat as many times as the time-step allows.

Each call succeeds. An attacker can mint a personal access token via POST /api/v1/users/{username}/tokens inside that window for long-lived access that outlives the captured OTP.

Impact

• Defect 1 (Web TOCTOU). Narrow exploit window but completely deterministic on parallel submission. The victim's own legitimate login is itself the trigger — no second observation of the OTP is needed if the attacker can race the victim's submission. Net effect: two authenticated sessions for one OTP, defeating RFC 6238 §5.2 in the multi-session case.
• Defect 2 (Basic-Auth stateless replay). The more serious of the two. Any captured OTP value remains valid on the API / git-clone basic-auth surface for the full totp.Validate window. An attacker who AiTM-relays one login can carve out 60–90 s of unattended API access during which they can mint a personal access token and persist past the OTP window. This surface specifically attracts attackers because (a) it is non-interactive (a script can hammer it), and (b) PAT minting via /api/v1/users/{username}/tokens does not require a second 2FA prompt once basic-auth + OTP have succeeded.
• Successful-replay invisibility. Gitea's failed-login counter increments on FailedLoginException; a successful replay never throws. The audit log records two successful 2FA authentications for the same principal at near-identical timestamps — most SIEM rules will not flag this.

Conditions for exploit

No special role / permission required on Gitea. Both defects are exploitable from any unauthenticated network position that can reach the listener.

Suggested remediation

Two distinct fixes are needed; option (c) collapses both into one place and is the recommended path.

(a) Race fix — compare-and-swap on UPDATE (Defect 1):

// models/auth/twofactor.go
func UpdateTwoFactorCAS(ctx context.Context, t *TwoFactor, prevPasscode string) (bool, error) {
    n, err := db.GetEngine(ctx).ID(t.ID).
        Where("last_used_passcode = ?", prevPasscode).
        AllCols().Update(t)
    return n == 1, err
}

Each handler captures prev := twofa.LastUsedPasscode before mutating, calls UpdateTwoFactorCAS(ctx, twofa, prev), and rejects the request if n != 1. Fixes both web sites with no extra lock contention. A row-level lock (SELECT … FOR UPDATE inside a db.WithTx) is an equivalent surgical option. Equivalent atomicity can also be obtained by a unique index on (twofa_id, last_used_passcode) so a duplicate UPDATE collides at the DB layer.

(b) Basic-Auth fix (Defect 2):

Wrap the twofa.ValidateTOTP(...) call at services/auth/basic.go:179 in the same inequality check + update pattern used in routers/web/auth/2fa.go:68,84-85, ideally via the CAS helper above so the basic-auth path can't reintroduce the race either.

(c) Preferred — store the accepted time-step counter, route every call site through one consume helper:

Replace LastUsedPasscode string with LastTotpStep int64. Derive the matching step inside TwoFactor.ValidateTOTP (skew-aware) and CAS on the step value:

func (t *TwoFactor) ValidateAndConsumeTOTP(ctx context.Context, passcode string) (bool, error) {
    step, ok, err := validateAndReturnStep(passcode, t.Secret) // skew-aware
    if err != nil || !ok { return false, err }

    n, err := db.GetEngine(ctx).Table("two_factor").
        Where("id = ? AND last_totp_step < ?", t.ID, step).
        Cols("last_totp_step").
        Update(map[string]any{"last_totp_step": step})
    if err != nil || n == 0 { return false, err }   // already consumed — replay refused
    t.LastTotpStep = step
    return true, nil
}

All three call sites (routers/web/auth/2fa.go, routers/web/auth/password.go, services/auth/basic.go) then go through this single function and cannot accidentally skip the consume step. Same fix shape as django-otp (last_t) and Authentik (authentik/stages/authenticator_totp/models.py:184). Recommended option because it makes the defect impossible to reintroduce at a future call site.

A schema migration is required for (c); (a)+(b) is the surgical minimum.

References

• RFC 6238 §5.2 — TOTP one-time use: https://datatracker.ietf.org/doc/html/rfc6238#section-5.2
• CWE-294 — Authentication Bypass by Capture-replay: https://cwe.mitre.org/data/definitions/294.html
• CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition: https://cwe.mitre.org/data/definitions/367.html
• Original Gitea fix this report builds on — CVE-2021-45331 / PR #3878 (introduced LastUsedPasscode): https://github.com/go-gitea/gitea/pull/3878