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).
348 vulnerabilities reference this CWE, most recent first.
GHSA-2CHH-R2HC-8Q2G
Vulnerability from github – Published: 2025-07-05 06:30 – Updated: 2025-07-05 06:30Dradis through 4.16.0 allows referencing external images (resources) over HTTPS, instead of forcing the use of embedded (uploaded) images. This can be leveraged by an authorized author to attempt to steal the Net-NTLM hashes of other authors on a Windows domain network.
{
"affected": [],
"aliases": [
"CVE-2023-50786"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-05T04:15:24Z",
"severity": "MODERATE"
},
"details": "Dradis through 4.16.0 allows referencing external images (resources) over HTTPS, instead of forcing the use of embedded (uploaded) images. This can be leveraged by an authorized author to attempt to steal the Net-NTLM hashes of other authors on a Windows domain network.",
"id": "GHSA-2chh-r2hc-8q2g",
"modified": "2025-07-05T06:30:30Z",
"published": "2025-07-05T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50786"
},
{
"type": "WEB",
"url": "https://dradis.com"
},
{
"type": "WEB",
"url": "https://dradis.com/ce"
},
{
"type": "WEB",
"url": "https://securiteam.io/2025/07/04/cve-2023-50786-dradis-ntlm-theft-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2GFR-HJCW-MR7Q
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2024-03-21 03:33** DISPUTED ** An issue was discovered in the GAEN (aka Google/Apple Exposure Notifications) protocol through 2020-10-05, as used in COVID-19 applications on Android and iOS. The encrypted metadata block with a TX value lacks a checksum, allowing bitflipping to amplify a contamination attack. This can cause metadata deanonymization and risk-score inflation. NOTE: the vendor's position is "We do not believe that TX power authentication would be a useful defense against relay attacks."
{
"affected": [],
"aliases": [
"CVE-2020-24722"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-07T15:15:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** An issue was discovered in the GAEN (aka Google/Apple Exposure Notifications) protocol through 2020-10-05, as used in COVID-19 applications on Android and iOS. The encrypted metadata block with a TX value lacks a checksum, allowing bitflipping to amplify a contamination attack. This can cause metadata deanonymization and risk-score inflation. NOTE: the vendor\u0027s position is \"We do not believe that TX power authentication would be a useful defense against relay attacks.\"",
"id": "GHSA-2gfr-hjcw-mr7q",
"modified": "2024-03-21T03:33:56Z",
"published": "2022-05-24T17:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24722"
},
{
"type": "WEB",
"url": "https://blog.google/inside-google/company-announcements/update-exposure-notifications"
},
{
"type": "WEB",
"url": "https://github.com/google/exposure-notifications-internals/blob/main/en-risks-and-mitigations-faq.md#additional-considerations"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/159496/GAEN-Protocol-Metadata-Deanonymization-Risk-Score-Inflation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Oct/12"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-2QP5-R5HX-Q27P
Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-26 09:30Remote Keyless Entry System (RKES), using the 433 MHz key fob bearing FCC ID CWTR53R0 manufactured by ALPS ALPINE CO., LTD., is vulnerable to a roll-back attack against its rolling-code authentication.
An attacker within RF range who records two consecutive lock or unlock transmissions from a legitimate key fob can later replay the same pair of transmissions repeatedly. During testing, replaying the first captured transmission caused the RKES to enter a state in which replaying the second captured transmission resulted in a successful lock or unlock operation of the vehicle. Tested and confirmed on a 2024 Suzuki Swift (SWIFT ISG GLS AC 1.2 5P 4x2 TM).
{
"affected": [],
"aliases": [
"CVE-2026-49319"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T15:16:37Z",
"severity": "MODERATE"
},
"details": "Remote Keyless Entry System (RKES), using the 433 MHz key fob bearing FCC ID CWTR53R0 manufactured by ALPS ALPINE CO., LTD., is vulnerable to a roll-back attack against its rolling-code authentication.\u00a0\n\n\n\nAn attacker within RF range who records two consecutive lock or unlock transmissions from a legitimate key fob can later replay the same pair of transmissions repeatedly. During testing, replaying the first captured transmission caused the RKES to enter a state in which replaying the second captured transmission resulted in a successful lock or unlock operation of the vehicle. Tested and confirmed on\u00a0a 2024 Suzuki Swift (SWIFT ISG GLS AC 1.2 5P 4x2 TM).",
"id": "GHSA-2qp5-r5hx-q27p",
"modified": "2026-06-26T09:30:46Z",
"published": "2026-06-25T15:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49319"
},
{
"type": "WEB",
"url": "https://fccid.io/CWTR53R0"
},
{
"type": "WEB",
"url": "https://www.asrg.io/security-advisories/cve-2026-49319-suzuki-swift-2024-rkes-rollback-replay"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:L/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-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-3252-V85M-5FQ8
Vulnerability from github – Published: 2026-07-16 15:33 – Updated: 2026-07-16 15:33HCL DFXAnalytics is affected by a Login Replay Attack vulnerability. The application allows a remote attacker to intercept, delay, or fraudulently retransmit valid authentication data to achieve unauthorized access. To mitigate this risk, the application must implement a mechanism to include timestamps with every message, ensuring that messages exceeding a specific age threshold are automatically rejected by the recipient system.
{
"affected": [],
"aliases": [
"CVE-2026-35141"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-16T14:16:50Z",
"severity": "LOW"
},
"details": "HCL DFXAnalytics is affected by a Login Replay Attack vulnerability. The application allows a remote attacker to intercept, delay, or fraudulently retransmit valid authentication data to achieve unauthorized access. To mitigate this risk, the application must implement a mechanism to include timestamps with every message, ensuring that messages exceeding a specific age threshold are automatically rejected by the recipient system.",
"id": "GHSA-3252-v85m-5fq8",
"modified": "2026-07-16T15:33:10Z",
"published": "2026-07-16T15:33:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35141"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0131787"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:N",
"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"
}
]
}
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.