2026年，OpenClaw讓AI真正長出了“手腳”。

它不再是那個只會“紙上談兵”的聊天機器人，而是能幫你訂機票、改代碼、管文件的“全能私人助理”。無數打工人正滿懷期待地安裝這只“龍蝦”，夢想著從此當上“小老板”，免于機械重復的工作。

然而，這種前所未有的“自主行動”能力，也投下了前所未有的安全陰影。

就在近期，針對OpenClaw的CVE-2026-25253遠程代碼執行（RCE）漏洞曝出，讓不少想跟風“養龍蝦”的人冷靜下來。攻擊者只需在網頁或文件中埋下一段惡意提示詞，就能誘導“龍蝦”反水，向系統后臺發出毀滅性的指令。

這個漏洞精準指向了語言大模型（LLM）一個極其隱蔽且致命的軟肋——輸出處理不當（Insecure Output Handling）。盡管它在OWASP的《大型語言模型與生成式AI十大風險2025》（OWASP LLM TOP 10）中只排名第五（LLM05），但它對智能體（AI Agent）而言，卻是危害巨大的“定時炸彈”。當負責智能體決策的LLM被人“洗腦”或突然“大腦短路”，下發了惡意指令，你以為無比聽話的“私人助理”，極有可能在瞬間變成拆掉你整個后臺系統的“頭號內鬼”。

什么是輸出處理不當？

輸出處理不當，特指語言大模型（LLM）生成的輸出內容在傳遞給下游其他組件和系統（如Web瀏覽器、后端數據庫、操作系統Shell、第三方擴展）之前，缺乏充分的驗證、清理和處理。

想要理解輸出處理不當，區分它與LLM02 敏感數據泄露和LLM09 錯誤信息，先要理解大模型的產品架構與應用場景。

大模型本身不具備物理破壞性，但是當它在產品架構、智能體架構中擔任“決策者”，它生成的文本被作為指令傳遞給另一個組件（如下游的數據庫插件或瀏覽器）時，風險就隨之產生。如果瀏覽器、解析器等接收端組件盲目執行了模型提供的輸入，就相當于為用戶（或攻擊者）提供了一個通往系統深處的“間接訪問通道”。一旦輸出內容包含JavaScript代碼、SQL注入語句或系統Shell命令等惡意指令，就會觸發代碼執行類漏洞，對系統形成攻擊。

造成輸出處理不當的原因有二。一是來自外部的攻擊，攻擊者可以通過提示詞注入、供應鏈攻擊等方式，惡意誘導大模型輸出不當內容，如包含DROP TABLE的惡意SQL指令，致使數據庫遭到破壞。二是大模型自身的缺陷，由于大模型幻覺、訓練數據偏差等原因，向下游組件發送錯誤指令，如在生成代碼時，調用存在安全缺陷的非參數化SQL語句，引發注入風險。

弄清了輸出處理不當的作用機制、產生原理，就能區分它與同樣關注大模型輸出端（Output）的LLM02與LLM09。LLM02 敏感數據泄露關注的是敏感信息如何從模型中“流出”；而輸出處理不當關注的是模型輸出的內容如何變成“病毒”，破壞下游系統的“運行安全”。LLM09 過度依賴關注的是人或決策環節對AI輸出準確性的盲信；而輸出處理不當關注的是技術驗證環節，側重于輸出在傳遞給下游組件之前的安全處理。

輸出處理不當會引發哪些安全風險？

當系統將大模型的輸出視為受信任的“內部指令”時，攻擊者可以通過間接提示注入等手段，將大模型變成破壞系統的武器，發動以下攻擊：

1.遠程代碼執行 (RCE)

這是輸出處理不當最致命的后果。如果應用程序將大模型生成的內容直接輸入到系統 Shell或具有執行功能的函數（如 exec() 或 eval()）中，攻擊者就能通過誘導模型生成刪除系統關鍵文件的指令，從而完全控制服務器。這正是OpenClaw漏洞的核心表現形式。

2.跨站腳本攻擊

當大模型生成包含JavaScript的內容并返回給用戶瀏覽器時，如果瀏覽器未做轉義直接渲染執行，就會引發XSS攻擊。攻擊者可以借此竊取用戶的會話信息（Cookies），或者在受害者的瀏覽器上執行任意操作。

3.SQL 注入

在數據分析類智能體中，大模型常被要求生成SQL查詢指令。如果這些生成的SQL語句在未進行參數化處理的情況下被后端直接執行，攻擊者就可以誘導模型輸出惡意查詢（如刪除表的指令），導致整個數據庫癱瘓或數據泄露。

4.路徑遍歷與系統破壞

如果大模型輸出的內容被用于構建服務器上的文件路徑（例如“幫我重命名這個文檔”），而系統未進行適當的清理，攻擊者可能誘導模型訪問受限目錄，導致敏感系統文件被讀取或修改。

5.供應鏈污染與惡意軟件包

大模型產生的“幻覺”可能導致它虛構出一個并不存在的代碼包名稱。攻擊者可以預先在公開倉庫注冊一個同名的惡意包。如果開發人員過度依賴AI的建議且未進行代碼審查，就可能在自動化部署流程中引入被感染的資源，致使系統遭到破壞。

如何防范輸出處理不當？

防范輸出處理不當的核心，是以“零信任”為根本指導原則，給大模型的輸出加上一道嚴格的“安全安檢”，徹底剝離其“未經授權的指令執行”特權，從架構底層杜絕AI輸出未經校驗直接變為系統可執行指令的風險。

1.輸出內容“零信任”，從源頭攔截不可信內容

把大模型的輸出視作不可信的外部輸入，而非內部可信指令。對所有傳遞給下游組件的模型響應，都執行嚴格的校驗、過濾與合規檢查，參照OWASP安全驗證標準（ASVS）建立標準化處理流程，從源頭攔截異常與惡意內容。

2.實施上下文感知編碼，剝離大模型輸出執行特權

根據輸出的下游場景做針對性轉義與處理：面向瀏覽器的內容應完成HTML轉義，避免代碼被直接執行；接入數據庫的操作強制使用參數化查詢，從根源杜絕SQL注入風險；對面向系統組件的指令做格式與內容校驗，僅放行合規內容。

3.落實“最小化授權”與沙箱隔離，隔離并鎖定風險

遵循“最小化授權”原則，僅為AI分配完成任務所需的最低權限，絕不賦予超額操作能力。同時將AI的指令執行放在隔離沙箱中運行，與核心系統、敏感數據做物理或邏輯分隔，即便輸出異常也無法波及核心資產。

4.強化日志審計與風險監控，實時阻斷安全風險

建立全鏈路日志記錄與實時監控機制，追蹤模型輸出的執行軌跡，識別異常指令、高頻高危操作等攻擊特征。通過異常檢測與速率限制，在漏洞利用造成實質破壞前快速攔截、阻斷風險。

OpenClaw RCE漏洞的爆發提醒我們，智能體的“行動力”越強，對于其“大腦”（LLM）的管理就必須越嚴格。在大模型仍普遍處于“黑盒”狀態時，它生成的每一行文本在轉化為影響物理世界的實際行動前，都必須經過徹底的“安檢”與轉義處理。絕不能讓未經審計的輸出直接流入下游組件，從而獲得操縱現實的權限。

防范LLM05 輸出處理不當，本質上是消除AI系統中的“過度信任”。只有在底層邏輯上堅持“數據歸數據，指令歸指令”，通過實施零信任驗證、上下文編碼以及必要的人工確認（Human-in-the-Loop），才能筑起安全長城，在享受AI帶來效率革命的同時，確保企業數字資產安然無恙。