360安全龍蝦泛域名私鑰泄漏，打進了安裝包

近日，安全社區發現：360 剛發布的 AI Agent 產品 "360安全龍蝦" （基于 OpenClaw 的一鍵部署客戶端），在其公開安裝包中，包含了 *.myclaw.360.cn 泛域名證書的 SSL 私鑰文件 。

一家以安全為核心賣點的公司，把自己的通配符證書私鑰，打包進了面向公眾分發的安裝包里。

聲明：本文僅作為網絡安全技術探討與供應鏈安全案例分析。文中引用的技術數據及文件路徑均來自公開網絡渠道及官方公開發布的軟件安裝包，不涉及任何逆向工程、破解或入侵行為。本文所述內容均基于公開信息與可獨立驗證的技術事實，不構成對任何公司的主觀評價。如相關廠商已發布官方修復公告，請以官方信息為準。

發生了什么

360安全龍蝦于 2026年3月14日正式發布，定位是 OpenClaw 智能體的一鍵安裝部署工具。

安全研究人員在解壓安裝包后發現，在以下路徑中存在明文的證書與私鑰文件：

/path/to/namiclaw/components/Openclaw/openclaw.7z/credentials

該目錄下包含了 *.myclaw.360.cn 的 Wildcard DV 泛域名證書及其對應的 RSA 私鑰。

證書由 WoTrus（沃通）CA 簽發，有效期從 2026年3月12日至 2027年4月12日，覆蓋 *.myclaw.360.cn 下的所有子域名。

技術驗證

據安全博客"秋風于渭水"的獨立驗證，通過標準的 OpenSSL 工具分別提取私鑰和證書中的 Modulus（模數），進行 MD5 哈希比對，兩者的指紋完全一致，在技術上證實了該 .key 文件確為對應泛域名證書的有效私鑰。

此外，X（原 Twitter）上多位用戶已公開貼出該證書的完整 PEM 編碼內容，任何人均可自行下載驗證。證書透明度日志（crt.sh）中亦可查詢到對應記錄。

老馮也在本地使用 OpenSSL 對上述證書和私鑰文件進行了獨立驗證，Modulus 哈希比對結果與上述報告一致。

這意味著什么

SSL 私鑰是 HTTPS 加密通信的核心。持有某域名的 SSL 私鑰，在技術上意味著：

1. 中間人攻擊（MITM）

在公共 Wi-Fi、企業內網、運營商鏈路等場景下，第三方可以利用該私鑰偽造 *.myclaw.360.cn 下任意子域名的合法 HTTPS 服務。由于證書本身是合法簽發的，客戶端不會彈出任何安全警告，用戶的加密流量可被實時解密。

2. API Key 截獲風險

360安全龍蝦作為 OpenClaw 部署工具，用戶在使用過程中通常會配置各類大模型的 API Key。如果客戶端與 *.myclaw.360.cn 之間的通信被中間人劫持，這些 API Key 存在被明文截獲的風險。

3. 供應鏈劫持

如果客戶端的自動更新、配置下發等機制依賴于該域名的 HTTPS 驗證，攻擊者理論上可以偽造服務器，向客戶端推送未經授權的指令或代碼。

需要說明的是，以上是泛域名私鑰泄露后在技術層面客觀存在的風險面，并不代表這些攻擊已經實際發生。

證書吊銷與 OCSP 的尷尬

根據 CA/Browser Forum Baseline Requirements（4.9.1.1 章節），當 CA 意識到證書私鑰可能已遭泄露時，應在 24小時內 執行吊銷操作。本次事件的時間線如下：

時間

事件

2026-03-12

WoTrus 簽發 *.myclaw.360.cn 證書

2026-03-14

360安全龍蝦正式發布，安裝包公開分發

2026-03-15

安全社區發現并公開討論私鑰泄露問題

2026-03-16 08:07 UTC

據"秋風于渭水"博客報告，證書 OCSP 狀態變更為 Revoked（已吊銷）

證書目前名義上已被吊銷。但事情遠沒有這么簡單。

