CVE-2026-110861 in better-auth
Summary
by MITRE • 10/15/2026
Better Auth @better-auth/drizzle-adapter and better-auth from 1.6.17 before 1.7.7, and @better-auth/kysely-adapter from 1.6.17 before 1.7.0, contain a race condition in database-backed rate limiting on PostgreSQL where the limit check is not atomic with the counter update. Remote attackers can send bursts of concurrent requests that pass the check together, exceeding configured limits on password sign-in, two-factor verification, one-time code, password reset, and other rate-limited endpoints.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Better Auth versions prior to 1.7.7 for the core library and better-auth/drizzle-adapter, as well as version 1.6.17 before 1.7.0 for the better-auth/kysely-adapter, represents a critical race condition within the database-backed rate limiting mechanism when operating on PostgreSQL databases. This flaw stems from a fundamental lack of atomicity in the sequence of operations used to enforce access controls. Specifically, the system performs a check against the current request count followed by an update to increment that counter. In concurrent execution environments, this two-step process creates a time-of-check-to-time-of-use (TOCTOU) window where multiple threads or processes can read the same baseline limit value before any of them have incremented it. Consequently, each thread perceives itself as being within the allowed threshold and proceeds with authentication-related actions, effectively bypassing the intended rate limits designed to prevent brute-force attacks and credential stuffing attempts.
From a technical perspective, this issue aligns closely with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The root cause lies in the implementation of the database queries used for rate limiting. Instead of utilizing atomic operations such as SELECT FOR UPDATE or UPSERT statements that ensure exclusive access during both the check and update phases, the application relies on non-isolated reads followed by writes. When a remote attacker sends bursts of concurrent requests to endpoints protected by this mechanism, these requests are processed in parallel threads. Because the database transaction isolation level does not prevent dirty reads or lost updates in this specific context, all simultaneous requests may pass the initial validation check simultaneously. This allows an adversary to exceed the configured maximum number of attempts for sensitive operations such as password sign-in, two-factor verification, one-time code generation, and password reset procedures within a single time window.
The operational impact of this vulnerability is significant, particularly regarding account security and system integrity. By bypassing rate limits, attackers can execute high-volume brute-force attacks against user accounts without triggering lockouts or alerts that would normally occur after exceeding the threshold. This increases the probability of successful credential compromise, especially for users with weak passwords. Furthermore, the ability to rapidly generate multiple one-time codes or password reset tokens could facilitate phishing campaigns or account takeover attempts by overwhelming legitimate users with notifications or allowing attackers to intercept and use reset links before the victim can react. The vulnerability affects critical authentication flows, meaning that any endpoint relying on this rate limiting logic is potentially exposed to automated abuse, leading to potential denial of service through resource exhaustion as well as unauthorized access.
To mitigate this risk, immediate action should be taken by upgrading Better Auth and its associated adapters to versions 1.7.7 or later for the core library and better-auth/drizzle-adapter, and version 1.7.0 or later for better-auth/kysely-adapter. These updated releases address the race condition by implementing atomic database operations that ensure the check and update of rate limit counters occur within a single transactional boundary, thereby preventing concurrent requests from bypassing limits. In environments where upgrading is not immediately feasible, temporary mitigations include adjusting the PostgreSQL isolation level to SERIALIZABLE for relevant transactions or implementing application-level locking mechanisms such as distributed locks using Redis with atomic operations like SETNX. Additionally, monitoring logs for unusual spikes in authentication attempts can help detect ongoing exploitation of this vulnerability while patches are being deployed. This issue is categorized under MITRE ATT&CK technique T1110, which covers brute force attacks, highlighting the importance of robust rate limiting as a primary defense against automated credential guessing campaigns.