<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Better-Auth - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/better-auth/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 07 Jul 2026 20:15:52 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/better-auth/feed.xml" rel="self" type="application/rss+xml"/><item><title>Better Auth OAuth Refresh Token Replay via Missing Client Authentication (CVE-2026-53512)</title><link>https://feed.craftedsignal.io/briefs/2026-07-better-auth-refresh-token-replay/</link><pubDate>Tue, 07 Jul 2026 20:15:52 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-better-auth-refresh-token-replay/</guid><description>The legacy `oidcProvider` and `mcp` plugins in the `better-auth` library versions prior to 1.6.11 are vulnerable to CVE-2026-53512, an OAuth refresh-token replay attack where the plugins fail to verify the `client_secret` of confidential clients during the `refresh_token` grant, allowing an attacker who obtains a valid `refresh_token` and `client_id` to indefinitely mint new access tokens and impersonate the client for unauthorized resource access.</description><content:encoded><![CDATA[<p>A critical vulnerability, CVE-2026-53512, has been identified in the <code>better-auth</code> library, affecting applications using the deprecated <code>oidcProvider()</code> or <code>mcp()</code> plugins in versions prior to <code>1.6.11</code>. This flaw stems from a missing client authentication step during the OAuth 2.0 <code>refresh_token</code> grant for confidential clients. Unlike the <code>authorization_code</code> grant, these plugins failed to verify the <code>client_secret</code>, enabling an attacker to replay a stolen <code>refresh_token</code> and its corresponding public <code>client_id</code> to repeatedly mint new access tokens. The attacker can gain indefinite access to resources with the user's original authorized scope, as token rotation refreshes the expiration window with each call. This significantly impacts any <code>better-auth</code> application configured with confidential OAuth clients using the vulnerable plugins.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access / Credential Acquisition:</strong> An attacker obtains a valid <code>refresh_token</code> and the associated public <code>client_id</code> for a confidential OAuth client. This could occur through various methods such as a database breach, log file capture, browser-side Cross-Site Scripting (XSS), or via a CORS-amplified script if exploiting the <code>mcp</code> endpoint with its wildcard <code>Access-Control-Allow-Origin: *</code>.</li>
<li><strong>Exploitation of Missing Authentication:</strong> The attacker sends a <code>POST</code> request to the vulnerable OAuth 2.0 token endpoint (e.g., <code>/api/auth/oauth2/token</code> or <code>/api/auth/mcp/token</code>) using the stolen <code>refresh_token</code> and <code>client_id</code>, but crucially, <em>without</em> providing the <code>client_secret</code>.</li>
<li><strong>Token Endpoint Bypass:</strong> Due to the flaw in <code>better-auth</code> versions prior to 1.6.11, the <code>oidcProvider</code> or <code>mcp</code> plugins do not enforce <code>client_secret</code> verification on the <code>refresh_token</code> grant for confidential clients, allowing the unauthenticated request to proceed.</li>
<li><strong>Access Token Minting:</strong> The vulnerable token endpoint issues a new, valid <code>access_token</code> to the attacker, along with a rotated <code>refresh_token</code>.</li>
<li><strong>Indefinite Session Prolongation:</strong> The attacker uses the newly minted <code>refresh_token</code> to repeat steps 2-4, effectively resetting the expiration window of the session and gaining indefinite access.</li>
<li><strong>Resource Access:</strong> With the valid <code>access_token</code>, the attacker can impersonate the legitimate client and user, making requests to resource servers to access, modify, or exfiltrate data within the scope of the original user's authorization.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The impact of CVE-2026-53512 is significant, primarily leading to indefinite confidential-client impersonation. An attacker who has acquired a single <code>refresh_token</code> and the corresponding <code>client_id</code> can continuously mint new <code>access_tokens</code> and rotate <code>refresh_tokens</code>, thereby maintaining persistent unauthorized access without further authentication. Each newly issued <code>access_token</code> carries the original user's authorized scope, granting the attacker the ability to read, write, or otherwise manipulate data on resource servers as if they were the legitimate user. This can result in severe data breaches, unauthorized modifications, and complete compromise of data governed by the affected OAuth client's permissions. The vulnerability affects <code>better-auth</code> applications leveraging the deprecated <code>oidcProvider</code> or <code>mcp</code> plugins.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li><strong>Upgrade immediately</strong> to <code>better-auth@1.6.11</code> or later to apply the official patch for CVE-2026-53512.</li>
<li><strong>Migrate from deprecated plugins</strong> by transitioning from <code>oidcProvider()</code> to the canonical <code>@better-auth/oauth-provider</code> package, as it enforces client authentication on all grants by default.</li>
<li><strong>Implement network-layer ingress restriction</strong> for <code>/api/auth/oauth2/token</code> and <code>/api/auth/mcp/token</code> endpoints to known client IPs at the load balancer, which can partially mitigate risk for server-to-server flows.</li>
<li><strong>Force all clients to public + PKCE</strong> by setting every client's <code>type: &quot;public&quot;</code> and requiring PKCE, thereby eliminating the <code>client_secret</code> for verification where the bug manifests.</li>
<li><strong>For the mcp endpoint specifically</strong>, drop the wildcard CORS header at an upstream proxy and replace it with a tight allowlist to prevent CORS-amplified attacks.</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>oauth</category><category>authentication-bypass</category><category>vulnerability</category><category>web</category><category>better-auth</category></item></channel></rss>