Skip to content
Log inStart free trial

GHSA-44jh-23m7-hpcf CVE-2026-110861

@better-auth/drizzle-adapter: Concurrent requests can exceed rate limits on PostgreSQL

Medium npm
Severity
6.3 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.22%
Chance of exploitation in the next 30 days. Higher than 12.25% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-307 Improper Restriction of Excessive Authentication Attempts
CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Fix
Available
3 packages have a fixed version

Description

Am I affected?

You are affected if you use @better-auth/drizzle-adapter from 1.6.17 through versions before 1.7.7 (including the 1.7.0 prereleases from beta.6 through rc.6) or @better-auth/kysely-adapter 1.6.17 through 1.6.31, and keep rate-limit records in a PostgreSQL database.

All of these must be true:

  • Rate limiting is enabled.
  • Rate-limit records are stored in the database.
  • The database is PostgreSQL, used through one of the adapter versions above.

You are not affected if you store rate-limit records in memory (the default) or in secondary storage.

Summary

Database-backed rate limiting on PostgreSQL can let a burst of concurrent requests go over the configured maximum. When many requests arrive at the same time, several of them can pass the limit check together. This weakens the rate limit on password sign-in, two-factor verification, one-time codes, password resets, and other rate-limited endpoints.

Impact

An attacker who sends many requests at once can make more attempts than the application allows.

The issue does not bypass password or one-time-code validation. It does not directly compromise an account. The number of extra attempts is limited by the number of concurrent database connections, the number of application instances, and the rate-limit window.

Patches

@better-auth/kysely-adapter is fixed in 1.7.0. Upgrade to 1.7.0 or later.

The Drizzle fix is merged for the planned @better-auth/drizzle-adapter 1.7.7 release. That package is not available yet. Upgrade better-auth and the installed Drizzle adapter together when 1.7.7 is available. No database schema or public API migration is required.

Workarounds

  • Store rate-limit records in secondary storage.
  • Use a custom rate-limit storage that checks and increments the counter in one atomic step. An atomic step cannot be interrupted by another request.
  • Enforce the intended limit at an upstream layer, such as a reverse proxy or gateway.

In-memory storage also avoids this issue. However, each application instance keeps its own counter, so it may not enforce one shared limit in multi-instance or serverless deployments.

Affected versions

npm

PackageVulnerableFixed in
@better-auth/drizzle-adapter
>= 1.6.17, < 1.7.7
1.7.7
@better-auth/kysely-adapter
>= 1.6.17, < 1.7.0
1.7.0
better-auth
>= 1.6.17, < 1.7.7
1.7.7

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

@better-auth/drizzle-adapter npm → 1.7.7

npm
npm install @better-auth/drizzle-adapter@1.7.7
yarn
yarn add @better-auth/drizzle-adapter@1.7.7
pnpm
pnpm add @better-auth/drizzle-adapter@1.7.7

@better-auth/kysely-adapter npm → 1.7.0

npm
npm install @better-auth/kysely-adapter@1.7.0
yarn
yarn add @better-auth/kysely-adapter@1.7.0
pnpm
pnpm add @better-auth/kysely-adapter@1.7.0

better-auth npm → 1.7.7

npm
npm install better-auth@1.7.7
yarn
yarn add better-auth@1.7.7
pnpm
pnpm add better-auth@1.7.7

Severity breakdown

CVSS 4.0 6.3

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Network
Attack complexity
High
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 3.7

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

Weakness

CWE-307: Improper Restriction of Excessive Authentication Attempts

The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.

How to prevent it
  • Architecture and Design: Common protection mechanisms include: Disconnecting the user after a small number of failed attempts Implementing a timeout Locking out a targeted account Requiring a computational task on the user's part.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

How to prevent it
  • Architecture and Design: In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
  • Architecture and Design: Use thread-safe capabilities such as the data access abstraction in Spring.
  • Architecture and Design: Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
  • Implementation: When using multithreading and operating on shared variables, only use thread-safe functions.
  • Implementation: Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
  • Implementation: Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
  • Implementation: Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
  • Implementation: Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
  • Implementation: Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
  • Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

References

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-r4xp-prcw-77qf
better-auth: OAuth Proxy lets an attacker sign in as another user
Critical Also affects better-auth
GHSA-965c-763c-88jm
better-auth: OAuth state can be used as a Magic Link to sign in as another user
Critical Also affects better-auth
GHSA-q84f-53jg-9ppm
better-auth: Device login approval does not show the requesting client or permissions
High Also affects better-auth
GHSA-qq9h-g4jm-xgf3
Better Auth: Account takeover via pre-account hijacking on magic-link and email-OTP sign-in
High Also affects better-auth
GHSA-2vg6-77g8-24mp
Better Auth: Stale sessions persist after user deletion across admin, anonymous, and SCIM flows
Medium Also affects better-auth
GHSA-7w99-5wm4-3g79
@better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete primitive
High Also affects better-auth
GHSA-392p-2q2v-4372
Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption
High Also affects better-auth
GHSA-9h47-pqcx-hjr4
Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by default
Critical Also affects better-auth
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor