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

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

🔍 技术细节速览

字段 值
CVE ID CVE-2026-61740
CVSS 评分 9.3 🔴
严重程度 严重
CVSS 向量 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/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-798
发布时间 2026-07-15
最后更新 2026-07-15
状态 Deferred
数据来源 security-advisories@github.com

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

漏洞概述

🗸 CVE-2026-61740 是一个位于 LightRAG 开源项目中的 严重身份验证绕过漏洞。

该漏洞允许远程未认证的攻击者，在特定配置下，绕过 LightRAG 的 API 密钥保护机制，成功调用本应受保护的各类敏感 API 端点，包括文档读取、上传、删除、知识图谱修改以及查询等操作。

根据 CVSS 4.0 评分，该漏洞被评为 9.3 (严重 - Critical)，其攻击向量为网络 (AV:N)，攻击复杂度低 (AC:L)，且无需任何权限 (PR:N) 和用户交互 (UI:N)。该漏洞直接影响数据的机密性 (VC:H) 和完整性 (VI:H)，影响范围广泛。

受影响组件与版本

  • 受影响组件: LightRAG
  • 受影响版本: < 1.5.4
  • 修复版本: 1.5.4
  • 触发条件： 服务以 LIGHTRAG_API_KEY 变量设置，但 AUTH_ACCOUNTS 变量未设置的状态下部署。

漏洞原理分析

此漏洞的成因涉及多个不安全的逻辑和默认配置组合，构成了一条完整的攻击链。

根据提供的 NVD 描述和 CWE 分类 (CWE-287: Improper Authentication, CWE-798: Use of Hard-coded Credentials)，我们可以推断出以下攻击链：

  1. 硬编码秘密与权限提升 (CWE-798):

    • 当 AUTH_ACCOUNTS 未设置时，lightrag/api/auth.py 文件中的认证逻辑会退化，使用一个硬编码的 DEFAULT_TOKEN_SECRET 来签发和验证 JWT (JSON Web Token)。
    • 这意味着任何知道或能猜到该硬编码秘密的攻击者，都可以为自己伪造任意权限的 JWT。

  2. API 密钥旁路:

    • 正常逻辑下，认证应先通过根级 API 密钥 (X-API-Key) 验证。然而，/auth-status 和 /login 这两个端点可以直接使用上述硬编码的秘密来签发访客 JWT。

  3. 认证顺序缺陷:

    • 在 lightrag/api/utils_api.py 中的 combined_dependency 函数（一个装饰器或依赖注入函数）里，认证逻辑存在缺陷。
    • 该函数在处理请求时，首先检查并接受了由硬编码秘密签发的一个有效访客 JWT，而跳过了后续对 X-API-Key 的校验。

攻击向量总结：
攻击者通过以下步骤即可利用漏洞：

  1. 发送请求到 /auth-status 或 /login 端点，利用硬编码的 DEFAULT_TOKEN_SECRET 生成一个合法的访客 JWT。
  2. 使用该 JWT 作为认证凭证，调用本应由 combined_auth 保护的高级 API 端点（如文档操作、查询等）。
  3. 由于后端认证逻辑的缺陷，该 JWT 被接受，攻击者成功绕过 API 密钥保护，获得了相当于初级用户的访问权限（甚至更高，取决于 JWT 中包含的权限）。

现有信息不足以完全确定 DEFAULT_TOKEN_SECRET 的具体值，但此类硬编码密码在开源项目中通常可以通过源码静态分析轻松获取，这是该问题的核心风险。

影响评估

  • 攻击复杂度 (AC:L): 低。利用流程简单清晰，只需构造几个 HTTP 请求，无需特殊工具或复杂技术。攻击者甚至可以很快在公开的源代码中找到硬编码的秘密。
  • 所需权限 (PR:N): 无。攻击者在发起攻击前不需要任何有效的身份凭证。
  • 用户交互 (UI:N): 无。攻击过程不需要受害用户进行任何操作。
  • 攻击途径 (AV:N): 网络。攻击者可以通过公网远程发起攻击。
  • 潜在后果:
    • 数据泄露 (VC:H): 攻击者可以读取所有文档，包括敏感的商业数据、客户信息或技术文档。
    • 数据篡改 (VI:H): 攻击者可以上传、修改甚至删除 RAG 系统中的文档，注入恶意数据，毒害知识库，导致 AI 生成的回答被污染或泄露敏感信息。
    • 服务可用性影响 (VA:L): 攻击者可以通过删除核心文档或异常操作，间接导致服务不稳定或部分功能不可用。
    • 声誉与合规风险: 对于企业用户而言，此漏洞可能导致严重的数据安全事件，违反如 GDPR、HIPAA 等数据保护法规。

修复建议

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

  • 立即将 LightRAG 升级到版本 1.5.4 或更高版本。 这是最直接、最有效的修复方式。根据描述，新版本已修复了认证链中的多个弱点，包括移除硬编码的秘密和修正认证顺序。

2. 临时缓解措施

如果无法立即升级，请采取以下临时措施降低风险：

  • 严格配置认证:

    • 同时设置 LIGHTRAG_API_KEY 和 AUTH_ACCOUNTS。 这是官方建议的、安全的部署方式。设置了 AUTH_ACCOUNTS 后，auth.py 将不会回退到使用危险的 DEFAULT_TOKEN_SECRET 逻辑。
    • 避免仅设置 LIGHTRAG_API_KEY 而遗漏 AUTH_ACCOUNTS。 当前漏洞正是此配置下的必然产物。

  • 网络隔离:

    • 将 LightRAG 服务部署在内网或使用防火墙、安全组严格限制对其 API 端点的公网访问。仅允许受信任的 IP 地址或服务进行连接。

  • 部署 Web 应用防火墙 (WAF) 或 API 网关:

    • 配置 WAF 或 API 网关规则，识别并阻止异常的认证行为，例如频繁访问 /auth-status 并携带伪造令牌发往后端 API 的请求。

  • 安全审计与监控:

    • 监控并审计所有访问 LightRAG API 的请求，特别是记录任何使用了 POST /auth-status 和 POST /login 的请求来源、频率及成功/失败状态。

参考资料

分析日期: 2026-07-16