CWE-294

{
  "affected": [],
  "aliases": [
    "CVE-2019-20626"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-23T17:15:00Z",
    "severity": "LOW"
  },
  "details": "The remote keyless system on Honda HR-V 2017 vehicles sends the same RF signal for each door-open request, which might allow a replay attack.",
  "id": "GHSA-gmw6-384q-c4pf",
  "modified": "2022-05-24T17:12:09Z",
  "published": "2022-05-24T17:12:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20626"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HackingIntoYourHeart/Unoriginal-Rice-Patty"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@victor_14768/replay-attacks-en-autos-206481dcfee1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-20123"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-05T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the offline access mode of Cisco Duo Two-Factor Authentication for macOS and Duo Authentication for Windows Logon and RDP could allow an unauthenticated, physical attacker to replay valid user session credentials and gain unauthorized access to an affected macOS or Windows device. This vulnerability exists because session credentials do not properly expire. An attacker could exploit this vulnerability by replaying previously used multifactor authentication (MFA) codes to bypass MFA protection. A successful exploit could allow the attacker to gain unauthorized access to the affected device.",
  "id": "GHSA-gp8j-qw75-8q9q",
  "modified": "2023-04-12T21:30:22Z",
  "published": "2023-04-05T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20123"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-duo-replay-knuNKd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe attacker, with one captured signed SOAP envelope from a victim and no other privileges, can invoke arbitrary operations on the service as the victim principal for the lifetime of the captured signing key. There is no rate limit on replays. The DetectReplays setting on transport-security bindings does not mitigate the issue because the attack does not reuse the original timestamp \u2014 the fresh timestamp in the wsse:Security header is what the replay-detection logic inspects.\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nEnsure communication is protected by SSL/TLS to prevent capturing of signed SOAP envelope.",
  "id": "GHSA-gqv6-pwcg-87r8",
  "modified": "2026-06-19T20:47:14Z",
  "published": "2026-06-19T20:47:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-gqv6-pwcg-87r8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/CoreWCF/CoreWCF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CoreWCF: XML Signature Wrapping in WS-Security endorsing/supporting signature verification allows replay of captured signed messages"
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-35551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-18T09:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered on Samsung mobile devices with O(8.x), P(9.0), and Q(10.0) (Exynos chipsets) software. They allow attackers to conduct RPMB state-change attacks because an unauthorized RPMB write operation can be replayed, a related issue to CVE-2020-13799. The Samsung ID is SVE-2020-18100 (December 2020).",
  "id": "GHSA-gv37-4vjv-96xm",
  "modified": "2022-05-24T17:36:56Z",
  "published": "2022-05-24T17:36:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35551"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-29475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-25T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An information disclosure vulnerability exists in the XFINDER functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
  "id": "GHSA-gvc3-rhv6-6x2c",
  "modified": "2022-10-26T19:00:39Z",
  "published": "2022-10-25T19:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29475"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1553"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-34151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-04T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use of hard-coded credentials vulnerability exists in Machine automation controller NJ series all models V 1.48 and earlier, Machine automation controller NX7 series all models V1.28 and earlier, Machine automation controller NX1 series all models V1.48 and earlier, Automation software \u0027Sysmac Studio\u0027 all models V1.49 and earlier, and Programmable Terminal (PT) NA series NA5-15W/NA5-12W/NA5-9W/NA5-7W models Runtime V1.15 and earlier, which may allow a remote attacker who successfully obtained the user credentials by analyzing the affected product to access the controller.",
  "id": "GHSA-gx2r-v5m4-v5qp",
  "modified": "2022-07-16T00:00:27Z",
  "published": "2022-07-05T00:00:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34151"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU97050784/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.ia.omron.com/product/vulnerability/OMSR-2022-001_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "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"
}

{
  "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": []
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}