CVE-2026-75130：Context7 的 MCP 文档服务器获评 9.0 分，且记录中未注明修复版本

2026 年 8 月 18 日，VulnCheck 针对 Context7 发布了 CVE-2026-75130。Context7 是 Upstash 为模型上下文协议运行的库文档服务器，编程智能体会向它查询特定版本文档。该漏洞位于 Upstash 称为 Custom AI Instructions 的功能中：库所有者将指导信息附加到某个文档条目上，Context7 会把该指导信息提供给每个查询该库的智能体的上下文窗口，而这条路径上没有任何环节会对其进行清理。Noma Security 的高级 AI 漏洞研究员 Eli Ainhorn 被列为发现者；该公司演示了被投毒的条目可使已连接的智能体读取项目根目录中的 .env 文件，将其内容作为 issue 发送到攻击者控制的 GitHub 仓库，并以“清理”为借口删除本地文件夹——这一切都源自一次常规文档请求。未记录到受害者。 其余有记录的智能体事件各自带有严重性、置信度评级和争议标记，均收录于 AI 事件归档，可在其中与此记录相邻的条目并排阅读。

Context7 的服务器很小，而这是首先值得理解的部分。Noma 的文章指出，它提供两个工具：resolve-library-id 和 query-docs，并且它自身无法执行代码、写入文件或访问网络。所有有记录的影响都是由另一端的智能体实施的，而该智能体确实拥有开发者机器上的文件系统、shell 和网络访问权限。npm registry 显示了其安装基数有多大：@upstash/context7-mcp 在 2026 年 7 月 22 日至 8 月 20 日之间的三十天内被下载了 4,064,176 次，这正是发布前后的时间窗口。

机制：一个被投毒的库，每一个查询它的智能体

Noma 在其 2026 年 3 月 5 日的 ContextCrush 说明中描述的演示分三步进行，这些步骤由代理而非服务器执行。它在 Context7 的注册表中注册了一个附带投毒规则的库。这些规则中的指令指示代理搜索并读取项目根目录中的每个 .env 文件；进一步的指令指示它将内容作为 issue 发布到由攻击者控制的 GitHub 仓库；最后一组指令则要求它为“清理”而删除本地文件夹和文件。将所有这一切拉入上下文的请求很普通——向编码助手寻求某个库的帮助。

这是一个供应链问题而非普通提示注入，原因在于恶意载荷所在的位置。攻击者从不会接触受害者的机器，也无需把文本植入用户打开的文档。被投毒的指令存放在 Context7 自己的注册表中，由 Context7 自己的基础设施托管和提供，并通过与合法文档相同的受信任渠道到达，与合法文档无法区分。Noma 指出，Context7 的信任评分——它根据库背后的 GitHub 历史记录对库进行评分——并不能防御这种情况，因为一个长期存在的账号可以被购买、劫持或伪造。该公司自己对这一结构性问题的最直白总结是：“攻击面不在于 MCP 服务器能做什么，而在于它能促使 AI 智能体做什么。”

一个缺陷，两个评分

该公告载有 CVSS 3.1 9.0（严重）和CVSS 4.0 6.4（中等）。这两个向量均由作为分配 CNA 的 VulnCheck 提供，NVD 则原样收录两者，并将各自归于 VulnCheck。这种评分差异并非错误；只是两个框架针对不同机器计算同一损害。CVSS 3.1 将 Scope 标记为 Changed——注入从服务器跨越到开发者的机器乃至更远——因此按完整权重计入该智能体能力所带来的高机密性、完整性和可用性影响。CVSS 4.0 用分别针对易受攻击系统和后续系统的指标取代 Scope：它记录 Context7 本身没有机密性、完整性或可用性影响（VC:N/VI:N/VA:N），而对下游系统有高影响（SC:H/SI:H/SA:H），其公式对此的权重较轻。服务器是信使，而非受害者。

这种分歧蔓延到了数据库。GitHub 的公告，GHSA-97r6-3rgm-v39r，于 8 月 18 日 18:32 UTC 发布，比 CVE 晚半小时，其摘要严重性显示为中危，尽管同一记录中的 CVSS 3.1 向量评分为 9.0。ENISA 的欧盟漏洞数据库将该条目镜像为EUVD-2026-61099，并且仅在 4.0 版本下存储 6.4 的基础评分。本文所依据的存档记录将该事件评为高危——这既不是两个已发布评分中的任何一个——而且这是存档的评级，并非其自身的测量值。

一个针对三月披露、于八月发布的 CVE

CVE 标识符于 2026 年 8 月 17 日被预留，并于 8 月 18 日 18:02 UTC 发布，这也是该记录所载的日期。CNA 容器还包含第二个日期，该日期未出现在聚合器页面上：datePublic，2026 年 3 月 5 日——比该标识符存在早五个半月，并且是 Noma 发布 ContextCrush 的同一天。该公告唯一的技术参考就是那篇 3 月的文章，VulnCheck 将其标记为同时包含技术描述和漏洞利用。

Noma 的披露时间线解释了这一时间差。它于 2026 年 2 月 18 日向 Upstash 报告该漏洞，并附上完整报告和概念验证；记录 Upstash 于 2 月 19 日接受这些发现并开始修复；称修复已于 2 月 23 日“通过规则净化和护栏部署到生产环境”；并将公开披露和 Noma 的最终验证定于 3 月 5 日。按 Noma 的说法，这个二月的漏洞在几天内就解决了。

npm registry 上的日期与那条时间线恰好对得上，使得受影响的范围看起来颇为蹊跷。@upstash/context7-mcp 2.1.2发布于 2026 年 2 月 23 日 10:06 UTC，正是 Noma 所称修复进入生产环境的那一天；其更新日志中写道“移除不必要的警告并更新工具描述”。2.1.3随后于 2026 年 3 月 4 日发布，即 Noma 文章发布的前一天，其说明提到在 MCP 端点上拒绝 GET 请求，并为搜索结果新增了一个来源字段。这两份发布说明均未提及净化处理、防护措施或该注入问题。CNA 的受影响范围止于 2.1.2，因此 2.1.3 成为首个不在该范围内的版本。

这三种解读都与上述日期相符，而 VulnCheck 与 Noma 均未说明哪一种才是正确的。第一种解读由 Digital Applied 在其 8 月 18 日的文章中提出，并由 AI Security Wire 于 8 月 22 日转述：该修复出现了回归——承载 2 月补丁的那个构建正落在 8 月的受影响范围内。第二种解读是：该版本范围只是以研究者所测试的那个构建为锚点，而真正边界是披露前一天发布的 2.1.3——这是若干聚合器机械套用得出的推断，其中包括 Feedly，它把“升级到 2.1.3 或更高版本”列为缓解措施。第三种解读是：2 月的修复是在规则分发侧而非客户端包中实施的，若如此，npm 版本范围根本就不能描述该修复。静默安全修复本就相当常见，因此缺少对应的更新日志条目并不能说明任何一方的问题。

什么是已确立的，什么不是

• 由主记录确立。 CVE 标识符、其 8 月 18 日的发布、VulnCheck 作为 CNA、针对用于 LLM 提示的输入未正确中和而作出的 CWE-1427 分类、对 Noma Security 的 Eli Ainhorn 的致谢，以及 Context7 直至 2.1.2 的受影响版本范围。

• 由 Noma 的研究所确立。 通过 Custom AI Instructions 的注入路径、三步概念验证、服务器仅暴露 resolve-library-id 和 query-docs 的观察结果，以及关于二月漏洞未观察到野外利用证据的陈述。

• 由注册表确定。2.1.2 于 2026 年 2 月 23 日发布，2.1.3 于 2026 年 3 月 4 日发布，以及一条此后已越过 4.0、并于 2026 年 10 月 19 日达到 4.4.4 的包版本线。

• 尚未确定：当前构建版本是否受影响。 没有任何来源称 4.x 系列存在漏洞，也没有任何来源称其不受影响。CVE 记录、VulnCheck 公告和 GitHub 公告均未列出修复版本，且 GitHub 公告的受影响版本范围列表为空。

