CVE-2026-75130：Context7 的 MCP 說明文件伺服器評分為 9.0，且該紀錄未列出已修正版本

2026 年 8 月 18 日，VulnCheck 針對 Context7 發布 CVE-2026-75130；Context7 是 Upstash 為 Model Context Protocol 營運的函式庫文件伺服器，供程式設計代理程式查詢特定版本的文件。此缺陷位於 Upstash 稱為「Custom AI Instructions」的功能：函式庫擁有者可將指引附加至文件條目，Context7 會把該指引提供到每個查詢該函式庫的代理程式上下文視窗中，而該路徑上沒有任何環節會對其進行清理。Noma Security 的資深 AI 漏洞研究員 Eli Ainhorn 被列為發現者；該公司示範了遭汙染的條目可使已連線的代理程式讀取 .env 檔案（位於專案根目錄），將這些內容以問題單形式傳送至攻擊者控制的 GitHub 儲存庫，並以「清理」為藉口刪除本機資料夾——這一切都只源自一次例行的文件請求。未記錄到任何受害者。其餘已記錄的代理程式事件各自有其嚴重性、信心等級與爭議標記，均收錄於 AI 事件檔案庫，本記錄的鄰近條目可與其並列查閱。

Context7 的伺服器規模很小，而這正是首先值得理解的地方。Noma 的文章指出，它提供兩個工具，resolve-library-id與query-docs，而且它本身無法執行程式碼、寫入檔案或連上網路。每一項有文件記載的影響，都是由另一端的代理程式所執行，而該代理程式確實能在開發者的機器上存取檔案系統、shell 與網路。npm registry 顯示其安裝基礎有多龐大：@upstash/context7-mcp已被下載4,064,176次；統計期間為 2026 年 7 月 22 日至 8 月 20 日的三十天，正是發布前後。

機制：一個被投毒的函式庫，每個查詢它的代理程式。

Noma 的示範（刊載於其 2026 年 3 月 5 日的 ContextCrush 文章）分為三個步驟，這些步驟由代理程式而非伺服器執行。它在 Context7 的註冊表中註冊了一個函式庫，並附上帶有惡意規則的規則集。這些規則中的指示要求代理程式搜尋並讀取專案根目錄中的每個 .env 檔案；進一步的指示要求它將內容以 issue 形式發佈到由攻擊者控制的 GitHub 儲存庫；最後一組指示則要它刪除本機資料夾與檔案以進行「清理」。將這一切帶入上下文的請求其實很普通——就是請程式設計助理協助處理某個函式庫。

這之所以是供應鏈問題，而非普通的提示注入，原因在於惡意載荷所在的位置。攻擊者從未接觸到受害者的機器，也無須在使用者開啟的文件中植入文字。被投毒的指令位於 Context7 自家的註冊表上，由 Context7 自己的基礎設施託管與提供，並透過與合法文件相同的受信任通道送達，難以與之區分。Noma 指出，Context7 的信任分數——依據函式庫背後的 GitHub 歷史來評分——無法防禦此攻擊，因為長期存在的帳號可被購買、劫持或捏造。該公司自己對這個結構性重點的總結很直白：「攻擊面不在 MCP 伺服器能做什麼，而在於它能讓 AI 代理做什麼。」

同一個 bug，兩個分數

此安全公告載明 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 的 EU Vulnerability Database 將該條目鏡像為EUVD-2026-61099，且僅在 4.0 版下儲存 6.4 的基礎分數。本文所依據的存檔記錄將這起事件評為高——而這並非上述兩個已公布分數中的任何一個——這是該存檔記錄的評級，並非其自行量測的結果。

一項於八月發布、針對三月披露的 CVE

此 CVE 識別碼於 2026 年 8 月 17 日保留，並於 8 月 18 日 UTC 18:02 發布，這也是記錄所載的日期。CNA 容器還帶有第二個日期，未出現在彙總頁面上：datePublic，2026 年 3 月 5 日——比該識別碼存在早五個半月，且與 Noma 發布 ContextCrush 是同一天。該公告唯一的技術參考是那篇 3 月文章，VulnCheck 將其標註為技術描述與漏洞利用。

