CVE-2026-18953：AWS 的 Transform MCP 伺服器沒有寫入邊界

Amazon 於 2026 年 8 月 5 日針對 CVE-2026-18953 發布安全公告 2026-075-AWS，該漏洞是 get_resource 工具中的路徑遍歷，而該工具屬於 awslabs.aws-transform-mcp-server，這是一款開源的 Model Context Protocol 伺服器，在開發者自己的機器上執行，讓 AI 助理能驅動 AWS Transform 作業並擷取其產物。0.1.0 至 0.1.4 版未充分限制路徑名稱，而 savePath 參數可將檔案寫到預期工作目錄之外——Amazon 儲存庫中的 GitHub 公告指出，這「可能導致本機程式碼執行」。Amazon 將其評為 8.6 分，屬高風險。修復版本為 0.1.5，且沒有伺服器端或僅靠設定的因應措施，因為易受攻擊的程式碼路徑存在於預設設定中。尚無公開來源記錄曾有人利用此漏洞。完整紀錄及其嚴重性與信心等級，位於 Orca AI Incident Archive，與同月歸檔的 MCP 與代理執行階段事件並列。

一個在開發者工作的地方寫入的 MCP 伺服器

Model Context Protocol 伺服器是賦予助理可呼叫工具的一層，而這個伺服器刻意設計成本地端。Amazon 的公告將其描述為「{{1}}一款開源的 MCP 伺服器，在開發人員的機器上本地執行，並讓以 AI 驅動的助理與 AWS Transform 互動，以執行程式碼轉換工作並擷取其成品。{{/1}}」其在 Python Package Index 上的套件說明指出，它透過 19 項工具公開 Transform 生命週期，管理轉換工作區、工作、連接器、人機協作任務、成品與聊天，並涵蓋大型主機現代化、VMware 移轉、.NET 現代化與自訂程式碼轉換。

那個放置位置正是這個缺陷之所以關鍵的原因。在廠商自家基礎架構上，一台處理檔名不當的伺服器會損壞廠商的儲存空間。這台伺服器卻是以開發者身分執行，位於開發者的家目錄中，緊鄰其 shell 設定與 SSH 金鑰；而 Amazon 所描述的影響並非下載檔案損毀，而是「本機程式碼執行」。附加到該 CVE 的每一項評分都一致指出一點：攻擊向量是本機，而非網路。

公告中所指名的工具，就是將作業產物下載到磁碟的那個工具。 get_resource 接受一個 savePath，用來指定檔案應該存放的位置。問題在於，沒有任何機制阻止該路徑指向別處。

有多糟，又是按誰的算法？

此 CVE 附加了三個分數，而它們並不相符。Amazon 作為編號機構指派了此 CVE，並在 CVSS v3.1 上以向量 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H——本機、低複雜度、無需權限、需要使用者互動、範圍已變更、對機密性、完整性與可用性有高影響。NIST 在 National Vulnerability Database 中的條目有其自身的主要 v3.1 分數 8.8，採用不同的向量 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H：需要低權限、無需使用者互動。兩者都落在 High 等級。分歧在於前置條件——行為者是否已需要一個立足點，以及是否需要說服真人——而不是結果有多糟。

Amazon 對同一 CVE 的 CVSS v4.0 評分為 6.3，中等，向量為 CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H。請閱讀影響指標：脆弱系統本身毫無影響，後續系統則各項皆為高。這正是路徑遍歷突破工具自身邊界的樣態——損害會施加於工具所能觸及的任何對象，因此它落在子系統欄，而脆弱系統得分為零。

CISA 於 2026 年 8 月 6 日對該 CVE 的補充資料，記載了 SSVC 判定為：利用狀態：無、可自動化：否、技術影響：全面。NVD 的記錄最後修改於 2026 年 10 月 23 日，仍同時並列保留 8.6 與 8.8。兩份文件都沒有把另一方視為錯誤。

脆弱的程式碼做了什麼，以及 0.1.5 改了什麼

