CWE-613
Allowed-with-ReviewInsufficient Session Expiration
Abstraction: Base · Status: Incomplete
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
876 vulnerabilities reference this CWE, most recent first.
GHSA-35C6-2WX7-593F
Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-05-06 15:32The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.
{
"affected": [],
"aliases": [
"CVE-2026-20748"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-06T16:16:09Z",
"severity": "MODERATE"
},
"details": "The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable\u00a0a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.",
"id": "GHSA-35c6-2wx7-593f",
"modified": "2026-05-06T15:32:32Z",
"published": "2026-03-06T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20748"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-062-08.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-062-08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-365R-WJFH-HWPV
Vulnerability from github – Published: 2026-03-21 00:31 – Updated: 2026-05-06 18:30The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.
{
"affected": [],
"aliases": [
"CVE-2026-32663"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-20T23:16:44Z",
"severity": "MODERATE"
},
"details": "The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable\u00a0a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.",
"id": "GHSA-365r-wjfh-hwpv",
"modified": "2026-05-06T18:30:24Z",
"published": "2026-03-21T00:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32663"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-078-08.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-078-08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-377J-WJ38-4728
Vulnerability from github – Published: 2025-09-04 14:06 – Updated: 2025-09-05 16:10Impact
The verification of the second factor had too long a session expiry. The long session expiry could be used to circumvent rate limiting of the second factor.
Patches
This issue has been addressed in Weblate 5.13.1 via https://github.com/WeblateOrg/weblate/pull/16002.
References
Thanks to Nahid Hasan Limon for reporting this issue responsibly.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Weblate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58352"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-04T14:06:15Z",
"nvd_published_at": "2025-09-05T00:15:32Z",
"severity": "LOW"
},
"details": "### Impact\nThe verification of the second factor had too long a session expiry. The long session expiry could be used to circumvent rate limiting of the second factor.\n\n\n### Patches\nThis issue has been addressed in Weblate 5.13.1 via https://github.com/WeblateOrg/weblate/pull/16002.\n\n### References\nThanks to Nahid Hasan Limon for reporting this issue responsibly.",
"id": "GHSA-377j-wj38-4728",
"modified": "2025-09-05T16:10:49Z",
"published": "2025-09-04T14:06:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/security/advisories/GHSA-377j-wj38-4728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58352"
},
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/pull/16002"
},
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/commit/0b46fe596231dd456283ead66699ae5516f23908"
},
{
"type": "PACKAGE",
"url": "https://github.com/WeblateOrg/weblate"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Weblate has a long session expiry when verifying second factor"
}
GHSA-3785-76F5-G4RM
Vulnerability from github – Published: 2024-10-16 09:30 – Updated: 2024-10-16 09:30The logout operation in the CloudStack web interface does not expire the user session completely which is valid until expiry by time or restart of the backend service. An attacker that has access to a user's browser can use an unexpired session to gain access to resources owned by the logged out user account. This issue affects Apache CloudStack from 4.15.1.0 through 4.18.2.3; and from 4.19.0.0 through 4.19.1.1.
Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue.
{
"affected": [],
"aliases": [
"CVE-2024-45462"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-16T08:15:05Z",
"severity": "MODERATE"
},
"details": "The logout operation in the CloudStack web interface does not expire the user session completely which is valid until expiry by time or restart of the backend service. An attacker that has access to a user\u0027s browser can use an unexpired session to gain access to resources owned by the logged out user account. This issue affects Apache CloudStack from 4.15.1.0 through 4.18.2.3; and from 4.19.0.0 through 4.19.1.1.\n\n\n\n\nUsers are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue.",
"id": "GHSA-3785-76f5-g4rm",
"modified": "2024-10-16T09:30:31Z",
"published": "2024-10-16T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45462"
},
{
"type": "WEB",
"url": "https://cloudstack.apache.org/blog/security-release-advisory-4.18.2.4-4.19.1.2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ktsfjcnj22x4kg49ctock3d9tq7jnvlo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-38GC-W4H9-7PMF
Vulnerability from github – Published: 2021-12-30 00:00 – Updated: 2022-01-08 00:00An insufficient session expiration vulnerability in the CGI program of the Zyxel NBG6604 firmware could allow a remote attacker to access the device if the correct token can be intercepted.
{
"affected": [],
"aliases": [
"CVE-2021-35034"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-29T13:15:00Z",
"severity": "CRITICAL"
},
"details": "An insufficient session expiration vulnerability in the CGI program of the Zyxel NBG6604 firmware could allow a remote attacker to access the device if the correct token can be intercepted.",
"id": "GHSA-38gc-w4h9-7pmf",
"modified": "2022-01-08T00:00:41Z",
"published": "2021-12-30T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35034"
},
{
"type": "WEB",
"url": "https://www.zyxel.com/support/Zyxel_security_advisory_for_sensitive_information_vulnerabilities_of_NBG6604_home_router.shtml"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-38J9-7PP9-2HJW
Vulnerability from github – Published: 2021-06-08 18:52 – Updated: 2021-06-17 20:00HashiCorp Vault and Vault Enterprise allowed the renewal of nearly-expired token leases and dynamic secret leases (specifically, those within 1 second of their maximum TTL), which caused them to be incorrectly treated as non-expiring during subsequent use. Fixed in 1.5.9, 1.6.5, and 1.7.2.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.7.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0"
},
{
"fixed": "1.6.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"fixed": "1.5.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32923"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-04T18:42:40Z",
"nvd_published_at": "2021-06-03T11:15:00Z",
"severity": "HIGH"
},
"details": "HashiCorp Vault and Vault Enterprise allowed the renewal of nearly-expired token leases and dynamic secret leases (specifically, those within 1 second of their maximum TTL), which caused them to be incorrectly treated as non-expiring during subsequent use. Fixed in 1.5.9, 1.6.5, and 1.7.2.",
"id": "GHSA-38j9-7pp9-2hjw",
"modified": "2021-06-17T20:00:42Z",
"published": "2021-06-08T18:52:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32923"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2021-15-vault-renewed-nearly-expired-leases-with-incorrect-non-expiring-ttls/24603"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202207-01"
},
{
"type": "WEB",
"url": "https://www.hashicorp.com/blog/category/vault"
}
],
"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": "Invalid session token expiration "
}
GHSA-38XM-RJ5R-36VX
Vulnerability from github – Published: 2024-01-26 21:30 – Updated: 2024-04-01 09:30A vulnerability was found in Totolink T8 4.1.5cu.833_20220905. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /cgi-bin/cstecgi.cgi. The manipulation leads to session expiration. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-252188. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-0944"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-26T20:15:54Z",
"severity": "LOW"
},
"details": "A vulnerability was found in Totolink T8 4.1.5cu.833_20220905. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /cgi-bin/cstecgi.cgi. The manipulation leads to session expiration. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-252188. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-38xm-rj5r-36vx",
"modified": "2024-04-01T09:30:31Z",
"published": "2024-01-26T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0944"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1YPisSnxM5CwSLKFgs9w5k5MtNUgiijVo/view?usp=sharing"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.252188"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.252188"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.269681"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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-3942-82QW-F9QH
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-01 18:30IBM WebSphere Application Server Liberty 23.0.0.9 through 23.0.0.10 could provide weaker than expected security due to improper resource expiration handling. IBM X-Force ID: 268775.
{
"affected": [],
"aliases": [
"CVE-2023-46158"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T18:17:37Z",
"severity": "CRITICAL"
},
"details": "IBM WebSphere Application Server Liberty 23.0.0.9 through 23.0.0.10 could provide weaker than expected security due to improper resource expiration handling. IBM X-Force ID: 268775.",
"id": "GHSA-3942-82qw-f9qh",
"modified": "2023-11-01T18:30:32Z",
"published": "2023-10-25T18:32:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46158"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/268775"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7058356"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-3CCG-X393-96V8
Vulnerability from github – Published: 2026-02-25 22:02 – Updated: 2026-02-27 21:51Summary The application allows users to set weak passwords (e.g., 1234, password) without enforcing minimum strength requirements. Additionally, active sessions remain valid after a user changes their password.
An attacker who compromises an account (via brute-force or credential stuffing) can maintain persistent access even after the victim resets their password.
Details
- Weak passwords are accepted during registration and password change.
- No minimum length or strength validation is enforced.
- After changing the password, previously issued session tokens remain valid.
- No forced logout occurs across active sessions.
Attack scenario:
Attacker guesses or obtains weak credentials. Logs in and obtains active session token. Victim changes password. Attacker continues accessing the account using the old session.
Steps to Reproduce
1. Register using a weak password (e.g., 12345678 ). 2. Log in and Password Change functionality. 3. Change account password with single character (e.g., 1 or a ) 4. Reuse the old session. 5. Observe that access is still granted.
Impact
- Persistent account takeover
- Unauthorized access to sensitive data
- Increased brute-force success probability
- Elevated risk for administrative accounts
The combination of weak password controls and improper session invalidation significantly increases both exploitability and impact.
Recommendation Password Policy Improvements:
- Enforce strong password policies – Require passwords to be 8–16+ characters with a mix of uppercase, lowercase, numbers, and special characters.
- Block common passwords – Use a blacklist of commonly used and breached passwords.
- Use secure hashing – Store passwords using strong salted hashing algorithms like bcrypt or Argon2.
- Enable account lockout – Limit failed login attempts to reduce brute-force risk.
- Educate users – Promote strong password practices and phishing awareness.
Session Management Fix:
- Invalidate all active sessions upon password change
- Revoke refresh tokens (if applicable)
- Implement token/session versioning
- Regenerate session IDs after credential updates
- Log and notify users of password change events
Implementing both controls will significantly reduce the risk of persistent account compromise.
A fixed version is available at https://github.com/go-vikunja/vikunja/releases/tag/v2.0.0.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.24.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27575"
],
"database_specific": {
"cwe_ids": [
"CWE-521",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-25T22:02:37Z",
"nvd_published_at": "2026-02-25T22:16:26Z",
"severity": "CRITICAL"
},
"details": "**Summary**\nThe application allows users to set weak passwords (e.g., 1234, password) without enforcing minimum strength requirements. Additionally, active sessions remain valid after a user changes their password.\n\nAn attacker who compromises an account (via brute-force or credential stuffing) can maintain persistent access even after the victim resets their password.\n\n\n**Details**\n\n1. Weak passwords are accepted during registration and password change.\n2. No minimum length or strength validation is enforced.\n3. After changing the password, previously issued session tokens remain valid.\n4. No forced logout occurs across active sessions.\n\n_Attack scenario:_\n\nAttacker guesses or obtains weak credentials.\nLogs in and obtains active session token.\nVictim changes password.\nAttacker continues accessing the account using the old session.\n\n**Steps to Reproduce**\n\n**1.** Register using a weak password (e.g., 12345678 ).\n**2.** Log in and Password Change functionality.\n**3.** Change account password with single character (e.g., 1 or a )\n**4.** Reuse the old session.\n**5.** Observe that access is still granted.\n\n**Impact**\n\n- Persistent account takeover\n- Unauthorized access to sensitive data\n- Increased brute-force success probability\n- Elevated risk for administrative accounts\n\nThe combination of weak password controls and improper session invalidation significantly increases both exploitability and impact.\n\n**Recommendation**\n_**Password Policy Improvements:**_\n\n- Enforce strong password policies \u2013 Require passwords to be 8\u201316+ characters with a mix of uppercase, lowercase, numbers, and special characters.\n- Block common passwords \u2013 Use a blacklist of commonly used and breached passwords.\n- Use secure hashing \u2013 Store passwords using strong salted hashing algorithms like bcrypt or Argon2.\n- Enable account lockout \u2013 Limit failed login attempts to reduce brute-force risk.\n- Educate users \u2013 Promote strong password practices and phishing awareness.\n\n_**Session Management Fix:**_\n\n- Invalidate all active sessions upon password change\n- Revoke refresh tokens (if applicable)\n- Implement token/session versioning\n- Regenerate session IDs after credential updates\n- Log and notify users of password change events\n\nImplementing both controls will significantly reduce the risk of persistent account compromise.\n\n\u003cimg width=\"1918\" height=\"907\" alt=\"Weak Password Policy Combined with Persistent Sessions After Password Change POC\" src=\"https://github.com/user-attachments/assets/f188b69b-0472-4d2c-aeda-c145384c99ef\" /\u003e\n\nA fixed version is available at https://github.com/go-vikunja/vikunja/releases/tag/v2.0.0.",
"id": "GHSA-3ccg-x393-96v8",
"modified": "2026-02-27T21:51:50Z",
"published": "2026-02-25T22:02:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-3ccg-x393-96v8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27575"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/89c17d3b23e2a23320ad135b4e8f0a14fdd91bda"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://vikunja.io/changelog/vikunja-v2.0.0-was-released"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vijkunja has Weak Password Policy Combined with Persistent Sessions After Password Change"
}
Mitigation
Set sessions/credentials expiration date.
No CAPEC attack patterns related to this CWE.