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

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

🔍 技术细节速览

字段 值
CVE ID CVE-2026-53513
CVSS 评分 9.6 🔴
严重程度 严重
CVSS 向量 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
CWE 分类 CWE-20,CWE-345,CWE-441,CWE-918
发布时间 2026-07-15
最后更新 2026-07-21
状态 Analyzed
数据来源 security-advisories@github.com

好的，作为一名资深网络安全分析师，我将基于您提供的 NVD 数据，为您生成一篇关于 CVE-2026-53513 的深度分析文章。

🚨 漏洞深度分析：CVE-2026-53513 - Better Auth SSO 插件中的服务器端请求伪造与账户接管风险

⚠️ CVSS 9.6 (严重)
CVSS 向量: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

漏洞概述

CVE-2026-53513 是一个存在于 Better Auth 开源认证库（TypeScript）的 @better-auth/sso 单点登录插件中的严重安全漏洞。该漏洞允许已认证的攻击者在特定配置下，利用 SSO 单点登录功能发起非盲板（Non-blind）的服务器端请求伪造（SSRF）攻击。成功利用此漏洞可导致敏感信息泄露（高影响：C:H）和账户伪造/劫持（高影响：I:H），尽管不直接影响可用性（A:N）。

根本原因在于，当 SSO 插件配置为 skipDiscovery: true 模式时，其提供的 /sso/register 和 /sso/update-provider API 端点未能对攻击者提交的 OIDC 配置（如 userInfoEndpoint, tokenEndpoint, jwksEndpoint）URL 进行充分的服务端验证。

受影响组件与版本

  • 受影响组件: @better-auth/sso 插件
  • 受影响的库: Better Auth
  • 受影响版本: 所有低于 1.6.11 的版本
  • 修复版本: 1.6.11 及以上版本

漏洞原理分析

攻击向量分析

根据 CVSS 向量（AV:N/AC:L/PR:L/UI:N/S:C），该漏洞的攻击路径清晰且利用难度较低：

  1. 攻击向量（AV: N）：攻击者通过网络即可发起攻击，无需物理接触目标服务器。
  2. 攻击复杂度（AC: L）：攻击者无需特殊的技巧或复杂的环境，仅需在调用 API 时提供恶意的 URL。
  3. 所需权限（PR: L）：攻击者需要拥有一个有效的、能够调用 SSO 管理 API 的认证凭据（通常是拥有配置 SSO 提供商权限的用户）。
  4. 用户交互（UI: N）：攻击链完全由攻击者主导，无需受害者（如普通用户）进行任何操作。
  5. 作用域变更（S: C）：漏洞利用不仅影响目标应用本身，还可能导致 SSO 提供商元数据（如 OIDC 配置、JWKS 密钥）被篡改，从而影响与攻击者控制的恶意 IdP 交互的所有用户。

技术细节

漏洞的核心在于 Better Auth SSO 插件的一个配置选项 skipDiscovery: true。在标准的 OIDC 流程中，服务提供方（SP，即 Better Auth 应用）会通过 OIDC 发现过程从身份提供方（IdP）的 /.well-known/openid-configuration 端点获取所有必要端点的 URL。skipDiscovery: true 的设计初衷是允许管理员手动指定这些端点 URL，以适应不支持自动发现的 IdP 或进行自定义配置。

