🔴 【深度分析】严重安全漏洞：CVE-2026-53512

CVSS 评分: 严重（9.1）🔴　　状态: Analyzed　　发布时间: 2026-07-15

🔍 技术细节速览

字段 值
CVE ID CVE-2026-53512
CVSS 评分 9.1 🔴
严重程度 严重
CVSS 向量 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/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
CWE 分类 CWE-287,CWE-306,CWE-345,CWE-863
发布时间 2026-07-15
最后更新 2026-07-21
状态 Analyzed
数据来源 security-advisories@github.com

好的，作为一名资深网络安全分析师，我将基于您提供的 NVD 原始数据，生成一篇专业的漏洞深度分析文章。

🔴 CVE-2026-53512：Better Auth OAuth Token 端点认证绕过漏洞（严重）

CVSS 4.0 评分：9.1（严重）

CVSS 向量： CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

危害等级： 严重 (Critical)。该漏洞允许远程、未授权的攻击者，通过利用一个有效的 refresh_token，在无需提供机密客户端凭据的情况下，获取新的 access_token 和 refresh_token，从而完全接管受害者的认证会话。

漏洞概述

CVE-2026-53512 是一个存在于 Better Auth 认证与授权库中的严重逻辑漏洞。该库是一个用于 TypeScript 生态系统的身份验证框架。

漏洞核心： 在版本 1.6.11 之前的 Better Auth 中，其遗留的 oidcProvider 和 mcp 插件所暴露的 OAuth Token 端点（例如 /api/auth/oauth2/token 或 /api/auth/mcp/token），在处理 refresh_token grant 类型的请求时，未能正确地验证机密客户端（confidential client）的 client_secret。

根据 OAuth 2.0 和 OpenID Connect 标准，当一个应用被注册为“机密客户端”（如后端服务器）时，其对 refresh_token 的交换请求必须包含 client_secret 以证明客户端身份。Better Auth 的这部分实现遗漏了这个关键验证步骤。

影响范围： 所有使用受影响版本的 Better Auth 并启用了 oidcProvider 或 mcp 插件的应用。官方确认 @better-auth/oauth-provider 包不受影响。

严重程度： 严重。攻击者只需获取到一个用户的 refresh_token，无需窃取任何客户端凭据，即可无限期地维持用户的认证状态，并获取访问高价值资源所需的 access_token。

受影响组件与版本

  • 受影响软件： Better Auth
  • 受影响版本： < 1.6.11
  • 修复版本： 1.6.11
  • 不受影响版本： >= 1.6.11
  • 不受影响组件： @better-auth/oauth-provider 包

漏洞原理分析

该漏洞源于对 OAuth 2.0 和 OpenID Connect 协议规范的实现缺陷。现有信息足以进行如下原理分析：

  1. 协议背景：在标准的 OAuth 2.0 refresh_token Grant 流程中，客户端需要向 Token 端点发送一个授权请求，其中必须包含 grant_type=refresh_token、有效的 refresh_token 以及 client_id 和 client_secret（对于机密客户端而言）。client_secret 是用来确保只有被授权的后端服务才能使用 refresh_token 换取新的令牌。

  2. 漏洞成因：Better Auth 的遗留 oidcProvider 和 mcp 插件在实现 Token 端点时，处理 refresh_token 的代码逻辑存在缺陷。从描述 “authenticates only possession of the bound refreshToken row and matching client_id, without verifying the confidential client's client_secret” 可知，服务器仅检查了：

    • 提交的 refresh_token 是否在数据库中有效（refreshToken row）。
    • 提交的 client_id 是否与 refresh_token 绑定（matching client_id）。

    然而，它没有执行关键的第二因素认证：验证与 client_id 关联的 client_secret。这意味着，任何攻击者只要能够获取到一个有效的 refresh_token，即使他们不知道客户的机密凭据，也能成功提交请求。

  3. 攻击向量：

    • 获取 refresh_token：攻击者可以通过多种方式窃取 refresh_token，例如：
      • 跨站脚本攻击 (XSS)：在用户浏览器中执行脚本，窃取存储在其 localStorage 或 cookie 中的令牌。
      • 中间人攻击 (MITM)：在未加密的连接上截获令牌。
      • 日志泄露：从服务器日志或开发调试信息中获取。
      • 恶意软件：从受害者设备上窃取。
    • 构造攻击请求：攻击者向受影响的 Token 端点（如 /api/auth/oauth2/token）发送一个正常的 POST 请求，包含 grant_type=refresh_token、refresh_token=<被窃取的令牌> 以及对应的 client_id。但请求中不会包含 client_secret 字段。
    • 获得新的令牌：由于服务器缺失对 client_secret 的校验，该请求会被视为合法，并返回一个新的 access_token 和 refresh_token。攻击者现在可以用新的令牌冒充受害者。