主流瀏覽器對 OCSP 通常采用"軟失敗"（Soft-Fail）策略：如果無法訪問 OCSP 服務器，瀏覽器會默認放行而非拒絕連接。換句話說，能做中間人攻擊的人，順手攔截掉 OCSP 流量也不是什么難事——僅靠 OCSP 吊銷并不能完全消除已泄露私鑰的威脅。

更有意思的是老馮的實測結果。2026年3月16日晚間 22:14，老馮使用 OpenSSL 對 OCSP 狀態進行驗證，返回結果竟然是 "未吊銷"。OCSP 響應返回的是 3月15日的緩存結果。

進一步排查發現：該 OCSP 服務的三個后端 IP 返回了三個不一致的結果 —— 有的說已吊銷，有的說沒有。

該證書確實已經吊銷。但這個發現本身暴露出證書基礎設施的一個嚴重可靠性隱患：即使你已經真的吊銷了證書，在相當可觀的一段時間里面，OCSP 依然可能在返回結果中認為它是有效的。

從工程實踐角度看

這類事故在軟件工程中有明確的防御手段。

泛域名私鑰屬于高等級憑據，在標準的安全開發實踐（SDL）中：

?私鑰應存放在 HSM（硬件安全模塊） 或專用的 KMS（密鑰管理系統） 中?CI/CD 流水線應配置 Secret 掃描，在構建階段自動檢測并阻斷憑據的意外打包?發布前的安全審查應覆蓋安裝包內的所有文件?開發人員不應直接接觸私鑰本體

以上均為業界通行做法，并非什么高不可攀的要求。對于一家主打 安全 的公司而言，這些應該是基本功。

對終端用戶的建議

如果你已經安裝了360安全龍蝦，出于審慎考慮：

1.在官方發布包含新證書的修復版本前，避免在不可信網絡環境下使用該客戶端2.如果你在客戶端中配置過大模型 API Key，建議前往對應服務商后臺 重新生成（Regenerate）密鑰3.關注360官方的后續安全公告

附：360 安全龍蝦發布會圖

信息來源

本文所述內容均基于以下公開信息與可獨立驗證的技術事實。

1.TechWeb 報道：360推出"安全龍蝦"[1]2.新浪科技（北京日報）：周鴻祎官宣將推出360安全龍蝦[2]3.小眾軟件 Appinn Feed 社區帖（轉自 L 站用戶報告）[3]4.秋風于渭水博客：技術驗證與風險分析[4]5.X用戶 @realNyarime 貼出的完整證書 PEM 編碼[5]6.X 用戶 @ZaihuaNews（科技圈在花新聞）事件報道，含 crt.sh 查詢鏈接[6]

關于本文引用的技術數據說明：OpenSSL Modulus 哈希比對結果及 OCSP 吊銷時間點的具體數值，來源于"秋風于渭水"博客的獨立驗證（來源 [4]）以及老馮的本地復現。相關驗證方法為標準操作，任何持有該安裝包的人均可使用 OpenSSL 自行復現。

寫 Bug 能理解。但發布前跑一遍 Secret 掃描，很難嗎。

References

[1] TechWeb 報道：360推出"安全龍蝦":https://finance.sina.com.cn/tech/roll/2026-03-14/doc-inhqyhwn7349741.shtml
[2]新浪科技（北京日報）：周鴻祎官宣將推出360安全龍蝦:https://finance.sina.com.cn/tech/roll/2026-03-11/doc-inhqqqfv9519753.shtml
[3]小眾軟件 Appinn Feed 社區帖（轉自 L 站用戶報告）:https://talk.appinn.net/posts/16284
[4]秋風于渭水博客：技術驗證與風險分析:https://www.tjsky.net/news/1451
[5]X用戶 @realNyarime 貼出的完整證書 PEM 編碼:https://x.com/realNyarime/status/2033428417488757122
[6]X 用戶 @ZaihuaNews（科技圈在花新聞）事件報道，含 crt.sh 查詢鏈接: https://x.com/ZaihuaNews/status/2033481130532392997

數據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403