Common Weakness Enumeration

CWE-294

Allowed

Authentication Bypass by Capture-replay

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

444 vulnerabilities reference this CWE, most recent first.

GHSA-GX3V-Q759-G323

Vulnerability from github – Published: 2026-07-21 21:57 – Updated: 2026-07-21 21:57
VLAI
Summary
Gitea: TOTP TOCTOU race on web 2FA paths + missing replay check on Basic-Auth `X-Gitea-OTP` surface
Details

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 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 this as a follow-up to CVE-2021-45331, not a duplicate.

Vulnerable code

Defect 1 — TOCTOU race on web 2FA login

routers/web/auth/2fa.go:55-88:

54  id := idSess.(int64)
55  twofa, err := auth.GetTwoFactorByUID(ctx, id)             // (A) read row
56  ...
62  ok, err := twofa.ValidateTOTP(form.Passcode)              // (B) pure-function RFC 6238 check
...
68  if ok && twofa.LastUsedPasscode != form.Passcode {        // (C) check against in-memory copy
...
84      twofa.LastUsedPasscode = form.Passcode                 // (D) mutate in-memory
85      if err = auth.UpdateTwoFactor(ctx, twofa); err != nil {// (E) UPDATE … AllCols where id=?

Step (E) is plain db.GetEngine(ctx).ID(t.ID).AllCols().Update(t) (models/auth/twofactor.go:128-131) — no row lock, no WHERE last_used_passcode = <previous> predicate, and no DB uniqueness on (uid, last_used_passcode). The model definition at models/auth/twofactor.go:48-57 shows LastUsedPasscode string is a plain column — no constraint, no version field.

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

Surface Route Defect
Web 2FA login POST /user/two_factor (TwoFactorPost) 1 — TOCTOU race
Password-reset 2FA re-auth POST /user/password/reset (ResetPasswdPost) when twofa is set 1 — TOCTOU race
Basic-Auth API every API endpoint that accepts Basic auth with X-Gitea-OTP header (e.g. /api/v1/user, /api/v1/users/{username}/tokens) 2 — stateless replay
Git-over-HTTPS push/pull Basic-auth flow, same X-Gitea-OTP route into services/auth/basic.go:validateTOTP 2 — stateless replay

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

Required Detail
Network reach to Gitea HTTP listener Trivially available
Valid victim password Credential dump / phishing relay / separate vuln
One captured OTP value within ~90 s AiTM, infostealer log, shoulder-surf, MITM, malicious extension
Ability to fire two parallel HTTP requests Trivial (curl -P 2, xargs -P 2, HTTP/2 multiplexing) — Defect 1 only

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
Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.26.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-20779"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:57:24Z",
    "nvd_published_at": "2026-07-03T21:16:56Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nI\u0027m 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:\n\n1. **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.\n\n2. **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\u201390 s with the default `Skew=1`). This is a clean [RFC 6238 \u00a75.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.\n\nBoth defects post-date the 2018 fix; neither is referenced in any published Gitea advisory I could find. I\u0027m filing this as a **follow-up** to CVE-2021-45331, not a duplicate.\n\n### Vulnerable code\n\n#### Defect 1 \u2014 TOCTOU race on web 2FA login\n\n`routers/web/auth/2fa.go:55-88`:\n\n```go\n54  id := idSess.(int64)\n55  twofa, err := auth.GetTwoFactorByUID(ctx, id)             // (A) read row\n56  ...\n62  ok, err := twofa.ValidateTOTP(form.Passcode)              // (B) pure-function RFC 6238 check\n...\n68  if ok \u0026\u0026 twofa.LastUsedPasscode != form.Passcode {        // (C) check against in-memory copy\n...\n84      twofa.LastUsedPasscode = form.Passcode                 // (D) mutate in-memory\n85      if err = auth.UpdateTwoFactor(ctx, twofa); err != nil {// (E) UPDATE \u2026 AllCols where id=?\n```\n\nStep (E) is plain `db.GetEngine(ctx).ID(t.ID).AllCols().Update(t)` (`models/auth/twofactor.go:128-131`) \u2014 no row lock, no `WHERE last_used_passcode = \u003cprevious\u003e` predicate, and no DB uniqueness on `(uid, last_used_passcode)`. The model definition at `models/auth/twofactor.go:48-57` shows `LastUsedPasscode string` is a plain column \u2014 no constraint, no version field.\n\n#### Defect 1 \u2014 same shape, password-reset 2FA re-auth\n\n`routers/web/auth/password.go:179-196` shows the identical pattern in the password-reset flow:\n\n```go\n179  passcode := ctx.FormString(\"passcode\")\n180  ok, err := twofa.ValidateTOTP(passcode)\n...\n185  if !ok || twofa.LastUsedPasscode == passcode {           // same check-against-in-memory pattern\n...\n192  twofa.LastUsedPasscode = passcode\n193  if err = auth.UpdateTwoFactor(ctx, twofa); err != nil {\n```\n\nSame shape, same race window.\n\n#### Defect 2 \u2014 Basic-Auth API / Git-over-HTTPS (stateless replay \u2014 no check at all)\n\n`services/auth/basic.go:170-185`:\n\n```go\nfunc validateTOTP(req *http.Request, u *user_model.User) error {\n    twofa, err := auth_model.GetTwoFactorByUID(req.Context(), u.ID)\n    ...\n    if ok, err := twofa.ValidateTOTP(req.Header.Get(\"X-Gitea-OTP\")); err != nil {  // :179\n        return err\n    } else if !ok {\n        return util.NewInvalidArgumentErrorf(\"invalid provided OTP\")\n    }\n    return nil\n}\n```\n\n`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.\n\n#### Why the existing failed-login counter doesn\u0027t catch either defect\n\nGitea\u0027s `loginAttempts` counter increments on **failed** sign-ins. A successful replay is a success \u2014 the counter is never touched, and two parallel successes produce two access tokens with no anomaly logged at the auth layer.\n\n### Race-window analysis (Defect 1)\n\nInside `TwoFactorPost`, the critical region between (A) `GetTwoFactorByUID` and (E) `UpdateTwoFactor` covers:\n\n1. one DB SELECT round-trip,\n2. base64-decode + AES-decrypt of the secret (`models/auth/twofactor.go:108-118`),\n3. `totp.Validate` (HMAC-SHA1 over the secret + time-step),\n4. `user_model.GetUserByID` (a second SELECT),\n5. optional `linkAccountFromContext` / OpenID link branch,\n6. the assignment + UPDATE.\n\nOn 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 \u2014 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\u0027s session and `KeyUserHasTwoFactorAuth = true`.\n\nThe same window exists on the password-reset flow (`routers/web/auth/password.go:179-193`).\n\nDefect 2 (basic-auth) is a different shape: no race needed. Every request that supplies the correct passcode within `totp.Validate`\u0027s skew window succeeds, indefinitely, until the time-step rolls.\n\n### Reachable HTTP routes\n\n| Surface | Route | Defect |\n|---------|-------|--------|\n| Web 2FA login | `POST /user/two_factor` (`TwoFactorPost`) | 1 \u2014 TOCTOU race |\n| Password-reset 2FA re-auth | `POST /user/password/reset` (`ResetPasswdPost`) when `twofa` is set | 1 \u2014 TOCTOU race |\n| Basic-Auth API | every API endpoint that accepts Basic auth with `X-Gitea-OTP` header (e.g. `/api/v1/user`, `/api/v1/users/{username}/tokens`) | 2 \u2014 stateless replay |\n| Git-over-HTTPS push/pull | Basic-auth flow, same `X-Gitea-OTP` route into `services/auth/basic.go:validateTOTP` | 2 \u2014 stateless replay |\n\n### Proof of concept\n\nPre-conditions: attacker has the victim\u0027s 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.\n\n#### Defect 1 \u2014 Web 2FA race (parallel curl)\n\n```bash\n# Step 1 \u2014 start a 2FA-pending session (password phase).\ncurl -c jar.txt -b jar.txt -d \u0027user_name=alice\u0026password=\u003cknown\u003e\u0027 \\\n     https://gitea.example.com/user/login\n\n# Step 2 \u2014 fire two identical POSTs to /user/two_factor with the captured passcode.\nPASS=654321\n( curl -sS -c jar1.txt -b jar.txt -X POST \\\n       -d \"passcode=${PASS}\" https://gitea.example.com/user/two_factor \u0026 )\n( curl -sS -c jar2.txt -b jar.txt -X POST \\\n       -d \"passcode=${PASS}\" https://gitea.example.com/user/two_factor \u0026 )\nwait\n\n# Step 3 \u2014 both cookie jars now hold authenticated sessions for Alice.\ncurl -b jar1.txt https://gitea.example.com/user/settings  # 200\ncurl -b jar2.txt https://gitea.example.com/user/settings  # 200\n```\n\nRepeated 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 \u2014 the attacker\u0027s request only needs to arrive between the victim\u0027s (A) and the victim\u0027s (E).\n\n#### Defect 2 \u2014 Basic-Auth API replay (no race needed)\n\n```bash\n# Attacker captured Alice\u0027s password + one live OTP (654321).\n# Within the RFC 6238 window (~60\u201390 s):\ncurl -u \"alice:\u003cknown-password\u003e\" \\\n     -H \"X-Gitea-OTP: 654321\" \\\n     https://gitea.example.com/api/v1/user\n# \u2192 200 OK. Repeat as many times as the time-step allows.\n```\n\nEach 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.\n\n### Impact\n\n- **Defect 1 (Web TOCTOU).** Narrow exploit window but completely deterministic on parallel submission. The victim\u0027s own legitimate login is itself the trigger \u2014 no second observation of the OTP is needed if the attacker can race the victim\u0027s submission. Net effect: two authenticated sessions for one OTP, defeating RFC 6238 \u00a75.2 in the multi-session case.\n- **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\u201390 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.\n- **Successful-replay invisibility.** Gitea\u0027s 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 \u2014 most SIEM rules will not flag this.\n\n### Conditions for exploit\n\n| Required | Detail |\n|----------|--------|\n| Network reach to Gitea HTTP listener | Trivially available |\n| Valid victim password | Credential dump / phishing relay / separate vuln |\n| One captured OTP value within ~90 s | AiTM, infostealer log, shoulder-surf, MITM, malicious extension |\n| Ability to fire two parallel HTTP requests | Trivial (`curl -P 2`, `xargs -P 2`, HTTP/2 multiplexing) \u2014 Defect 1 only |\n\nNo special role / permission required on Gitea. Both defects are exploitable from any unauthenticated network position that can reach the listener.\n\n### Suggested remediation\n\nTwo distinct fixes are needed; option (c) collapses both into one place and is the recommended path.\n\n**(a) Race fix \u2014 compare-and-swap on UPDATE (Defect 1):**\n\n```go\n// models/auth/twofactor.go\nfunc UpdateTwoFactorCAS(ctx context.Context, t *TwoFactor, prevPasscode string) (bool, error) {\n    n, err := db.GetEngine(ctx).ID(t.ID).\n        Where(\"last_used_passcode = ?\", prevPasscode).\n        AllCols().Update(t)\n    return n == 1, err\n}\n```\n\nEach 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 \u2026 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.\n\n**(b) Basic-Auth fix (Defect 2):**\n\nWrap 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\u0027t reintroduce the race either.\n\n**(c) Preferred \u2014 store the accepted time-step counter, route every call site through one consume helper:**\n\nReplace `LastUsedPasscode string` with `LastTotpStep int64`. Derive the matching step inside `TwoFactor.ValidateTOTP` (skew-aware) and CAS on the step value:\n\n```go\nfunc (t *TwoFactor) ValidateAndConsumeTOTP(ctx context.Context, passcode string) (bool, error) {\n    step, ok, err := validateAndReturnStep(passcode, t.Secret) // skew-aware\n    if err != nil || !ok { return false, err }\n\n    n, err := db.GetEngine(ctx).Table(\"two_factor\").\n        Where(\"id = ? AND last_totp_step \u003c ?\", t.ID, step).\n        Cols(\"last_totp_step\").\n        Update(map[string]any{\"last_totp_step\": step})\n    if err != nil || n == 0 { return false, err }   // already consumed \u2014 replay refused\n    t.LastTotpStep = step\n    return true, nil\n}\n```\n\nAll 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.\n\nA schema migration is required for (c); (a)+(b) is the surgical minimum.\n\n### References\n\n- RFC 6238 \u00a75.2 \u2014 TOTP one-time use: https://datatracker.ietf.org/doc/html/rfc6238#section-5.2\n- CWE-294 \u2014 Authentication Bypass by Capture-replay: https://cwe.mitre.org/data/definitions/294.html\n- CWE-367 \u2014 Time-of-check Time-of-use (TOCTOU) Race Condition: https://cwe.mitre.org/data/definitions/367.html\n- Original Gitea fix this report builds on \u2014 CVE-2021-45331 / PR #3878 (introduced `LastUsedPasscode`): https://github.com/go-gitea/gitea/pull/3878",
  "id": "GHSA-gx3v-q759-g323",
  "modified": "2026-07-21T21:57:24Z",
  "published": "2026-07-21T21:57:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-gx3v-q759-g323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20779"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/99f8b3d9a1d32f4c39828e07971455a18191e0b9"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: TOTP TOCTOU race on web 2FA paths + missing replay check on Basic-Auth `X-Gitea-OTP` surface"
}

GHSA-H222-GCMC-VJFM

Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-05-24 17:26
VLAI
Details

A nonce reuse vulnerability exists in the ACEView service of ALEOS before 4.13.0, 4.9.5, and 4.4.9 allowing message replay. Captured traffic to the ACEView service can be replayed to other gateways sharing the same credentials.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-21T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A nonce reuse vulnerability exists in the ACEView service of ALEOS before 4.13.0, 4.9.5, and 4.4.9 allowing message replay. Captured traffic to the ACEView service can be replayed to other gateways sharing the same credentials.",
  "id": "GHSA-h222-gcmc-vjfm",
  "modified": "2022-05-24T17:26:16Z",
  "published": "2022-05-24T17:26:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11856"
    },
    {
      "type": "WEB",
      "url": "https://source.sierrawireless.com/resources/security-bulletins/sierra-wireless-technical-bulletin---swi-psa-2020-004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H4FX-378P-MCPJ

Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-06 21:31
VLAI
Details

Authentication bypass OAuth device authorization flow in Devolutions Server 2026.3.7.0 and earlier allows a remote attacker to take over a user's account via replay of a captured device verification link by an authenticated victim.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-105485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-06T19:17:40Z",
    "severity": "MODERATE"
  },
  "details": "Authentication bypass OAuth device authorization flow in Devolutions Server 2026.3.7.0 and earlier allows a remote attacker to take over a user\u0027s account via replay of a captured device verification link by an authenticated victim.",
  "id": "GHSA-h4fx-378p-mcpj",
  "modified": "2026-10-06T21:31:40Z",
  "published": "2026-10-06T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105485"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2026-0035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H7H7-F9WH-XHJ8

