AI 代理框架 Omnigent 爆四漏洞可串成認證後 RCE,curl 8.22.0 同步修十個 CVE、golang.org/x/crypto 補強 SSH 阻斷服務漏洞
GitHub Security Advisories · 2026-09-02
2026 年 9 月 2 日同一天,三則資安揭露相繼出現:Go 團隊在 oss-security 發布 golang.org/x/crypto 安全公告,curl 專案發布 8.22.0 版安全公告,GitHub Security Advisories 也揭露 AI 代理框架 Omnigent 的四項連環漏洞。前兩者分別修補 SSH 通道阻斷服務問題,以及涵蓋 LDAP、HTTP/2、TLS 憑證比對等面向的十個 CVE。Omnigent 的漏洞則可讓具備一般帳號的使用者,透過上傳的代理程式包在伺服器端取得任意程式碼執行權限。
golang.org/x/crypto:漏洞機制
Go 官方公告指出,golang.org/x/crypto 的 SSH 套件存在兩個獨立編號的阻斷服務漏洞:CVE-2026-56855 與 CVE-2026-78662。前者發生在通道(channel)已建立之後,惡意對端可送出未預期的訊息讓連線陷入死結;後者則發生在通道尚未確立可用狀態時,攻擊者能對 incomingRequests 佇列灌入大量請求,同樣造成整條連線鎖死。兩者的共同根因,是舊版實作在收到不符預期的訊息時選擇緩衝等待,而非直接判定為協定錯誤並斷線。修補後的版本改為明確處理 RFC 4254 定義的所有通道訊息,遇到未知類型即視為協定錯誤並終止連線。
golang.org/x/crypto:受影響版本
兩項漏洞影響修補前所有仍依賴舊版通道處理邏輯的 golang.org/x/crypto 版本,官方公告未列出明確的受影響下限版本號。只要應用程式的 SSH 客戶端或伺服器仍使用舊版 golang.org/x/crypto/ssh,就暴露在遠端可觸發的連線鎖死風險下。
golang.org/x/crypto:修補與緩解
Go 團隊已釋出 golang.org/x/crypto v0.56.0 修補上述兩個問題,兩則漏洞皆由 Will Mortensen 回報。公告未提供暫時性緩解措施,升級至 v0.56.0 是目前唯一修補途徑。受影響對象是任何直接建置在該套件 SSH 實作之上的 Go 應用程式,無論是用它打造客戶端還是伺服器。
curl 8.22.0:漏洞機制
curl 專案同日在 oss-security 發布 curl 8.22.0 安全公告,一次修補十個 CVE,涵蓋 LDAP 認證、HTTP/2、TLS 憑證比對與 Cookie 處理等模組。其中機制較特殊的是 CVE-2026-13608:libcurl 在處理 OpenLDAP 後端的 SASL 認證交握時,會把「交握尚未完整」的中斷狀態誤判為「加密驗證已成功」。這代表遭遇中間人攻擊時,攻擊者只要注入一段提早截斷的回應,就能讓 libcurl 略過完整的伺服器身分驗證流程。另一項 CVE-2026-18924 則是 HTTP/2 伺服器推送(server push)功能中的 use-after-free 記憶體錯誤。
curl 8.22.0:受影響版本
依官方公告,CVE-2026-13608 影響 curl 7.82.0 至 8.21.0,更早期版本與 8.22.0 以後不受影響。其餘九個 CVE 各自有不同的受影響版本區間,完整清單需查閱 curl.se 個別 CVE 頁面。由於 libcurl 被大量作業系統套件、程式語言執行環境與應用程式間接連結,實際受影響面遠超過直接使用 curl 命令列工具的使用者。
curl 8.22.0:修補與緩解
curl 8.22.0 已修補全部十個問題,官方建議直接升級 libcurl 與 curl 命令列版本。若暫時無法升級,CVE-2026-13608 可改用 LDAPS(LDAP over TLS)取代明碼 LDAP 連線來規避,因為偽造伺服器會在憑證驗證階段就被拒絕。curl 官方將 CVE-2026-13608 列為低風險,但其餘涉及記憶體安全與連線重用的問題仍建議儘速套用更新。
Omnigent:漏洞機制
GitHub Security Advisories 於 9 月 2 日揭露 AI 代理框架 Omnigent(允許使用者透過網頁介面或 API 上傳自訂「代理程式包」的服務端框架)存在四項可互相串連的漏洞。錨點漏洞 GHSA-756x-9hf6-q4h4(CVE-2026-62675)源於代理程式包驗證邏輯的疏漏:伺服器端 Python callable 工具原本應是僅限操作者信任的功能,上傳路徑卻同時接受來自一般租戶的程式包,執行時經 importlib.import_module() 與 getattr() 解析,讓攻擊者得以指向 subprocess.check_output 等函式取得任意程式碼執行。姊妹漏洞 GHSA-jrrm-9hc7-2v3h(CVE-2026-62674)出在 PUT /sessions/{session_id}/agent 端點缺少「代理是否為共享範本」的授權檢查,使一般使用者能覆寫共享代理程式包,讓惡意 stdio MCP 伺服器影響所有沿用該範本建立的工作階段。第三項 GHSA-7mqg-cx4g-x2rf(CVE-2026-62676)出在 shell 指令解析器 policies/builtins/_shell.py,該解析器對無法辨識的指令「放行」而非拒絕,讓受限代理能用 bash -lc、timeout、setsid 等未列管指令繞過白名單與工作區隔離。
Omnigent:影響範圍
這四項漏洞共同影響 omnigent < 0.3.0 的所有部署,尤其是多租戶代管環境。四項弱點可被串連使用:繞過 shell 白名單、竄改共享代理範本、注入惡意 callable 工具與跳脫工作目錄限制,合計足以讓只具備一般身分驗證的使用者取得執行環境的完整程式碼執行權限。此次揭露的完整清單如下:
GHSA-756x-9hf6-q4h4(CVE-2026-62675):上傳代理程式包內建惡意 Python callable 工具,導致認證後 RCE,CVSS 8.8(High)GHSA-jrrm-9hc7-2v3h(CVE-2026-62674):覆寫共享代理程式包導致認證後 RCE,CVSS 9.0(Critical)GHSA-7mqg-cx4g-x2rf(CVE-2026-62676):shell 指令解析器防護規則失效,CVSS 7.1(High)GHSA-p8rw-8qj3-hf33:os_env.cwd未經驗證,導致可任意存取主機檔案系統
Omnigent:修補與緩解
上述漏洞皆已在 omnigent 0.3.0 版修補,其中 shell 解析器問題對應修補提交 1a05b7b。官方建議的修補方向包括:無法辨識的指令一律預設拒絕、上傳路徑一律拒絕伺服器端 Python callable 工具(除非由操作者明確加入允許清單)、並在共享代理的編輯端點補上與 MCP 端點一致的權限檢查。在完成升級前,操作者應暫時限制代理程式包上傳功能,並避免讓未受信任的使用者存取共享範本代理。
原始來源:oss-security: golang.org/x/crypto 漏洞公告、oss-security: curl 8.22.0 安全公告、GHSA-756x-9hf6-q4h4、GHSA-jrrm-9hc7-2v3h、GHSA-7mqg-cx4g-x2rf