n8n 是一款強大的工作流自動化平台，近期披露了一個針對企業版（Enterprise）的嚴重安全性漏洞 CVE-2026-59208。這個漏洞允許攻擊者在特定配置下，偽造身份並以另一名使用者的權限登入系統，達成帳號接管（Account Takeover）的效果。
對於初入行的工程師來說，這個漏洞是一個非常經典的身份驗證實作錯誤，核心問題在於對 JWT（JSON Web Token）標準的誤解。
理解 Token Exchange 與身份綁定
在企業級部署中，n8n 提供了一項名為 Token Exchange（令牌交換）的功能。這主要是給 OEM 合作夥伴使用的，目的是讓使用者在進入嵌入式 n8n 產品時，不需要再次輸入帳號密碼（即單一登入 SSO 的一種實作）。
運作流程如下：合作夥伴使用自己的私鑰簽署一個短暫的 JWT，n8n 接收後使用預先配置的公鑰驗證簽名。如果簽名正確，n8n 會讀取 Token 內的 claims（聲明），將其與本地帳號匹配，隨後允許使用者登入。
漏洞的核心：忽略了發行者身份
在 JWT 標準（RFC 7519）中，有兩個關鍵的欄位： iss (Issuer)：代表誰發行了這個 Token。 sub (Subject)：代表這個 Token 指向的具體使用者 ID。
標準明確規定，sub 的唯一性僅在該發行者（iss）的範圍內有效。換句話說，發行者 A 的使用者 ID 123 與發行者 B 的使用者 ID 123 可能是完全不同的兩個人。因此，要唯一識別一個使用者，必須將 iss 與 sub 視為一對組合。
然而，n8n 在實作時犯了錯：它在匹配本地使用者時僅檢查了 sub，而完全忽略了 iss。
這導致了一個嚴重的後果：如果 n8n 實例配置了信任多個外部發行者，攻擊者只要能從發行者 A 獲取一個合法的 Token，且該 Token 的 sub 剛好與發行者 B 旗下的某個使用者相同，n8n 就會將攻擊者誤認作發行者 B 的使用者，直接授予登入權限。整個過程完全不需要知道目標使用者的密碼。
影響範圍與實務風險
這個漏洞並非所有 n8n 使用者都會遇到，它有特定的觸發條件： 第一，必須是企業版實例。 第二，必須啟用了 Token Exchange 功能。 第三，配置中必須信任兩個或以上的外部發行者。
雖然觸發條件較多，但對於 OEM 部署環境來說，信任多個發行者是常見配置，因此風險極高。雖然目前尚未有公開的 PoC（概念驗證）顯示攻擊者如何輕易操控 sub 數值，但從架構設計來看，這是一個典型的身份綁定漏洞。
修復建議與工程啟示
n8n 已在 2.27.4 與 2.28.1 版本中修復此問題。建議所有使用者立即更新至最新穩定版本。
如果暫時無法更新，可以採取以下臨時緩解措施： 關閉 Token Exchange 功能。 如果必須使用，將信任的發行者（N8N_TOKEN_EXCHANGE_TRUSTED_KEYS）限制在單一發行者，這樣就消除了跨發行者碰撞的可能性。
這次事件給開發者的啟示是：在實作身份驗證邏輯時，絕對不能假設外部傳入的 ID 是全域唯一的。只要涉及多租戶（Multi-tenancy）或多發行者環境，所有識別碼都必須與其對應的命名空間（Namespace，在此即為 Issuer）綁定檢查。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。