Langflow 33 個 CVE 同批曝光：兩個 9.8 不用登入就能 RCE，1.13.0 是唯一完整解

2026 年 10 月 29 日，IBM 把 33 個 Langflow CVE 紀錄一次推到公開 CVE 清單。其中兩個是最壞的那種：不需要任何帳號，遠端就能繞過登入、或在伺服器上跑任意程式碼。(source: HOL Guard, The Hacker News)

如果你跑過 Langflow——那個拖拖曳曳畫 AI agent flow 的工具——而且版本在 1.0.0 到 1.12.8 之間、又有其他機器連得到它，這篇文章是寫給你的。

白話導讀

想像 Langflow 是一個接待大廳：每個進門的訪客都會被請去「登記」，然後才能用裡面的設備。

但 1.12.x 系列有一個預設設定 LANGFLOW_AUTO_LOGIN=true，它的效果是：每個訪客都不用登記，一進門就直接被當成最大權限的管理員。而且這個設定的原始碼註解自己寫著：「會繞過認證，只該用在開發環境」。(source: 1.12.8 auth.py)

所以這兩個 9.8 漏洞的入口，是認證預設根本沒開。攻擊者不需要猜到誰的密碼——他只需要連得到你的 7860 port。

兩個不用登入的 9.8

CVE	CVSS (IBM)	需要的帳號	能拿到什麼	影響至	修於
CVE-2026-93680	9.8	無	認證繞過	1.12.8	1.13.0
CVE-2026-110186	9.8	無	任意程式碼執行（MCP tool enumeration）	1.12.8	1.13.0
CVE-2026-104339	9.8	無	任意程式碼執行	1.12.3	1.12.4

三個都不用帳號。前兩個是整批 33 個裡最麻煩的，因為任何 1.12.x 都救不了你——包括 10 月 22 日剛出的 1.12.8。(source: HOL Guard 完整 CVE 對照表)

CVE-2026-110186 的攻擊面值得講一下：Langflow 可以用 Model Context Protocol（MCP）把自己的 flows 當 tools 暴露給支援 MCP 的 AI app。IBM 的描述是「透過 MCP tool enumeration 可被未認證攻擊者利用的遠端程式碼執行」——攻擊者連上 MCP 端點、列舉你掛了哪些 tools，就能走進去執行東西。(source: The Hacker News)

公版 Metasploit 模組比 CVE 紀錄先出

時間線有點離譜：

2026-09-29：1.12.4 發布（修 16 個 CVE ID）
2026-10-06：1.12.5 發布（再修 13 個）
2026-10-22：1.13.0 發布（修完剩下全部）
2026-10-23：Metasploit 發布 langflow_auth_bypass_cve_2026_93680 模組
2026-10-29：IBM 的 33 個 CVE 紀錄才正式上公開清單

兩個 9.8 的修補版（1.13.0）在 CVE 公開前只有 7 天窗口；但 1.12.4 / 1.12.5 的 29 個修補早就在 9 月底、10 月初上了。Metasploit 模組甚至比 CVE 紀錄早 6 天就掛在公版上了。(source: Rapid7 Metasploit wrap-up, 模組原始碼)

模組本身做的事很克制：無憑證連上 MCP SSE 端點、初始化 session、把伺服器列出的 tools 抓下來存成 JSON loot——它是偵察模組，不在伺服器上跑指令。模組標註的影響範圍是 1.5.0–1.11.4，比 IBM 紀錄的 1.0.0–1.12.8 窄（模組作者只測到這個範圍，不代表更舊或更新的版本安全）。

💡 重點：截至 10 月 30 日的 CISA KEV 目錄，這兩個 9.8 還沒被列為已知野外利用。更早的 6 個 Langflow CVE 在 KEV 上（最近一個 CVE-2026-9198 是 8 月加的）。「還沒進 KEV」不等於「沒被掃」——公版模組一出來，自動化工具就會開始掃 7860 port。

先查你中招沒有

以下指令都可以從一台沒有 Langflow session 的機器跑：

# 1. 版本確認
pip show langflow | grep -i ^version
curl -s http://localhost:7860/api/v1/version
docker inspect --format '{{.Config.Image}}' <container>
# 任何 1.0.0 – 1.12.8 都至少中一個

# 2. auto-login 是否開著
# 用私人視窗開 UI：如果沒跳登入表、直接進 flow 清單 = 高度可疑（SSO 也可能免表單，僅供線索）

# 3. MCP 端點是否對外人回話
curl --include --max-time 5 -N -H 'Accept: text/event-stream' http://your-langflow:7860/api/v1/mcp/sse
# 200 + event stream 開始 = 任何人可連；401/403 = 有要求憑證（連線 5 秒後被 cut 屬正常）

