Skip to main content

better-auth CVE-2026-45364

HIGH
Improper Restriction of Excessive Authentication Attempts (CWE-307)
2026-05-15 https://github.com/better-auth/better-auth GHSA-p6v2-xcpg-h6xw
7.3
CVSS 3.1 · Vendor: https://github.com/better-auth/better-auth
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Control IPv6 /64 prefix
  2. Delivery
    Rotate source addresses
  3. Exploit
    Bypass per-IP rate limits
  4. Execution
    Unlimited auth attempts
  5. Impact
    Credential stuffing attack

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Brute-force prevention, rate limiting
Exploitation Conditions

Three conditions must all be met: application uses better-auth < 1.4.17 or affected v1.5 prereleases, authentication endpoints serve IPv6 clients (default on Cloudflare, Vercel, AWS ALB, Google Cloud LB), and rate limiting is enabled using default configuration that relies on x-forwarded-for or similar IP header. The vulnerability does not apply if only IPv4 clients are served or if rate limiting is disabled. Applications using version 1.4.16 with custom ipv6Subnet: 64 configuration are also not vulnerable.

Impact

The CVSS score of 7.3 (High) with network vector, low complexity, and no required privileges or user interaction indicates easily exploitable remote attack. However, this is a defense-in-depth bypass rather than direct compromise - attackers still need valid credentials. Real-world impact depends on password strength and other security controls. The absence of KEV listing and EPSS data suggests no confirmed active exploitation. Risk is highest for applications with weak password policies or known/leaked credentials. Most cloud providers advertise IPv6 by default, making the vulnerable configuration common. The comprehensive vendor advisory and quick patch release indicate responsible disclosure and vendor response.

Exploit ScenarioDerived

An attacker with IPv6 connectivity rotates through addresses in their /64 allocation or varies textual encoding of a single address to create unique rate limit keys. Each address appears as a new client, allowing unlimited authentication attempts against /sign-in/email endpoints to perform credential stuffing or brute force attacks without triggering rate limits.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 15, 2026

Rate limiter bypass in better-auth versions < 1.4.17 allows attackers to defeat authentication attempt limits by rotating through IPv6 addresses within their allocated /64 prefix or using different textual representations of the same address. The vulnerability affects authentication endpoints including sign-in, sign-up, and password reset when serving IPv6 clients, which includes most cloud providers by default. No public exploit identified at time of analysis.

RemediationAI

Primary fix is to upgrade to better-auth@1.4.17 or later. For users on version 1.4.16 specifically, set advanced.ipAddress.ipv6Subnet: 64 in the configuration as the normalizeIP helper exists but defaults incorrectly. For versions below 1.4.16, implement IPv6 prefix-based rate limiting at the CDN, WAF, or load balancer level with /64 prefix length or coarser for residential traffic per RFC 6177. As partial mitigation on any version, tighten the customRules window for authentication endpoints to narrow the abuse window. Detailed patches are available at https://github.com/better-auth/better-auth/pull/7470 and https://github.com/better-auth/better-auth/pull/7509.

Affected Packages

npm better-auth fix: 1.4.17, 1.5.0-beta.9

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in npm

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Better-auth is an npm authentication library that implements rate limiting to protect against brute force attacks. The vulnerability stems from how IPv6 addresses were keyed in the rate limiter - using exact textual representation without normalization or prefix masking. IPv6 addressing architecture (RFC 6177) typically allocates /64 prefixes to end users, giving them 2^64 addresses. Additionally, IPv6 allows multiple valid textual representations of the same address through compression, mixed notation, and IPv4-mapped forms. The root cause is CWE-307 (Improper Restriction of Excessive Authentication Attempts) where the rate limiting mechanism fails to group related addresses.

