觀點 · 資訊分享

本機跑大模型的 ktransformers 爆漏洞：排程埠對所有網卡開放，惡意封包就能在主機上執行指令

ktransformers 0.6.3 以前的 balance_serve 排程服務，把 ZeroMQ 埠綁在所有網卡上，又直接用 pickle 解開收到的資料，取得 CVE-2026-63767。修補只是改成只綁 127.0.0.1，pickle 本身還在。

一句話看懂：ktransformers 0.6.3 以前的排程服務，把網路埠開在「所有網卡」上，又直接解開收到的 pickle 資料，取得 CVE-2026-63767（CVSS 9.3）；官方的修補是改成只開在本機 127.0.0.1。

ktransformers 排程埠漏洞資訊圖卡：排程服務對所有網卡開放，又直接解開 pickle，遠端能執行指令

先用白話講：這是什麼問題？

ktransformers 是在自己的主機上跑大型模型的推論框架，適合自架模型的人。它的預設高效能後端 balance_serve 裡有個「排程服務」，負責把工作分給不同的處理程序。

這個排程服務有兩個毛病，合在一起就出事：

大門沒鎖：它的網路埠開在 tcp://*，意思是監聽所有網卡，不只是本機，連區網、甚至網際網路上的人都連得到
收到包裹不檢查就拆：每收到一則訊息，就直接用 Python 的 pickle.loads() 還原。pickle 像是把物件「冷凍打包」，解凍時會照包裡附的說明書重建物件，而說明書可以寫「順便幫我執行這個指令」

回報者在 2026-07-13 於 GitHub 開了 Issue #2087，指出排程服務可被未驗證的遠端攻擊者利用
修補的 PR #2091 在 2026-07-19 合併
VulnCheck 在 2026-07-20 公布 CVE-2026-63767，影響 ktransformers 0.6.3 以前，官方以 commit def0f93 修正；我沒有查到對應的正式發行版本號
評分是 CVSS v4 的 9.3（v3.1 為 9.8），攻擊者不需要登入，只要連得到那個埠，就能用惡意的 pickle 資料，以「伺服器程序的身分」執行任意指令

PR 的做法很單純：把排程服務的埠從 tcp://* 改成 tcp://127.0.0.1，每處只改一行。原因是排程的通訊本來就只發生在同一台機器內，客戶端本來就是連 localhost，改成只聽本機並不影響正常使用。

PR 說明也很誠實地指出一件事：pickle.loads() 本身還在。現在只是把大門關到只有本機能進，網路上的攻擊面被擋住了；若要徹底解決，要改用有格式檢查的資料格式（例如 JSON、msgpack），或加上 ZeroMQ 的 CURVE 認證，這屬於更大的設計變更，留待之後處理。

1. 先確認有沒有暴露：在主機上看有哪些服務聽在所有網卡：

ss -ltnp

找輸出裡本地位址是 0.0.0.0 或 * 的行，而且程序是 Python 或 ktransformers 的，就是暴露中。

2. 處理方式（任選或搭配）：

3. 寫程式時的教訓：對不信任的來源資料，不要用 pickle.loads()；行程之間溝通，優先用 JSON 這類只描述資料、不會執行程式的格式；內部服務預設綁 127.0.0.1，真的需要對外再明確開放。

最近自架 AI 的人很多，各種推論框架大多「一行指令就跑起來」，但預設值不一定適合暴露在網路上，這次就是一例：內部用的溝通埠，被不小心開給了所有網卡。如果家裡或公司的主機上同時放了模型、檔案和備份，一個暴露的埠就足以讓人一路摸進來。

我的建議是：新服務裝好的第一件事，先看它聽在哪個位址。沒有需要對外的，一律改成本機；需要給同事用的，前面加一層有驗證的反向代理，不要直接把推論服務的埠暴露出去。

ktransformers 是什麼？

一個在自己主機上跑大型模型的推論框架，balance_serve 是它預設的高效能服務後端，裡面有負責分派工作的排程服務。

pickle 為什麼危險？

pickle 是 Python 把物件打包、還原的格式，還原時會照包裡的說明重建物件，而這份說明可以夾帶要執行的指令。所以絕對不要對不可信來源的資料用 pickle.loads。

我該怎麼檢查自己有沒有暴露？

在主機上查看哪些程式的埠是監聽在 0.0.0.0（所有網卡）而不是 127.0.0.1，並用防火牆或容器設定，確保推論服務只有本機或可信網段能連到。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。