然而，该功能在实现上存在缺陷：

  1. 缺乏源验证（CWE-441, CWE-20）：POST /sso/register（注册新 SSO 提供商）和 POST /sso/update-provider（更新现有提供商配置）端点接收用户提交的 oidcConfig.userInfoEndpoint、tokenEndpoint 和 jwksEndpoint URL。代码将这些 URL 直接存储 到数据库的 ssoProvider 记录中，没有对其来源（域名、IP 地址）进行任何类型的校验。任何通过认证的用户都可以提供指向内网 IP（如 http://169.254.169.254/latest/meta-data/）、本地主机（http://127.0.0.1:8080/admin）或其他敏感内部服务的 URL。

  2. 非盲板 SSRF（CWE-918）：当合法的用户（或攻击者伪装成的用户）尝试通过该被篡改的 SSO 提供商进行 OIDC 回调时，Better Auth 服务端会主动去读取数据库中存储的这些恶意 URL。这意味着：

    • tokenEndpoint：服务端将向该 URL 发送请求以换取令牌，并将其响应解析为 OAuth 令牌。
    • userInfoEndpoint：服务端将向该 URL 发送请求获取用户信息。
    • jwksEndpoint：服务端将向该 URL 发送请求获取 JSON Web Key Set (JWKS) 来验证 token。

    由于服务端会处理这些请求的响应，攻击者可以：

    • 信息泄露（C:H）：通过 SSRF 技术读取云服务元数据、内部服务响应等。
    • 账户操纵（I:H）：这是最危险的场景。如果同时配置了 trustEmailVerified: true，攻击者可以：
      • 架设一个攻击者控制的恶意 OIDC 提供商。
      • 向 userInfoEndpoint 返回一个包含任意邮箱地址（例如 admin@victim-company.com）的用户信息。
      • 由于 Better Auth 信任了该提供商返回的已验证邮箱（trustEmailVerified: true），它就会将攻击者的本地账户与目标邮箱对应的合法账户进行关联（Account Linking），从而实现账户接管（Account Takeover）。

影响评估

  • 实际威胁: 极高。漏洞利用条件相对容易满足（只需有效用户权限和具备 skipDiscovery 配置的 SSO 功能）。攻击者一旦得手，可以实现以下严重后果：
    • SSRF 攻击：探测和攻击内网服务，获取云环境敏感凭据。
    • 账户冒充：通过控制 SSO 回调信息，使系统将任何用户与攻击者控制的账户绑定，从而以受害者身份登录。
    • 令牌伪造：通过控制 jwksEndpoint 提供伪造的公钥，使服务端信任攻击者签发的任意 JWT 令牌。
  • 攻击复杂度: 低。利用了标准 API 输入验证缺失问题。
  • 所需权限: 低。需要具有配置 SSO 提供商权限的普通用户账号。
  • 潜在后果: 数据泄露、账户接管、横向移动、内部网络侦察等。

修复建议

推荐方案（升级）

立即将 Better Auth 库升级到 1.6.11 或更高版本。

这是最根本、最直接的修复方式。该版本已针对 /sso/register 和 /sso/update-provider API 端点添加了对 userInfoEndpoint， tokenEndpoint， 和 jwksEndpoint 等 URL 参数的来源验证机制。

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

  1. 禁用 skipDiscovery 配置：如果业务上允许，尽量使用 OIDC 的标准发现机制，而不是手动配置端点。将 SSO 提供商配置为 skipDiscovery: false 可以避免此漏洞。
  2. 限制用户权限：严格审查和管理能够配置 SSO 提供商的用户账户。对此类管理员权限进行最小权限原则（PoLP）管理，减少潜在的攻击面。
  3. 部署 WAF 规则：在 Web 应用防火墙（WAF）或反向代理（如 Nginx, HAProxy）层面配置规则，对 POST 到 /sso/register 和 /sso/update-provider 接口的请求体进行深度包检测：
    • 拒绝 oidcConfig 参数中包含内网 IP 地址（如 10.x.x.x, 192.168.x.x, 172.16-31.x.x, 127.x.x.x）或云服务元数据地址（如 169.254.169.254）的请求。
    • 对 URL 中的域名进行白名单校验，仅允许可信任的、已知的 IdP 服务域名。
  4. 加强监控与告警：
    • 监控对 /sso/register 和 /sso/update-provider 接口的异常调用，特别是短时间内多次修改配置的行为。
    • 监控服务器对异常内网 IP 的外连请求，这可能是 SSRF 攻击的证据。

参考资料