Noma 的披露時間軸說明了這段空檔。它於 2026 年 2 月 18 日向 Upstash 通報該漏洞，並附上完整報告與概念驗證；記錄 Upstash 於 2 月 19 日接受這些發現並開始修復；表示修正已於 2 月 23 日「以規則淨化與防護欄部署至生產環境」；並將公開披露與 Noma 的最終驗證日期訂為 3 月 5 日。根據 Noma 的說法，2 月的錯誤在幾天內就解決了。

npm 註冊表的日期與該時間線吻合，但這種吻合方式讓受影響的版本範圍顯得古怪。@upstash/context7-mcp 2.1.2於 2026 年 2 月 23 日 10:06 UTC 發布，正是 Noma 所說修復進入生產環境的那一天；其變更日誌寫道：「移除不必要的警告並更新工具描述。」2.1.3接著於 2026 年 3 月 4 日發布，也就是 Noma 撰文的前一天，其說明提到在 MCP 端點上拒絕 GET 請求，並在搜尋結果中新增 source 欄位。兩份發布說明都未提及清理、防護機制或該注入問題。CNA 的受影響範圍結束於 2.1.2，因此 2.1.3 是第一個落在範圍外的版本。

這三個日期對應三種解讀，而 VulnCheck 與 Noma 都未說明哪一種才正確。第一種說法由 Digital Applied 在其 8 月 18 日的文章中提出，並經 AI Security Wire 於 8 月 22 日重述，主張該修補程式出現回歸：搭載二月修補程式的組建，落在八月的受影響範圍之內。第二種說法是，該範圍僅以研究人員所測試的組建為錨點，而於披露前一天發布的 2.1.3 才是真正的邊界——這是多家彙整服務機械式做出的推論，包括 Feedly，其將「更新至 2.1.3 或更新版本」列為緩解措施。第三種說法是，二月的修補程式套用在規則被提供的位置，而非用戶端套件中，如此一來，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 的頁面回傳機器人驗證而非內容，完全無法閱讀。

哪些改變了，哪些沒有

就二月的漏洞而言，Upstash 在幾天內便採取行動：依 Noma 的說法，2 月 19 日受理，2 月 23 日修復。至於八月的記錄，CVE 所引用的唯一供應商聲明，是 Upstash 在 LinkedIn 上的一則貼文，在該處被標記為廠商公告，若無工作階段，我們無法讀取其內容。沒有任何針對該儲存庫的 GitHub 安全公告載明已修復的版本，而 NVD 的條目狀態為 Deferred，且無 CPE 組態，最後修改時間為 2026 年 10 月 22 日，因此 NVD 自身的分析並不在記錄之中。

套件本身仍持續發佈。在 2025 年 4 月 20 日至 2026 年 10 月 23 日之間，upstash/context7 儲存庫發佈了 163 個版本，而其中沒有任何版本的說明提及這個 CVE，或描述如何清理那些承載注入內容的自訂指令。這只是維護者選擇寫下哪些內容的紀錄，並非什麼都沒修復的證明。

這份記錄留給操作員的是曝險管理，而不是修補線。Noma 的建議重點在於檢視 MCP 整合，並檢查執行階段中代理與伺服器之間傳遞了什麼；OpenCVE 建議的行動則是升級、停用或限制 Custom AI Instructions 功能，以及為伺服器加入輸入驗證。上述一切在營運層面的版本，都是同樣的三個動作：固定 MCP 伺服器版本，而不是浮動跟著 latest；讓生產憑證不要留在代理可讀取的明文環境檔案中；以及把工具回應視為不受信任的輸入，而不是代理可能照著遵循的文件。

發表十週後，公開紀錄仍停留在 8 月 18 日的狀態：一個識別碼、兩個相差兩個等級的分數、一個受影響範圍（其上限是二月出貨的組建版本），以及沒有指名任何修復程式。負責分類處置 CVE-2026-75130 的人，只能依自家代理程式能觸及的範圍自行判斷，因為紀錄並沒有告訴他們該安裝哪個版本。