# 4. 7860 開在哪（只看本機 / 本 network namespace，Docker port 映射不在此列）
ss -ltnp | grep 7860
# 0.0.0.0:7860 + 這台有公網位址 = 緊急

風險分級（來自 HOL 的分析，我同意這個分級）：

今天就要動：server 上跑著別人連得到的 Langflow——team 共用的 agent builder、demo box、沒有 SSO 擋在前面的容器。
較低但非零：langflow run 綁在 127.0.0.1 的本機 session（兩個 no-login bug 需要網路能到達）；或單一可信帳號 + auto-login 已關的 instance（救不了那三個 no-login CVE）。
有擋的：所有 Langflow path 前面有 SSO / VPN / IAP 的反向代理。

升級：兩個陷阱

修法只有一個：1.13.0。1.12.4 清掉 16 個 ID、1.12.5 再清 13 個，但那兩個 no-login 9.8 只出現在 1.13.0。

# pip / uv
pip install --upgrade "langflow==1.13.0"

# Docker（別信 latest，拉 pinned tag）
docker pull langflowai/langflow:1.13.0

陷阱一：1.13.0 預設把 auto-login 關掉了（我對過 1.13.0 的 source，AUTO_LOGIN 的 default 從 true 改成 false）。從 1.12.x 原地升級的 instance 如果沒設 superuser 密碼，啟動時會直接拒絕：Username and password must be set。所以升級前要先設好：

export LANGFLOW_AUTO_LOGIN=false
export LANGFLOW_SUPERUSER=langflow
export LANGFLOW_SUPERUSER_PASSWORD='use-a-long-random-value'
# 注意：這三個變數必須進到 Langflow 實際讀取的環境
# （container 的 env / systemd unit / .env），不是只在你手邊的 shell 設

陷阱二：auto-login 舊帳戶已經有密碼了。 如果 instance 之前跑 auto-login，bootstrap 帳戶（langflow）已經有一個系統生成的密碼和登入時間戳。這時你 export LANGFLOW_SUPERUSER_PASSWORD=... 不會改到它，登入會報 Incorrect username or password。Langflow 文件給的恢復路徑（Recover access after upgrading）：

暫時把 auto-login 開回去
用 PATCH /api/v1/users/{id} 對那個帳戶設密碼
再把 auto-login 關掉
第 1–3 步期間把 7860 對外關起來——那幾分鐘你回到了裸露狀態

⚠️ 不要靠重裝找回存取權：Langflow 文件明確警告，刪掉重裝 Langflow 可能把 flows 永久刪掉。

升級完還要做的：換金鑰

升級只修新的漏洞，不會幫你還原已經洩漏的。批內有四個跟 secret 有關的 CVE，最值得注意的是 CVE-2026-77817：flow / project 的 JSON export 不會把 secret 剝掉。所以：

在受影響版本上 export 過的任何 JSON（躺在 repo、ticket、Slack 裡的），可能帶著活的金鑰
flows 呼叫過的 model API / SaaS 的 API keys，如果攻擊者真的進來過，當它已經洩漏
換完金鑰再觀察 access log，而不是只換版本就收工

這是誰的事

Langflow 是 open-source，CVE authority 是 IBM——因為 IBM 在 2024 年收了 DataStax，而 DataStax 收了 Langflow 原始開發商 Logspace。(source: The Register)

對 homelab / self-host 族群的直接意涵：你在 Docker 上跑的任何「AI agent 組裝工具」（Langflow、n8n、Flowise 這類型），只要 port 對 LAN 以外可達、前面沒有認證層，攻擊面就跟著這次 33-CVE 的形狀走。推論伺服器（vLLM / Ollama）是「無認證 HTTP 代理帶 GPU」，agent builder 是「無認證 HTTP 代理帶你所有 flows 的金鑰」——同一個模式，不同的獵物。

If You're Stuck

升級後啟動報 Username and password must be set → 1.13.0 預設 auto-login 已關，設 LANGFLOW_SUPERUSER_PASSWORD 再啟動
升級後登入報 Incorrect username or password → 是陷阱二：auto-login 舊帳戶有生成密碼，走上面的恢復路徑（暫時開 auto-login → PATCH /api/v1/users/{id} → 關回）
升級後 MCP 端點還是不要求憑證 → 1.12.x 上該端點對未認證連線開著就是 bug，不用設定；升級 1.13.0 或先把 port 關掉
設了 AUTO_LOGIN=false 但舊 session 還是活著 → 關 auto-login 不會撤銷已存在的 session / API key；要手動 revoke 或等過期
Docker latest 升級完還是 1.12.x → latest tag 之前解析到的就是舊版，改用 pinned langflowai/langflow:1.13.0
不確定版本 → curl -s http://localhost:7860/api/v1/version 最直接