影响评估

评估维度 分析
攻击复杂度 (AC: L) 攻击复杂度低。一旦攻击者获得了有效的 refresh_token，攻击步骤非常简单，只需发送一个标准的 HTTP 请求即可完成。
攻击向量 (AV: N) 攻击可通过网络远程发起，无需物理接触。
所需权限 (PR: N) 攻击者无需在系统上拥有任何合法账户或权限，只需要外部的 refresh_token 即可。
用户交互 (UI: N) 攻击过程不需要受害者的任何交互（受害者可能在不知情的情况下已经被窃取了令牌）。
机密性影响 (VC: H) 高。攻击者可以获得新的 access_token，从而访问受害者有权访问的任何受保护资源，包括个人数据、敏感业务信息等。
完整性影响 (VI: H) 高。攻击者可以使用 access_token 以受害者身份修改数据、执行操作、发表内容等，严重破坏数据完整性和系统可用性。
攻击前提 (AT: P) 需要存在一个被捕获的 refresh_token。这需要攻击者具备初步的渗透能力（如 XSS、MITM、日志访问等），但一旦达成，后续攻击的门槛极低。

潜在后果：

  • 用户账户完全接管：攻击者可以持续保持对受害者账户的访问，直至令牌被手动撤销或过期。
  • 横向移动：如果被攻击的应用与其他内部系统集成，access_token 可能被用于访问更敏感的内部资源。
  • 数据泄露：攻击者可以窃取所有用户数据。
  • 身份冒用：攻击者可以冒充受害者执行合法操作，如交易、发消息、修改密码等。

修复建议

1. 立即升级（首要方案）

  • 强烈建议：立即将 Better Auth 库升级到 1.6.11 或更高版本。
  • 升级操作通常只需更新 package.json 中的依赖版本并重新安装依赖即可：
    npm install better-auth@latest
# 或
yarn add better-auth@latest
# 或
pnpm update better-auth

2. 临时缓解措施（如无法立即升级）

  • 禁用受影响的插件：如果业务暂时不需要 oidcProvider 或 mcp 插件，可以暂时在 Better Auth 配置中将其禁用。
  • 加强令牌管理：
    • 缩短 refresh_token 有效期：尽可能缩短 refresh_token 的生命周期，降低泄露后的窗口时间。
    • 严格监控 refresh_token 使用：实施监控和告警规则，检测异常的 refresh_token 使用模式，例如频繁的 refresh 操作、不正常的 IP 来源等。
  • 审查访问日志：检查应用程序日志，寻找来自异常来源的、对 /api/auth/oauth2/token 或 /api/auth/mcp/token 端点的可疑请求，特别是那些缺少 client_secret 的 refresh_token 请求。

3. 审计与最佳实践

  • 对所有使用 Better Auth 的授权流程进行安全审计，确保遵循 OAuth 2.0 和 OpenID Connect 协议的最佳实践。
  • 确保所有机密客户端都正确配置并存储了 client_secret。

参考资料