Know when Canonical gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/better-auth/better-auth) PRIMARY 7.3 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Primary rating from Vendor (https://github.com/better-auth/better-auth) · only source for this CVE.

CVSS VectorVendor: https://github.com/better-auth/better-auth

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

DescriptionCVE.org

Am I affected?

Users are affected if all of the following are true:

  • Their app uses better-auth at a version < 1.4.17, or at a v1.5 prerelease tagged <= 1.5.0-beta.8.
  • The apps authentication endpoints serve clients reachable over IPv6. Most managed hosts including Cloudflare, Vercel, Fly.io, AWS Application Load Balancer, and Google Cloud Load Balancing advertise IPv6 by default.
  • The app's rate-limit configuration is enabled (the production default) and relies on the leftmost x-forwarded-for value (the stock setup) or any other configured IP-bearing header.

If users are on 1.4.16 specifically, the normalizeIP helper exists in your version but the IPv6 prefix length defaults to /128. Stock config still permits prefix rotation because no prefix mask is applied. Either upgrade to 1.4.17 or set advanced.ipAddress.ipv6Subnet: 64 in the config.

If applications do not use the rate limiter, or if the deployment serves only IPv4 clients, the prefix-rotation vector does not apply. The representation-aliasing vector still applies to IPv6 addresses delivered over IPv4 transport in some edge cases (an upstream proxy carrying an IPv4-mapped IPv6 source), but it is rare in practice.

Fix:

  1. Upgrade to better-auth@1.4.17 or later. The current stable line 1.6.x and the pre-release line 1.7.0-beta both carry the fix.
  2. If applications cannot upgrade, see workarounds below.

Summary

Better Auth's HTTP rate limiter keyed each request by the exact textual IP address it received in x-forwarded-for (or the configured IP-bearing header). IPv6 clients controlling a typical /64 allocation could rotate through 2^64 distinct source addresses without exhausting the per-address counter, defeating rate limiting on /sign-in/email, /sign-up/email, /forget-password, and every other path the limiter protects. The same bug allowed a single client to vary the textual encoding of one IPv6 address (uppercase, compression, IPv4-mapped, hex-encoded IPv4-in-IPv6) and produce multiple distinct keys.

Details

The pre-fix getIp function returned the leftmost x-forwarded-for value verbatim after a single validity check, and onRequestRateLimit constructed the rate-limit key by string concatenation of that value with the request path. Two facts of IPv6 made the key space larger than the population of clients:

  • ISPs and cloud providers assign prefixes, not addresses. RFC 6177 recommends /56 for residential users; cloud providers commonly assign /29 to /48. An attacker controlling a single /64 therefore controls 2^64 source addresses without doing anything unusual.
  • IPv6 has multiple textual representations for the same address. RFC 5952 specifies a canonical form, but RFC 4291 §2.2 permits the older mixed forms, and ::ffff:0:0/96 IPv4-mapped addresses can be written as either dotted-decimal or hex-encoded.

The fix in better-auth@1.4.17 introduces normalizeIP and applies it to every getIp result. Normalization expands compressed IPv6 forms, lowercases hex digits, collapses IPv4-mapped IPv6 to plain IPv4, and applies a default /64 prefix mask. The rate-limit key construction now uses an explicit | separator to prevent key-construction collisions across address-and-path joins.

The /64 default matches the smallest commonly-allocated IPv6 unit, so a single client cannot use prefix rotation to defeat rate limiting on stock config. Operators who serve clients on coarser allocations (/56 for residential ISPs, larger for cloud) can configure advanced.ipAddress.ipv6Subnet accordingly.

Patches

Fixed in better-auth@1.4.17 on the v1.4.x maintenance line and in better-auth@1.5.0-beta.9 on the v1.5.x line. PR #7470 introduced the normalization primitive (packages/core/src/utils/ip.ts) and applied it to getIp and the rate-limit key. PR #7509 changed the IPv6 prefix-length default from /128 to /64 so that stock config closes the prefix-rotation vector without requiring users to opt in.

After the patch, the rate limiter treats all IPv6 addresses within a /64 allocation as a single client, all textual encodings of one IPv6 address as the same address, and all IPv4-mapped IPv6 addresses as their underlying IPv4 form.

Workarounds

If users cannot upgrade past 1.4.17:

  • On >= 1.4.16: set advanced.ipAddress.ipv6Subnet: 64 in the auth configuration. The normalizeIP helper is present at 1.4.16; only the default is wrong. This restores the post-1.4.17 behavior on stock config.
  • On < 1.4.16: shift the bypass mitigation upstream. Set the IPv6 prefix length on the app's CDN, WAF, or load balancer rate-limit policy to /64 (or coarser per RFC 6177 if the app serves residential traffic). Cloudflare, Vercel Firewall, AWS WAF, and Google Cloud Armor all support per-prefix rate limiting.
  • As a partial mitigation on any version: tighten the customRules window for sign-in, sign-up, and password-reset endpoints. This narrows the abuse window but does not close it.

Impact

The bypass enables unbounded authentication attempts from a single IPv6-capable client. Direct consequences:

  • Credential-stuffing and brute-force on /sign-in/email are no longer rate-limited per client.
  • Account enumeration via response-shape differences becomes faster.
  • Password-reset and email-verification email fan-out can be amplified.

The bypass does not directly compromise any account. Successful exploitation still requires the attacker to guess a credential the password store accepts. The rating reflects the loss of one defense-in-depth layer rather than a direct compromise.

Credit

Reported by @nexryai on GitHub.

Resources

Executive ViewAI

Why It Matters

better-auth versions prior to 1.4.17 contain a rate limiter bypass vulnerability affecting authentication endpoints (sign-in, sign-up, password reset) that allows attackers to circumvent login attempt restrictions by exploiting IPv6 address rotation capabilities. Organizations using better-auth in cloud environments are at elevated risk of credential brute-force attacks against user accounts without technical rate-limiting protection.

Business Impact: High
Compensating Controls

Apply vendor patch. If immediate patching is not possible, implement network-level rate limiting on authentication endpoints (sign-in, sign-up, password reset) at load balancer or WAF layer to restrict requests per IPv6 /64 prefix or enforce account-level lockout policies after failed attempts (e.g., 5 failed attempts within 15 minutes).

Threat Intelligence Overview

EPSS Score
0.1%
Top 79% exploitable
Threat Intel
1
1 source
Data Quality
4 sources
Confidence: Medium
NVD CVE.org EPSS GHSA GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

36
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +36
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Affected Products (CPE)CVE.org

pkg:npm/better-auth
pkg:npm/better-auth
CVE-2011-3544 CRITICAL POC
9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug

CVE-2019-11043 CRITICAL POC
9.8 Oct 28

In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it

CVE-2014-6271 CRITICAL POC
9.8 Sep 24

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which

CVE-2013-0422 CRITICAL POC
9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using

CVE-2016-3714 HIGH POC
8.4 May 05

The (1) EPHEMERAL, (2) HTTPS, (3) MVG, (4) MSL, (5) TEXT, (6) SHOW, (7) WIN, and (8) PLT coders in ImageMagick before 6.

CVE-2017-12617 HIGH POC
8.1 Oct 04

When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTT

CVE-2016-8735 CRITICAL POC
9.8 Apr 06

Remote code execution is possible with Apache Tomcat before 6.0.48, 7.x before 7.0.73, 8.x before 8.0.39, 8.5.x before 8

CVE-2014-7169 CRITICAL POC
9.8 Sep 25

GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of

CVE-2014-0160 HIGH POC
7.5 Apr 07

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe

CVE-2016-5195 HIGH POC
7.0 Nov 10

Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by lev

CVE-2013-2423 LOW POC
3.7 Apr 17

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 17 and earlier, and

CVE-2023-4911 HIGH POC
7.8 Oct 03

Local privilege escalation in the GNU C Library (glibc) dynamic loader ld.so allows unprivileged local users on affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy