CWE-294
AllowedAuthentication Bypass by Capture-replay
Abstraction: Base · Status: Incomplete
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).
342 vulnerabilities reference this CWE, most recent first.
GHSA-2VPV-3C94-J6HF
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50oBike relies on Hangzhou Luoping Smart Locker to lock bicycles, which allows attackers to bypass the locking mechanism by using Bluetooth Low Energy (BLE) to replay ciphertext based on a predictable nonce used in the locking protocol.
{
"affected": [],
"aliases": [
"CVE-2018-16242"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-14T21:29:00Z",
"severity": "MODERATE"
},
"details": "oBike relies on Hangzhou Luoping Smart Locker to lock bicycles, which allows attackers to bypass the locking mechanism by using Bluetooth Low Energy (BLE) to replay ciphertext based on a predictable nonce used in the locking protocol.",
"id": "GHSA-2vpv-3c94-j6hf",
"modified": "2022-05-13T01:50:19Z",
"published": "2022-05-13T01:50:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16242"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2018/Sep/30"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2XJH-35WJ-VW46
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42Skype for Business in Microsoft Lync 2013 SP1 and Skype for Business 2016 allows an attacker to steal an authentication hash that can be reused elsewhere, due to how Skype for Business handles authentication requests, aka "Skype for Business Elevation of Privilege Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2017-11786"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-13T13:29:00Z",
"severity": "HIGH"
},
"details": "Skype for Business in Microsoft Lync 2013 SP1 and Skype for Business 2016 allows an attacker to steal an authentication hash that can be reused elsewhere, due to how Skype for Business handles authentication requests, aka \"Skype for Business Elevation of Privilege Vulnerability.\"",
"id": "GHSA-2xjh-35wj-vw46",
"modified": "2022-05-13T01:42:33Z",
"published": "2022-05-13T01:42:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11786"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11786"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101156"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039530"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-35W3-6QHC-474V
Vulnerability from github – Published: 2024-03-29 20:16 – Updated: 2024-03-29 20:16Impact
A user can reuse an expired session by controlling the x-workos-session header.
Patches
Patched in https://github.com/workos/authkit-nextjs/releases/tag/v0.4.2
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@workos-inc/authkit-nextjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-29901"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-29T20:16:00Z",
"nvd_published_at": "2024-03-29T16:15:08Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA user can reuse an expired session by controlling the `x-workos-session` header.\n\n### Patches\n\nPatched in https://github.com/workos/authkit-nextjs/releases/tag/v0.4.2",
"id": "GHSA-35w3-6qhc-474v",
"modified": "2024-03-29T20:16:00Z",
"published": "2024-03-29T20:16:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/security/advisories/GHSA-35w3-6qhc-474v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29901"
},
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/commit/6c3f4f3179d66cbb15de3962792083ff3b244a01"
},
{
"type": "PACKAGE",
"url": "https://github.com/workos/authkit-nextjs"
},
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/releases/tag/v0.4.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "@workos-inc/authkit-nextjs session replay vulnerability"
}
GHSA-37V6-FXX8-XJMX
Vulnerability from github – Published: 2026-04-03 02:58 – Updated: 2026-05-06 23:25Summary
Telnyx Webhook Replay Detection Bypass via Base64 Signature Re-encoding
Current Maintainer Triage
- Status: narrow
- Normalized severity: low
- Assessment: Shipped v2026.3.28 replay hashing treated equivalent Telnyx Base64/Base64URL signatures as distinct requests, but signature verification still held, so lower to low.
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)
ad77666054651c1fd77b1dc60fd6a8db6600a29a— 2026-03-30T20:01:43+01: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.
OpenClaw thanks @AntAISecurityLab for reporting.
{
"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-41351"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T02:58:17Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nTelnyx Webhook Replay Detection Bypass via Base64 Signature Re-encoding\n\n## Current Maintainer Triage\n- Status: narrow\n- Normalized severity: low\n- Assessment: Shipped v2026.3.28 replay hashing treated equivalent Telnyx Base64/Base64URL signatures as distinct requests, but signature verification still held, so lower to low.\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- `ad77666054651c1fd77b1dc60fd6a8db6600a29a` \u2014 2026-03-30T20:01:43+01: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\nOpenClaw thanks @AntAISecurityLab for reporting.",
"id": "GHSA-37v6-fxx8-xjmx",
"modified": "2026-05-06T23:25:13Z",
"published": "2026-04-03T02:58:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-37v6-fxx8-xjmx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41351"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/ad77666054651c1fd77b1dc60fd6a8db6600a29a"
},
{
"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-detection-bypass-via-base64-signature-re-encoding"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Telnyx Webhook Replay Detection Bypass via Base64 Signature Re-encoding"
}
GHSA-392P-2Q2V-4372
Vulnerability from github – Published: 2026-07-07 20:55 – Updated: 2026-07-07 20:55Am I affected?
Users are affected if all of the following are true:
- Their project depends on
@better-auth/oauth-providerat a version>= 1.6.0, < 1.6.11, or uses the embedded plugin inbetter-auth >= 1.4.8-beta.7, < 1.6.0. - At least one OAuth client served by their application's authorization server requests the
offline_accessscope, so refresh tokens are minted. - Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refresh token times two requests, or a service worker queues offline requests.
If developer applications do not request offline_access for any client, no refresh tokens are minted and they are not exposed.
Fix:
- Upgrade to
@better-auth/oauth-provider@1.6.11or later. - If developers cannot upgrade, see workarounds below.
Summary
The OAuth provider's POST /oauth2/token endpoint, on the refresh_token grant, performs a non-atomic read / validate / revoke / mint sequence on the oauthRefreshToken row. Two concurrent requests presenting the same parent refresh token both pass the revocation check before either revoke completes, so each mints a fresh refresh token. The replay-detection branch only fires when revoked is already truthy at read time, which is exactly the state concurrent attackers race past. The result is a forked refresh-token family from a single parent token.
Details
The adapter.update predicate on the parent row is keyed on id only; it does not include revoked IS NULL, so two concurrent updates both succeed (last-write-wins, no error path). The schema does not declare unique on oauthRefreshToken.token, so concurrent creates do not collide on a unique-key violation either.
RFC 9700 §4.14 (OAuth Security Best Current Practice) prescribes refresh-token family invalidation on detected reuse; this implementation tries to enforce that contract through the revoked check, but the check is not atomic with the consumption step. Token rotation issues a new refresh token with each call, so a single stolen refresh token grants indefinite access until the row is revoked or its refreshTokenExpiresAt (default 7 days) passes. Rotation refreshes that window each call.
The fix lands an atomic compare-and-swap on the parent row inside the rotation primitive (UPDATE ... WHERE id = ? AND revoked IS NULL with a rowcount check), so the losing rotation fails closed with invalid_grant and the parent row stays marked revoked. Subsequent replay of the original refresh token then trips the existing family-invalidation guard. The schema gains a unique constraint on oauthRefreshToken.token for parity with oauthAccessToken.token.
Patches
Fixed in @better-auth/oauth-provider@1.6.11. The refresh-token rotation primitive now performs an atomic compare-and-swap on the parent row, and the explicit revokeRefreshToken path uses the same CAS. On a contested rotation, exactly one caller wins and mints a fresh refresh token; the loser receives invalid_grant. Subsequent replay of the original refresh token trips the existing family-invalidation guard because the parent row stays marked revoked.
@better-auth/memory-adapter@1.6.11 ships a compatibility fix in the same wave: the in-memory where clause now treats undefined and null as equivalent under an eq null predicate, mirroring SQL IS NULL and Mongo's missing-or-null semantics. Without this change, the CAS predicate WHERE revoked IS NULL falls through on every call against a row whose optional revoked field is absent (the adapter factory's transformInput skips writing undefined when no default exists), so the rotation above is broken for any deployment using the in-memory adapter.
Strict refresh-token family invalidation on a contested rotation, per RFC 9700 §4.14 (which calls for invalidating the winner's tokens too when reuse is detected at rotation time), is deferred to a follow-up minor on the next channel. Closing it cleanly requires an opt-in transactional rotation in the adapter contract so the family-delete cannot interleave with the winner's in-flight access-token insert. The deferred site carries a FIXME(strict-family-invalidation) marker.
Schema-migration note: the better-auth migration generator only emits UNIQUE for newly-created columns. Existing installs will not pick up the new oauthRefreshToken.token unique constraint from migrate / generate; add it manually if an application's operational tooling depends on it (CREATE UNIQUE INDEX oauth_refresh_token_token_uniq ON "oauthRefreshToken" (token);). The CAS fix above does not depend on the database-level constraint to be correct; the constraint is defense-in-depth so collisions from a buggy custom generateRefreshToken callback fail loudly.
Workarounds
None of these close the bug fully without a code patch.
- Adapter-level: configure the database adapter to run the OAuth refresh handler under serializable isolation, or wrap the
adapter.updateonoauthRefreshTokenwith a row-level pessimistic lock (SELECT ... FOR UPDATE). Narrows the window without closing it. - Token lifetime: pass
oauthProvider({ refreshTokenExpiresIn: 60 })to expire forked families within one minute. Trades attacker persistence for shorter user sessions. - Client-side single-flight: serialize refresh-token usage in the client SDK with a mutex. Mitigates honest concurrency but does nothing against an attacker with a stolen refresh token.
- Disable refresh tokens: do not request the
offline_accessscope. Closes the surface but breaks long-lived sessions.
Impact
- Indefinite access from a single stolen refresh token: forked refresh-token families grant access at the original user's authorization scope, surviving past any single revocation if an attacker holds any branch.
- Detection bypass: legitimate users whose refresh token has been forked do not trip family invalidation when they refresh, because the attacker's branch already swapped the parent row out from under the legitimate user's check.
Credit
Reported by @chdanielmueller.
Resources
- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)
- CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
- CWE-294: Authentication Bypass by Capture-replay
- CWE-613: Insufficient Session Expiration
- RFC 9700 §4.14: Refresh Token Protection
- RFC 6749 §6: Refreshing an Access Token
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@better-auth/oauth-provider"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0"
},
{
"fixed": "1.6.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "better-auth"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.8-beta.7"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53517"
],
"database_specific": {
"cwe_ids": [
"CWE-294",
"CWE-362",
"CWE-367",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T20:55:48Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their project depends on `@better-auth/oauth-provider` at a version `\u003e= 1.6.0, \u003c 1.6.11`, or uses the embedded plugin in `better-auth \u003e= 1.4.8-beta.7, \u003c 1.6.0`.\n- At least one OAuth client served by their application\u0027s authorization server requests the `offline_access` scope, so refresh tokens are minted.\n- Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refresh token times two requests, or a service worker queues offline requests.\n\nIf developer applications do not request `offline_access` for any client, no refresh tokens are minted and they are not exposed.\n\nFix:\n\n1. Upgrade to `@better-auth/oauth-provider@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe OAuth provider\u0027s `POST /oauth2/token` endpoint, on the `refresh_token` grant, performs a non-atomic read / validate / revoke / mint sequence on the `oauthRefreshToken` row. Two concurrent requests presenting the same parent refresh token both pass the revocation check before either revoke completes, so each mints a fresh refresh token. The replay-detection branch only fires when `revoked` is already truthy at read time, which is exactly the state concurrent attackers race past. The result is a forked refresh-token family from a single parent token.\n\n### Details\n\nThe `adapter.update` predicate on the parent row is keyed on `id` only; it does not include `revoked IS NULL`, so two concurrent updates both succeed (last-write-wins, no error path). The schema does not declare `unique` on `oauthRefreshToken.token`, so concurrent creates do not collide on a unique-key violation either.\n\nRFC 9700 \u00a74.14 (OAuth Security Best Current Practice) prescribes refresh-token family invalidation on detected reuse; this implementation tries to enforce that contract through the `revoked` check, but the check is not atomic with the consumption step. Token rotation issues a new refresh token with each call, so a single stolen refresh token grants indefinite access until the row is revoked or its `refreshTokenExpiresAt` (default 7 days) passes. Rotation refreshes that window each call.\n\nThe fix lands an atomic compare-and-swap on the parent row inside the rotation primitive (`UPDATE ... WHERE id = ? AND revoked IS NULL` with a rowcount check), so the losing rotation fails closed with `invalid_grant` and the parent row stays marked revoked. Subsequent replay of the original refresh token then trips the existing family-invalidation guard. The schema gains a unique constraint on `oauthRefreshToken.token` for parity with `oauthAccessToken.token`.\n\n### Patches\n\nFixed in `@better-auth/oauth-provider@1.6.11`. The refresh-token rotation primitive now performs an atomic compare-and-swap on the parent row, and the explicit `revokeRefreshToken` path uses the same CAS. On a contested rotation, exactly one caller wins and mints a fresh refresh token; the loser receives `invalid_grant`. Subsequent replay of the original refresh token trips the existing family-invalidation guard because the parent row stays marked revoked.\n\n`@better-auth/memory-adapter@1.6.11` ships a compatibility fix in the same wave: the in-memory `where` clause now treats `undefined` and `null` as equivalent under an `eq null` predicate, mirroring SQL `IS NULL` and Mongo\u0027s missing-or-null semantics. Without this change, the CAS predicate `WHERE revoked IS NULL` falls through on every call against a row whose optional `revoked` field is absent (the adapter factory\u0027s `transformInput` skips writing `undefined` when no default exists), so the rotation above is broken for any deployment using the in-memory adapter.\n\nStrict refresh-token family invalidation on a contested rotation, per RFC 9700 \u00a74.14 (which calls for invalidating the winner\u0027s tokens too when reuse is detected at rotation time), is deferred to a follow-up minor on the `next` channel. Closing it cleanly requires an opt-in transactional rotation in the adapter contract so the family-delete cannot interleave with the winner\u0027s in-flight access-token insert. The deferred site carries a `FIXME(strict-family-invalidation)` marker.\n\nSchema-migration note: the better-auth migration generator only emits `UNIQUE` for newly-created columns. Existing installs will not pick up the new `oauthRefreshToken.token` unique constraint from `migrate` / `generate`; add it manually if an application\u0027s operational tooling depends on it (`CREATE UNIQUE INDEX oauth_refresh_token_token_uniq ON \"oauthRefreshToken\" (token);`). The CAS fix above does not depend on the database-level constraint to be correct; the constraint is defense-in-depth so collisions from a buggy custom `generateRefreshToken` callback fail loudly.\n\n### Workarounds\n\nNone of these close the bug fully without a code patch.\n\n- **Adapter-level**: configure the database adapter to run the OAuth refresh handler under serializable isolation, or wrap the `adapter.update` on `oauthRefreshToken` with a row-level pessimistic lock (`SELECT ... FOR UPDATE`). Narrows the window without closing it.\n- **Token lifetime**: pass `oauthProvider({ refreshTokenExpiresIn: 60 })` to expire forked families within one minute. Trades attacker persistence for shorter user sessions.\n- **Client-side single-flight**: serialize refresh-token usage in the client SDK with a mutex. Mitigates honest concurrency but does nothing against an attacker with a stolen refresh token.\n- **Disable refresh tokens**: do not request the `offline_access` scope. Closes the surface but breaks long-lived sessions.\n\n### Impact\n\n- **Indefinite access from a single stolen refresh token**: forked refresh-token families grant access at the original user\u0027s authorization scope, surviving past any single revocation if an attacker holds any branch.\n- **Detection bypass**: legitimate users whose refresh token has been forked do not trip family invalidation when they refresh, because the attacker\u0027s branch already swapped the parent row out from under the legitimate user\u0027s check.\n\n### Credit\n\nReported by @chdanielmueller.\n\n### Resources\n\n- [CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)](https://cwe.mitre.org/data/definitions/362.html)\n- [CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition](https://cwe.mitre.org/data/definitions/367.html)\n- [CWE-294: Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html)\n- [CWE-613: Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html)\n- [RFC 9700 \u00a74.14: Refresh Token Protection](https://datatracker.ietf.org/doc/html/rfc9700#section-4.14)\n- [RFC 6749 \u00a76: Refreshing an Access Token](https://datatracker.ietf.org/doc/html/rfc6749#section-6)",
"id": "GHSA-392p-2q2v-4372",
"modified": "2026-07-07T20:55:48Z",
"published": "2026-07-07T20:55:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-392p-2q2v-4372"
},
{
"type": "PACKAGE",
"url": "https://github.com/better-auth/better-auth"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.0"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption"
}
GHSA-399C-6449-XHH6
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-04-22 21:30Bluetooth® Low Energy Pairing in Bluetooth Core Specification v4.0 through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when the MITM negotiates Legacy Passkey Pairing with the pairing Initiator and Secure Connections Passkey Pairing with the pairing Responder and brute forces the Passkey entered by the user into the Initiator. The MITM attacker can use the identified Passkey value to complete authentication with the Responder via Bluetooth pairing method confusion.
{
"affected": [],
"aliases": [
"CVE-2022-25836"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-12T04:15:00Z",
"severity": "HIGH"
},
"details": "Bluetooth\u00ae Low Energy Pairing in Bluetooth Core Specification v4.0 through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when the MITM negotiates Legacy Passkey Pairing with the pairing Initiator and Secure Connections Passkey Pairing with the pairing Responder and brute forces the Passkey entered by the user into the Initiator. The MITM attacker can use the identified Passkey value to complete authentication with the Responder via Bluetooth pairing method confusion.",
"id": "GHSA-399c-6449-xhh6",
"modified": "2025-04-22T21:30:37Z",
"published": "2023-07-06T19:24:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25836"
},
{
"type": "WEB",
"url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reporting-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3GX9-8889-CCM7
Vulnerability from github – Published: 2025-05-19 15:31 – Updated: 2025-05-19 18:30Tiiwee X1 Alarm System TWX1HAKV2 allows Authentication Bypass by Capture-replay, leading to physical Access to the protected facilities without triggering an alarm.
{
"affected": [],
"aliases": [
"CVE-2025-30072"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T15:15:23Z",
"severity": "HIGH"
},
"details": "Tiiwee X1 Alarm System TWX1HAKV2 allows Authentication Bypass by Capture-replay, leading to physical Access to the protected facilities without triggering an alarm.",
"id": "GHSA-3gx9-8889-ccm7",
"modified": "2025-05-19T18:30:45Z",
"published": "2025-05-19T15:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30072"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2025-006.txt"
},
{
"type": "WEB",
"url": "https://www.tiiwee.com/collections/x1-alarm-systems"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/May/20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3P3G-VPW6-4W66
Vulnerability from github – Published: 2021-05-27 18:43 – Updated: 2023-09-29 17:16Impact
When using client authentication method "private_key_jwt" [1], OpenId specification says the following about assertion jti:
A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties
Hydra does not seem to check the uniqueness of this jti value. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens:
$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3u_j7pwvL7YtPqGhtyQe5OhnBE2KCp5pM","expires_in":3599,"scope":"application openid","token_type":"bearer"}⏎ ~$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2_Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4","expires_in":3599,"scope":"application openid","token_type":"bearer"}
Severity
We rate the severity as medium because the following reasons make it hard to replay tokens without the patch:?
- TLS protects against MITM which makes it difficult to intercept valid tokens for replay attacks
- The expiry time of the JWT gives only a short window of opportunity where it could be replayed
Patches
This will be patched with v1.4.0+oryOS.17
Workarounds
Two workarounds have been identified:
- Do not allow clients to use
private_key_jwt - Use short expiry times for the JWTs
References
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
Upstream
This issue will be resolved in the upstream repository https://github.com/ory/fosite
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ory/hydra"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-5300"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-24T21:19:26Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen using client authentication method \"private_key_jwt\" [1], OpenId specification says the following about assertion `jti`:\n\n\u003e A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties\n\nHydra does not seem to check the uniqueness of this `jti` value. Here is me sending the same token request twice, hence with the same `jti` assertion, and getting two access tokens:\n\n```\n$ curl --insecure --location --request POST \u0027https://localhost/_/oauth2/token\u0027 \\\n --header \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n --data-urlencode \u0027grant_type=client_credentials\u0027 \\\n --data-urlencode \u0027client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111\u0027 \\\n --data-urlencode \u0027scope=application openid\u0027 \\\n --data-urlencode \u0027client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer\u0027 \\\n --data-urlencode \u0027client_assertion=eyJhb [...] jTw\u0027\n{\"access_token\":\"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3u_j7pwvL7YtPqGhtyQe5OhnBE2KCp5pM\",\"expires_in\":3599,\"scope\":\"application openid\",\"token_type\":\"bearer\"}\u23ce ~$ curl --insecure --location --request POST \u0027https://localhost/_/oauth2/token\u0027 \\\n --header \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n --data-urlencode \u0027grant_type=client_credentials\u0027 \\\n --data-urlencode \u0027client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111\u0027 \\\n --data-urlencode \u0027scope=application openid\u0027 \\\n --data-urlencode \u0027client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer\u0027 \\\n --data-urlencode \u0027client_assertion=eyJhb [...] jTw\u0027\n{\"access_token\":\"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2_Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4\",\"expires_in\":3599,\"scope\":\"application openid\",\"token_type\":\"bearer\"}\n```\n\n### Severity\n\nWe rate the severity as medium because the following reasons make it hard to replay tokens without the patch:\u0010\n\n- TLS protects against MITM which makes it difficult to intercept valid tokens for replay attacks\n- The expiry time of the JWT gives only a short window of opportunity where it could be replayed\n\n### Patches\n\nThis will be patched with v1.4.0+oryOS.17\n\n### Workarounds\n\nTwo workarounds have been identified:\n\n- Do not allow clients to use `private_key_jwt`\n- Use short expiry times for the JWTs\n\n### References\n\nhttps://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication\n\n### Upstream\n\nThis issue will be resolved in the upstream repository https://github.com/ory/fosite",
"id": "GHSA-3p3g-vpw6-4w66",
"modified": "2023-09-29T17:16:04Z",
"published": "2021-05-27T18:43:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ory/hydra/security/advisories/GHSA-3p3g-vpw6-4w66"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5300"
},
{
"type": "WEB",
"url": "https://github.com/ory/hydra/commit/700d17d3b7d507de1b1d459a7261d6fb2571ebe3"
},
{
"type": "PACKAGE",
"url": "https://github.com/ory/hydra"
},
{
"type": "WEB",
"url": "https://github.com/ory/hydra/releases/tag/v1.4.0"
},
{
"type": "WEB",
"url": "https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Authentication Bypass in hydra"
}
GHSA-3P9H-R6FG-7R7H
Vulnerability from github – Published: 2025-10-14 12:31 – Updated: 2025-10-14 12:31A vulnerability has been identified in SIMATIC S7-1200 CPU V1 family (incl. SIPLUS variants) (All versions < V2.0.2), SIMATIC S7-1200 CPU V2 family (incl. SIPLUS variants) (All versions < V2.0.2). Affected controllers are vulnerable to capture-replay in the communication with the engineering software. This could allow an on-path attacker between the engineering software and the controller to execute any previously recorded commands at a later time (e.g. set the controller to STOP), regardless whether or not the controller had a password configured.
{
"affected": [],
"aliases": [
"CVE-2011-20002"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-14T10:15:33Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SIMATIC S7-1200 CPU V1 family (incl. SIPLUS variants) (All versions \u003c V2.0.2), SIMATIC S7-1200 CPU V2 family (incl. SIPLUS variants) (All versions \u003c V2.0.2). Affected controllers are vulnerable to capture-replay in the communication with the engineering software. This could allow an on-path attacker between the engineering software and the controller to execute any previously recorded commands at a later time (e.g. set the controller to STOP), regardless whether or not the controller had a password configured.",
"id": "GHSA-3p9h-r6fg-7r7h",
"modified": "2025-10-14T12:31:30Z",
"published": "2025-10-14T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-20002"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-625789.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/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-3PWP-6V4C-X7PG
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:34Fiyo CMS 2.0.6.1 allows remote authenticated users to gain privileges via a modified level parameter to dapur/ in an app=user&act=edit action.
{
"affected": [],
"aliases": [
"CVE-2017-6823"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-12T05:59:00Z",
"severity": "HIGH"
},
"details": "Fiyo CMS 2.0.6.1 allows remote authenticated users to gain privileges via a modified level parameter to dapur/ in an app=user\u0026act=edit action.",
"id": "GHSA-3pwp-6v4c-x7pg",
"modified": "2025-04-20T03:34:00Z",
"published": "2022-05-13T01:46:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6823"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/41594"
},
{
"type": "WEB",
"url": "http://rungga.blogspot.co.id/2017/03/privilege-escalation-manipulation-of.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96889"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
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
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.