Amazon 對該機制的描述只有一句話，而且措辭相當謹慎：該工具「未能充分限制路徑名稱」，這可能讓「依情境而定的行為者」得以「透過 savePath 參數，將任意檔案寫入預定工作目錄之外」。該公告並未界定這個行為者、並未說明是什麼觸發寫入，也未描述成功利用會是什麼模樣。它只說結果「可能導致本機程式碼執行」。

關於這套機制，最詳盡的公開說明並非出自 Amazon，而是來自一個小型的概念驗證儲存庫，ronamosa/CVE-2026-18953，於 2026 年 8 月 8 日以 Apache-2.0 授權發佈在 GitHub 上——只有兩次提交，撰寫本文時尚無星標、也無分支——它以逐字副本的形式收錄了易受攻擊版本與已修補版本的 file_validation.py，並以相同輸入驅動兩者。

它對 0.1.4 的解讀是這樣：validate_write_path()解析了savePath使用realpath和expanduser，拒絕了一份簡短的拒絕清單所列的位置（~/.aws、~/.ssh、~/.gnupg、~/.docker、~/.aws-transform-mcp、/etc/shadow、/etc/passwd），並從提供的檔案名稱中移除目錄元件。它從未將解析後的路徑限制於任何基底或工作目錄。敏感檔案名稱的黑名單——.bashrc、.zshrc、authorized_keys、id_rsa——在讀取時會強制執行，但在寫入時不會。

此儲存庫示範了三種它允許的寫入：一個完全不需要路徑遍歷的絕對路徑、一個相對的 ../../ 逃逸，以及一個讀取路徑原本會拒絕的點檔案名稱。這三者全都落在指令碼所建立的暫存目錄內，而其範例輸出顯示dropped_by_absolute_path.sh、dropped_by_traversal.sh以及.bashrc位於一個誘餌家目錄下；真正的家目錄從未被碰觸。版本 0.1.5 補上了缺失的邊界：一個取自$AWS_TRANSFORM_MCP_WRITE_DIR或伺服器啟動工作目錄的基礎目錄，每個解析後的寫入都必須落於其下，再加上套用於最終解析寫入路徑的檔名封鎖清單。修正後的驗證器會對這三者全部提出「Write path must be within the working directory」的錯誤。

這些細節都沒有出現在公告中，而儲存庫也未聲稱它們來自該處。請將拒絕清單、唯讀檔名檢查與基底目錄修正視為根據原始碼所做的重建，而非第二項官方發現。儲存庫在公告之外確實新增的內容，是關於誰能提供該路徑的說明：由於伺服器的職責是將作業與任務內容拉入助理的上下文中，選擇savePath的人不必是坐在鍵盤前的人。助理若受到它透過同一工具所取得的不受信任內容操控，也可能做出這項決定。這是儲存庫根據程式碼與工具設計提出的論點，並非 Amazon 主張的說法；Amazon 未定義的「視情境而定的行為者」與此相符，且僅止於此。

修補程式與公告之間相隔七週

修正並未隨公告一同到來。Python Package Index 的發行歷程——來自該套件所經由之登錄庫的第一方中繼資料——將 0.1.4 標記為 2026 年 5 月 20 日、0.1.5 為 2026 年 6 月 17 日，比 2026 年 8 月 5 日發布的公告 2026-075 早了七週。該索引上根本沒有 0.1.0 檔案；受影響範圍內最早發佈的成品是 0.1.1，於 2026 年 5 月 9 日上傳。因此，從該索引安裝的開發者只可能在 5 月 9 日至 6 月 17 日期間取得有漏洞的組建，而任何持續追蹤發行版本的人，到 6 月中都早已使用已修補的程式碼。

亞馬遜並未說明它何時得知此問題、何時收到通報，或為何關閉該問題的版本會發布。紀錄中唯一被指名的人是 Drew Raines，公告與 GitHub 安全公告都感謝他「透過協調式問題揭露流程就此議題合作」。GHSA-66mr-jr63-2jgw 於 2026 年 8 月 5 日發布於 Amazon 的 awslabs/mcp 儲存庫，與該公告同日；CVE 紀錄於當日 13:44 UTC 預留，並於 19:33 UTC 發布。

