Claude Code被利用安全漏洞，僅憑"樂于助人"就可觸發攻擊

Mozilla 旗下 0din 團隊的研究人員發現，Claude Code 可被操控，在開發者設備上悄然開啟一個隱藏的反向 Shell（遠程控制通道）。

整個攻擊過程無需在克隆的項目中植入任何惡意代碼，所有可見文件均可通過常規審查，不會引發任何警覺。危險指令并非預先埋伏在代碼中，而是在運行時從一條 DNS 文本記錄中動態獲取——而這類記錄根本不在任何掃描工具的檢測范圍之內。

攻擊鏈：從一條錯誤提示到完全失控

此次攻擊以一個普通的 Markdown 文件為起點，其內容僅是說明如何安裝一款名為 Axiom 的常見監控工具。在未完成初始化的情況下運行該工具，會彈出一條平平無奇的錯誤提示，并指示用戶執行一條特定的配置命令。

研究團隊指出，這種模式與開發者日常排查問題的操作高度相似，這也正是它能夠順利規避警惕的核心原因。Claude Code 出于"幫助用戶"的本能，自動遵循了文檔中的這條指令，將其視為常規的錯誤恢復操作加以執行。

就是這一條命令，觸發了一段隱藏的 Shell 腳本。腳本隨即悄悄向攻擊者完全掌控的 DNS 文本記錄發起查詢，該記錄中包含一段經過 Base64 編碼的反向 Shell 命令，命令在靜默狀態下執行后，直接連回了攻擊者的遠程服務器。

一旦獲得訪問權限，攻擊者還可植入 SSH 密鑰或設置隱藏的定時任務（cron job）以維持持久控制。更令人擔憂的是，只需將一個包含惡意倉庫的鏈接發布在招聘帖或聊天消息中，每一位打開該鏈接的開發者都將面臨同等風險。

傳統安全工具為何形同虛設

常規安全工具——無論是殺毒軟件還是防火墻——均未能察覺這一漏洞，原因在于每個獨立步驟單獨來看都毫無異常。靜態代碼掃描工具只識別到了一次普通的 DNS 查詢，無從判斷其背后的惡意意圖；網絡監控系統記錄到的也不過是正常的域名解析請求；而 Claude Code 本身則將該命令視為已獲授權的常規配置操作予以執行。

0din 團隊強調，編程智能體在執行任何腳本之前，必須嚴格核查該腳本的實際運行內容。他們同時告誡開發者：無論一個陌生倉庫的配置文件看起來多么正常，都不應想當然地認為它是可信的。

此次事件也揭示出一個更深層的問題：基于大語言模型構建的智能體 AI 工具，可能需要遠比現在更為強健的運行時安全防護機制。在這類智能體真正具備評估指令實際執行內容的能力之前，類似的間接攻擊將始終難以防范。

這一教訓并不局限于 Claude Code 本身——大多數智能體 AI 系統在面對間接提示注入攻擊時，都存在相似的盲區。就目前而言，對陌生自動化操作保持警惕、將其視為真實風險加以對待，仍是普通開發者所能采取的最可靠防護手段。

Q&A

Q1：Claude Code 是怎么被攻擊者利用的？

A：攻擊者通過在項目中放置一個普通的 Markdown 安裝說明文件，誘導 Claude Code 執行一條"錯誤恢復"命令。該命令觸發隱藏腳本，腳本再從攻擊者控制的 DNS 文本記錄中獲取經 Base64 編碼的反向 Shell 命令，最終在開發者設備上悄然建立與攻擊者服務器的連接，整個過程無需任何惡意代碼預先植入項目文件中。

Q2：為什么殺毒軟件和防火墻檢測不到這種攻擊？

A：因為攻擊鏈中的每一個步驟單獨來看都完全正?！狣NS 查詢是常見的網絡操作，Markdown 文件通過代碼審查，Claude Code 也只是執行了一條"文檔記錄在案"的配置指令。靜態掃描工具、網絡監控和防火墻均無法將這些分散的正常行為關聯成一次攻擊，因此整個過程對傳統安全工具幾乎是隱形的。

Q3：開發者應該如何防范這類針對 AI 編程工具的攻擊？

A：0din 團隊建議，開發者在使用編程智能體時，應在執行任何腳本前仔細核實其實際運行內容，不要因為配置文件看起來普通就默認信任陌生倉庫。此外，對來源不明的倉庫鏈接（尤其是通過招聘帖、聊天消息傳播的）應保持高度警惕，將所有陌生的自動化操作視為潛在風險。