• 未证实：任何受害者或实际环境中的利用。该档案将实际危害记录为不实。CISA 于 8 月 19 日对该记录的补充评估将“利用”评为“无”，“可自动化”评为“否”，“技术影响”评为“完全”；该漏洞不在 KEV 目录中；ENISA 的镜像记录显示 EPSS 为 0.49%。Noma 的研究是演示，而非事件报告。

• 尚未证实：回归这一解读本身。它依据的是修复时间线与一次 npm 发布之间的日期巧合，且没有任何一手资料断言同一代码路径曾两次失败。

佐证：重述，以及在关键之处保持沉默

与记录一致的文件在很大程度上源自该记录。VulnCheck 的公告重述了 CVE 文本，并补充了弱点分类和研究人员的署名致谢。GitHub 公告是同一提交的别名，于同晚发布，未包含版本范围，也未经过独立审查。ENISA 的条目是一个镜像。Digital Applied 是该档案引用的两个来源之一，于 8 月 18 日发布其分析，并于 8 月 22 日更新，加入了最新的注册表拉取数据；AI Security Wire 于 8 月 22 日发布了第二篇报道。两者都重述了该公告并转述了回归推断，且均未声称已独立验证。

我们未发现任何新闻媒体对 2026 年 10 月 29 日该 CVE 的报道——没有 BleepingComputer、The Register 或 SecurityWeek 的相关条目——搜索结果也只是 CVE 聚合页面，而非新闻报道。这种缺失关系到应如何解读该记录：档案将其评为 A 级，文档完备且原始来源彼此一致；原始来源确实一致，但此处的一致是 CNA 记录与其所引研究之间的一致，而非两项独立测量之间的一致。若干聚合页面添加了其来源并不支持的说法；例如，Feedly 的条目称已有补丁可用并点名 2.1.3，而没有任何公告这样表述，VulDB 的页面则返回了机器人验证而非内容，完全无法阅读。

哪些变了，哪些没变

就二月的漏洞而言，按 Noma 的说法，Upstash 在几天内就采取了行动：2 月 19 日受理，2 月 23 日修复。就八月的记录而言，CVE 引用的唯一供应商声明是 Upstash 在 LinkedIn 上的一篇帖子，该帖在那里被标记为供应商公告，而我们没有会话就无法读取其内容。没有任何针对该仓库的 GitHub 安全公告包含修复版本，而 NVD 的条目处于以下状态：已推迟，并且没有 CPE 配置，最后修改时间为 2026 年 10 月 22 日，因此 NVD 自身的分析并未记录在案。

这个软件包本身仍在持续发布。在 {{1}}2025年4月20日{{/1}} 至 {{2}}2026年10月23日{{/2}} 期间，{{3}}upstash/context7{{/3}} 仓库共发布了 163 个版本，而其中没有任何发布说明提到这个 {{4}}CVE{{/4}}，也没有描述对携带注入内容的自定义指令进行清理。这只是维护者选择记录下来的内容，并不能证明没有任何问题被修复。

这份记录留给运维人员的是暴露面管理，而不是一条补丁线。Noma 的建议核心是审查 MCP 集成，并检查运行时智能体与服务器之间传递的内容；OpenCVE 建议采取的行动是升级、禁用或限制 Custom AI Instructions 功能，并为服务器增加输入验证。所有这些在操作层面都归结为同样的三项举措：锁定 MCP 服务器版本，而不是浮动使用 latest；将生产凭据排除在智能体可读取的明文环境文件之外；将工具响应视为不可信输入，而不是智能体可能照做的文档。

发布十周后，公开记录仍止步于 8 月 18 日：一个标识符、两个相差两个档位的评分、一个受影响范围——其上限是 2 月发布的某个构建版本——以及没有指明任何修复方案。任何负责对 CVE-2026-75130 进行分类处置的人，都必须根据其代理程序所能触达的范围来作决定，因为记录并未告诉他们该安装哪个版本。