觀點 · 資訊分享
Traefik ForwardAuth 特定架構下能被偽造標頭繞過驗證：專案 4 月 24 日已公告，4 月 30 日才拿到 CVE
CVE-2026-35051 影響 Traefik 的 ForwardAuth 中介層：在受信任上游代理之後、trustForwardHeader=false 的環境，攻擊者可偽造 X-Forwarded-Prefix 讓驗證服務誤判。專案早在 4 月 24 日已發布安全公告與修正版。
- 發布
- 2026-05-01
- 篇幅
- 約 3 分鐘 · 1,573 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Traefik 的 ForwardAuth 在特定部署下沒有清掉攻擊者偽造的 X-Forwarded-Prefix 標頭，可能讓驗證服務誤判；專案早在 4 月 24 日就發布公告與修正版。
先用白話講：ForwardAuth 是什麼？
Traefik 是常見的反向代理，像是大樓的總機：外面的請求先到它這裡，再轉給裡面不同的服務。ForwardAuth 是它的一個功能：每個請求進來前，先打電話問另一個「驗證服務」：「這個人可以進去嗎？」
這次的問題是，總機在打電話給驗證服務時，漏掉清理其中一張「便條紙」，讓攻擊者能自己在上面寫字，騙驗證服務放行。
發生什麼事
- 4 月 24 日：Traefik 專案發布安全公告 GHSA-6384-m2mw-rf54，並釋出修正版
- 4 月 30 日：CVE-2026-35051 在 NVD 公開
也就是說，這不是 4 月 30 日才突然爆出的漏洞，而是專案早已公告、CVE 編號隔幾天才補上。
問題的細節：當 trustForwardHeader=false，且 Traefik 部署在受信任的上游代理後面時，Traefik 會重建 X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Proto 等標頭，卻沒有清除或重建 X-Forwarded-Prefix。攻擊者帶來的值會原封不動送到驗證服務。
誰會中？
官方描述，需要同時符合：
| # | 條件 |
|---|---|
| 1 | Traefik 部署在受信任的上游代理之後 |
| 2 | 使用 ForwardAuth，且 trustForwardHeader=false |
| 3 | 驗證服務依 X-Forwarded-Prefix 做授權或路由決定 |
另外，原始通報提到，如果 StripPrefix 在 ForwardAuth 之前執行，驗證服務會同時收到攻擊者給的值與 Traefik 產生的值；驗證服務若取第一個值，就可能被騙。
給開發者的技術細節
- 修正版本：2.11.43、3.6.14、3.7.0-rc.2
- 受影響版本：v2 的 2.11.42 以前；v3 的 3.6.13 以前與 3.7.0-rc.1 以前；官方列出 v1 的 1.7.34 以前也受影響但沒有修正版
- 評分：GitHub 公告的 CVSS 4.0 為 7.8（High）；NVD 頁面上另有其他來源給出更高的評分
- 自查：確認驗證服務有沒有讀取
X-Forwarded-Prefix；若有，升級後再檢查授權邏輯
我的看法
我自己在家裡的 NAS 上也會用反向代理串服務，這個漏洞提醒我一件事：驗證服務最好不要依賴任何「前面某一層幫你清過」的標頭，自己要有最後一道檢查。
另外，接案時常見的架構是「雲端 CDN → 反向代理 → 驗證服務」，層數一多，每一層對標頭的處理都可能不一致。升級是必要的，但更根本的做法是讓授權決定只看你自己確定可信的資訊，而不是看起來像內部產生的欄位。
名詞小辭典
- 反向代理（Reverse Proxy）：站在伺服器前面接請求、再轉給後端的中介服務，Traefik、Nginx 都屬於這類。
- X-Forwarded-Prefix：代理在轉送時附上的標頭，記錄原本請求網址被去掉的前綴。
- GHSA：GitHub 安全公告的編號格式，CVE 則是全球通用編號。
- CVSS：漏洞嚴重度評分，滿分 10；不同版本的算法不同，分數不能直接比較。