Vulnerability from github – Published: 2023-08-31 12:30 – Updated: 2023-11-17 06:31
VLAI
Details

VMware Tools contains a SAML token signature bypass vulnerability. A malicious actor with man-in-the-middle (MITM) network positioning between vCenter server and the virtual machine may be able to bypass SAML token signature verification, to perform VMware Tools Guest Operations.

Severity
7.5 (High)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-20900"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T10:15:08Z",
    "severity": "HIGH"
  },
  "details": "VMware Tools contains a SAML token signature bypass vulnerability.\u00a0A malicious actor with man-in-the-middle (MITM) network positioning between vCenter server and the virtual machine may be able to bypass SAML token signature verification, to perform VMware Tools Guest Operations.\n\n\n\n\n\n\n\n\n\n\n\n",
  "id": "GHSA-h7h7-f9wh-xhj8",
  "modified": "2023-11-17T06:31:20Z",
  "published": "2023-08-31T12:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20900"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NVKQ6Y2JFJRWPFOZUOTFO3H27BK5GGOG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TJNJMD67QIT6LXLKWSHFM47DCLRSMT6W"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZJM6HDRQYS74JA7YNKQBFH2XSZ52HEWH"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231013-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5493"
    },
    {
      "type": "WEB",
      "url": "https://www.vmware.com/security/advisories/VMSA-2023-0019.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/08/31/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/10/27/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H97R-55W6-6RFG

Vulnerability from github – Published: 2026-09-22 12:30 – Updated: 2026-09-22 12:30
VLAI
Details

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-87119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-22T12:17:14Z",
    "severity": "HIGH"
  },
  "details": "Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.\n\nThe payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer\u0027s wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain\u0027s own semantics for re-installing an existing key.\n\nThis issue affects mpp: from 0.14.0 before 0.16.2.",
  "id": "GHSA-h97r-55w6-6rfg",
  "modified": "2026-09-22T12:30:26Z",
  "published": "2026-09-22T12:30:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-p9fv-9w58-95x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87119"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/4b6eaec02af0e8485cfb4ff68f467d075ed5dd6f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/db464dfa9a86ccda58f0827101f6da6bd8aafa78"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-87119.html"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-87119"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H9WX-JCXV-WQP5

Vulnerability from github – Published: 2025-06-30 21:30 – Updated: 2025-06-30 21:30
VLAI
Details

Dell OpenManage Network Integration, versions prior to 3.8, contains an Authentication Bypass by Capture-replay vulnerability in the RADIUS protocol. An attacker with local network access could potentially exploit this vulnerability to forge a valid protocol accept message in response to a failed authentication request.

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-36593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-30T19:15:23Z",
    "severity": "HIGH"
  },
  "details": "Dell OpenManage Network Integration, versions prior to 3.8, contains an Authentication Bypass by Capture-replay vulnerability in the RADIUS protocol.  An attacker with local network access could potentially exploit this vulnerability to forge a valid protocol accept message in response to a failed authentication request.",
  "id": "GHSA-h9wx-jcxv-wqp5",
  "modified": "2025-06-30T21:30:52Z",
  "published": "2025-06-30T21:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36593"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000337238/dsa-2025-257-security-update-for-dell-openmanage-network-integration-omni-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HCPX-V556-CH6P

Vulnerability from github – Published: 2024-11-07 18:31 – Updated: 2024-11-07 18:31
VLAI
Details

A vulnerability in Veeam Backup & Replication Enterprise Manager has been identified, which allows attackers to perform authentication bypass. Attackers must be able to perform Man-in-the-Middle (MITM) attack to exploit this vulnerability.

Severity
7.7 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-40715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-07T17:15:08Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Veeam Backup \u0026 Replication Enterprise Manager has been identified, which allows attackers to perform authentication bypass. Attackers must be able to perform Man-in-the-Middle (MITM) attack to exploit this vulnerability.",
  "id": "GHSA-hcpx-v556-ch6p",
  "modified": "2024-11-07T18:31:23Z",
  "published": "2024-11-07T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40715"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4682"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HF79-3HFM-MGMR

Vulnerability from github – Published: 2024-01-23 21:30 – Updated: 2024-01-29 21:30
VLAI
Details

The radio frequency communication protocol being used by Meross MSH30Q 4.5.23 is vulnerable to replay attacks, allowing attackers to record and replay previously captured communication to execute unauthorized commands or actions (e.g., thermostat's temperature).

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-46892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-23T21:15:08Z",
    "severity": "HIGH"
  },
  "details": "The radio frequency communication protocol being used by Meross MSH30Q 4.5.23 is vulnerable to replay attacks, allowing attackers to record and replay previously captured communication to execute unauthorized commands or actions (e.g., thermostat\u0027s temperature).",
  "id": "GHSA-hf79-3hfm-mgmr",
  "modified": "2024-01-29T21:30:27Z",
  "published": "2024-01-23T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46892"
    },
    {
      "type": "WEB",
      "url": "https://www.kth.se/cs/nse/research/software-systems-architecture-and-security/projects/ethical-hacking-1.1279219"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HHC4-5Q24-RM38

Vulnerability from github – Published: 2022-11-14 12:00 – Updated: 2022-11-16 19:00
VLAI
Details

Xiongmai Camera XM-JPR2-LX V4.02.R12.A6420987.10002.147502.00000 is vulnerable to account takeover.

Severity
7.5 (High)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-38827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-14T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "Xiongmai Camera XM-JPR2-LX V4.02.R12.A6420987.10002.147502.00000 is vulnerable to account takeover.",
  "id": "GHSA-hhc4-5q24-rm38",
  "modified": "2022-11-16T19:00:25Z",
  "published": "2022-11-14T12:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38827"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChandlerChin/XiongmaiCamera/blob/main/Account%20takeover%20with%20traffic%20monitoring%20exploitation%20in%20XM-JPR2-LX%20device.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HHQ4-97C2-P447

Vulnerability from github – Published: 2026-04-02 20:59 – Updated: 2026-05-06 02:40
VLAI
Summary
OpenClaw: Zalo webhook replay cache cross-target messageId scope bypass
Details

Summary

Zalo webhook replay cache cross-target messageId scope bypass

Current Maintainer Triage

  • Status: narrow
  • Normalized severity: low
  • Assessment: v2026.3.28 replay dedupe is still keyed too broadly, but the issue should stay scoped to authenticated sibling-target delivery paths rather than arbitrary unauthenticated attackers.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 4d038bb242c11f39e45f6a4bde400e5fd42e4ebf — 2026-03-31T19:33:57+09:00

Release Process Note

  • The fix is already present in released version 2026.3.31.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @smaeljaish771 for reporting.

Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T20:59:11Z",
    "nvd_published_at": "2026-04-28T19:37:43Z",
    "severity": "LOW"
  },
  "details": "## Summary\nZalo webhook replay cache cross-target messageId scope bypass\n\n## Current Maintainer Triage\n- Status: narrow\n- Normalized severity: low\n- Assessment: v2026.3.28 replay dedupe is still keyed too broadly, but the issue should stay scoped to authenticated sibling-target delivery paths rather than arbitrary unauthenticated attackers.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `4d038bb242c11f39e45f6a4bde400e5fd42e4ebf` \u2014 2026-03-31T19:33:57+09:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @smaeljaish771 for reporting.",
  "id": "GHSA-hhq4-97c2-p447",
  "modified": "2026-05-06T02:40:21Z",
  "published": "2026-04-02T20:59:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hhq4-97c2-p447"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41402"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4d038bb242c11f39e45f6a4bde400e5fd42e4ebf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-webhook-replay-cache-cross-target-messageid-scope-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Zalo webhook replay cache cross-target messageId scope bypass"
}
Mitigation
Architecture and Design

Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.

Mitigation
Architecture and Design

Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-701: Browser in the Middle (BiTM)

An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list