因此，修復的日期已確定，但修復的原因並未確定。在安全公告發布前七週，已修補的版本就已出現在註冊表上，這與先低調修復、隨後協調披露的情況相符——但這只是根據兩個時間戳所作的推論，而兩份文件都沒有明說此事。

該紀錄確立了什麼，以及未確立什麼

檔案館將此條目評為 A 級——文獻記錄完善、原始來源一致——且未標記為有爭議。檔案館將其歸類為研究紀錄，屬漏洞發現而非部署事故，且無實際造成危害的紀錄。此評級著重於文件記錄的品質，而就所審查的證據而言，該評級成立：公告、GitHub 安全公告與 CVE 紀錄是三份由 Amazon 發布的文件，對產品、版本、修補程式與致謝對象的記述一致。

• 已確認。Amazon 於 2026 年 8 月 5 日發布公告 2026-075-AWS，涵蓋 CVE-2026-18953，即 get_resource 的 savePath 處理中的 CWE-22 路徑遍歷；該處理位於 awslabs.aws-transform-mcp-server 0.1.0 至 0.1.4 版，已於 0.1.5 版修正，且因為易受攻擊的路徑位於預設組態中，所以沒有伺服器端或僅限組態的因應措施。

• 已確認。 評分及其差異：Amazon 作為 CVE 編號管理機構給出 8.6 高風險，NIST 作為 NVD 主要評分給出 8.8 高風險，CVSS v4.0 為 6.3 中風險，而 CISA 於 8 月 6 日作出的 SSVC 判定指出，尚未觀察到實際利用，也未觀察到可自動化利用路徑。

• 已確認。Python Package Index 上的發布日期，以及對 Drew Raines 協調揭露的致謝。

• 由第三方從原始碼推斷。 拒絕清單、唯讀檔名封鎖清單、不存在的基底目錄，以及 _ALLOWED_WRITE_BASE 修正，全都來自 ronamosa 的概念驗證儲存庫，任何人都可以比對其中內嵌的兩個驗證器版本副本。

• 由時間戳記與設計推斷。 也就是說，0.1.5 是刻意推出的安全性更新，而由不受信任內容操控的助理可能提供該惡意路徑。Amazon 對兩者皆未說明。

• 尚未確認。是否有任何在野利用情形。CISA 的「Exploitation: none」日期為 8 月 6 日，也就是公開概念驗證出現的兩天前，因此它只反映當時的情況，並不代表之後的任何情況。目前尚未公布受影響使用者人數、客戶通知或遙測資料。

• 尚未確立。 獨立報導。似乎沒有主流媒體報導此 CVE。公開紀錄包括 Amazon 的三份文件、NIST 與 CISA 對這些文件的補充資料、重述該紀錄的追蹤頁面，以及上述那個小型概念驗證儲存庫。

有哪些變更，以及要檢查哪些項目

Amazon 的補救措施只是提升版本號，別無其他：升級至 0.1.5 或更新版本，並「確保任何分支或衍生程式碼都已修補，以納入新的修正」。真正會向外擴散的是第二條。該伺服器是開源的，而一個內嵌 0.1.4 驗證器的分支會繼承這個缺陷，卻不會繼承這份公告；公告要求衍生程式碼的營運者將變更帶入其中，也就是說，上游發行版並不會觸及由他人維護的副本。

概念驗證儲存庫提出了安全公告不願提出的建議。公告指出，無法立即升級的維運人員應將伺服器的工作目錄設為專用的空目錄，並將伺服器可寫入的任何檔案視為已遭入侵。Amazon 的立場更為嚴格：完全沒有伺服器端或僅靠設定的變通辦法。根據該儲存庫本身的說法，這項建議也很薄弱，因為有漏洞的程式碼從一開始就從未將寫入限制在工作目錄內。在兩者不一致之處，應以廠商僅能升級的指示為準。

這份紀錄有用之處不在於它的分數，而在於它的形態：一個本機 MCP 伺服器、一次由呼叫端提供目的地的產物下載，而兩者之間沒有任何界線。真正要檢查的不是公告日期，而是固定版本——0.1.5 或更新版本，並且把同樣的變更帶入任何複製了驗證器的分支。