OpenClaw 登陸 AWS，嚴重安全漏洞暴露逾 4 萬個雲端實例

亞馬遜網路服務（AWS）近日在其輕量虛擬伺服器產品 Amazon Lightsail 上推出 OpenClaw 的一鍵式託管部署服務，為這款 AI 代理框架提供簡化的雲端部署方案。然而，此次發布正值 OpenClaw 的安全危機持續發酵之際，報告發現全球 82 個國家共有 42,900 個公開面向的暴露實例。

AWS Lightsail 託管部署：技術細節與定位

AWS 表示，此次整合是為了回應客戶對自行設置 OpenClaw 時面臨複雜配置挑戰的廣泛反映。Lightsail 藍圖預先配置了 Amazon Bedrock（預設整合 Claude Sonnet 4.6），並透過 CloudShell 腳本自動建立所需的 IAM 角色。用戶選擇 OpenClaw 藍圖後，透過瀏覽器與 SSH 憑證配對，即可透過 WhatsApp、Telegram、Slack、Discord 或網頁介面與 AI 代理互動。

從普及背景來看，OpenClaw 的崛起速度驚人：由 Peter Steinberger 於 2025 年 11 月創建（最初命名為 Clawdbot，後歷經 Moltbot 和 OpenClaw 兩次更名），2026 年初病毒式傳播，數週內累積 10 萬顆星，目前已超越 Linux 和 React 成為 GitHub 非聚合軟體項目中星數最高的倉庫。Steinberger 已於今年 2 月加入 OpenAI，OpenClaw 目前已轉型為由 OpenAI 資助的獨立開源基金會。

CVE-2026-25253 與大規模實例暴露：安全現狀全貌

此次 AWS 發布面臨的核心安全挑戰，是一個已被充分記錄的嚴重漏洞及其引發的大規模暴露現象：

CVE-2026-25253（2 月 1 日披露）：影響 2026.1.29 版本前的所有 OpenClaw 部署，允許攻擊者透過竊取 WebSocket 令牌實現一鍵遠端程式碼執行；攻擊者可構造惡意 URL，當用戶點擊後，身份驗證令牌自動傳送至攻擊者控制的伺服器，無需用戶任何其他操作

暴露規模統計：Hunt.io 發現 17,500+ 個暴露實例；Bitsight 在 1 至 2 月間記錄到 30,000+ 個暴露實例；SecurityScorecard 全球掃描確認 42,900 個公開實例，其中 15,200 個已確認存在 RCE 漏洞

雲端部署集中：98.6% 的暴露實例運行在 DigitalOcean、阿里雲、騰訊雲及 AWS 等雲端平台，而非家庭網路，顯示這些實例在企業和開發者環境中廣泛應用

憑證竊取目標：每個 OpenClaw 實例均儲存著 Claude、OpenAI、Google AI 等服務的 API 金鑰，成為攻擊者高優先級的憑證竊取目標

政府層面的回應也已出現：中國工業和資訊化部發布安全警告，韓國科技企業禁止內部使用 OpenClaw。

供應鏈污染與架構性安全風險

除已知漏洞外，安全研究人員還揭示了更深層的結構性問題：

ClawHub 供應鏈污染：Bitdefender 在 OpenClaw 的技能中心 ClawHub 中發現約 900 個惡意套件，佔所有已發布技能的 20%。惡意套件包括偽裝成實用工具的憑證竊取程式、提供持久訪問的後門，以及使用混淆有效載荷繞過程式碼審查的高級惡意軟體。OpenClaw 技能以系統級權限運行，可直接訪問訊息、API 金鑰和檔案，使供應鏈攻擊的影響遠比 npm 或 PyPI 生態更具破壞性。

提示注入攻擊：Giskard 的研究表明，精心構造的提示詞可從正在運行的代理中提取 API 金鑰、環境變數和私密憑證，這是一個 Lightsail 藍圖提供的沙箱機制無法從根本上解決的架構性問題。

AWS 文件承認「執行 OpenClaw 如果操作不當，可能會造成安全威脅」，並建議切勿公開網關、定期輪換令牌、將憑證儲存在環境變數而非配置文件中——但指南並未提供全面的安全加固說明。

常見問題

AWS Lightsail 提供的安全措施是否能保護 OpenClaw 用戶免受已知漏洞影響？

Lightsail 藍圖提供了沙箱執行、裝置配對認證以及自動 TLS/HTTPS 訪問等安全加固措施，可以緩解部分攻擊向量。然而，它無法解決 CVE-2026-25253 等需要升級到特定版本的漏洞（AWS 文件應明確說明版本要求），也無法從根本上解決提示注入攻擊或 ClawHub 供應鏈污染的問題。

企業是否應該在生產環境中部署 OpenClaw？

Token Security 的研究顯示，22% 的組織已有員工在未獲 IT 授權的情況下自行運行 OpenClaw，形成「影子 AI」部署。在正式採用 AWS Lightsail 託管版本之前，企業應完整評估：（1）是否已升級至修復 CVE-2026-25253 的版本；（2）所有 ClawHub 技能的來源是否可信；（3）系統級權限（文件訪問、腳本執行、瀏覽器控制）是否符合組織的安全策略。

OpenClaw 轉為開源基金會模式後，安全問題是否有所改善？

OpenClaw 目前已轉型為由 OpenAI 資助的獨立開源基金會，MIT 授權的社群維護者將繼續推動項目發展。基金會結構理論上提供了更可持續的治理模式，降低了單一維護者的風險。然而，ClawHub 供應鏈污染問題反映的是整個生態系統的審查機制缺失，需要基金會建立更嚴格的套件審核流程，而非僅靠組織架構轉型就能解決。