資安雷達 2026 年 9 月 22 日

2026-09-22 — nginx ignition 三洞齊發:搶帳號重放CPU超載

primary=https://github.com/advisories/GHSA-pxcx-fv34-x9p5 primary=https://github.com/advisories/GHSA-jr34-h97m-9hpx primary=https://github.com/advisories/GHSA-hf33-q6cf-c66f

nginx ignition 三洞齊發:搶帳號重放CPU超載

GitHub Security Advisories · 2026-09-21

只要在系統剛啟動、還沒有人完成初始設定的空窗期,同時打一串未經驗證的請求,就能搶在合法管理員之前,替自己建立好幾個擁有完整讀寫權限的管理員帳號。這是自架 nginx 管理面板專案 nginx ignition 在 2026 年 9 月 21 日同一天公開的三份資安公告之一,另外兩份分別揭露 TOTP 驗證碼可在效期內重複使用、以及 Accept-Language 標頭可觸發約 75 倍的 CPU 放大攻擊。

nginx ignition 是開發者 lucasdillmann 維護的開源後台,提供圖形化介面管理 nginx 的站台、憑證與轉發規則,等同於幫 nginx 加裝一套控制台;它與 nginx 官方專案、以及 F5 旗下的 NGINX Inc 並無關聯,實際的設定檔仍是由這套 Go 語言後端產生後再交給底層 nginx 執行。三份公告的 CWE 分類分別是競態條件資源耗盡驗證機制不當,涵蓋了帳號、效能、驗證三個面向。

GHSA IDCVSS機制修復版本
GHSA-pxcx-fv34-x9p58.1onboarding 端點競態,可搶建多組管理員2.41.1
GHSA-jr34-h97m-9hpx7.5底線繞過既有防護,CPU 放大約 75 倍2.40.1
GHSA-hf33-q6cf-c66f4.2TOTP 驗證碼於效期內可重放2.35.1

漏洞機制

第一個漏洞出在 onboarding 完成端點 POST /api/users/onboarding/finish,這支路由被註冊為匿名可存取。處理常式先檢查 OnboardingCompleted() 是否已完成設定,再呼叫 Save() 寫入新使用者,中間沒有鎖、交易或唯一鍵保護,形成一個典型的TOCTOU 競態。攻擊者只要在系統尚未完成初始設定前平行送出多個請求,每一個請求都能各自通過檢查,最後拿到好幾組具備 Hosts、Users、NginxServer 等權限全開的管理員 JWT,等於完全接管這台 nginx 的控制台與其代理的所有站台。

第二個漏洞藏在處理 Accept-Language 標頭的 i18nMiddleware 裡。先前為了防堵 CVE-2022-32149 而加上的連字號過濾,只擋掉了 - 字元,卻沒發現 Go 的 language.ParseAcceptLanguage() 對底線 _ 一視同仁地解析。攻擊者送出一個約 1 MiB、以底線分隔大量語系標籤的標頭,就能觸發解析器裡的二次方時間掃描,單一請求即可燒掉約 2.4 秒 CPU,十個平行連線就足以讓十核心機器全滿載,且只需要約 10 MiB/s 的上行頻寬。

第三個漏洞則是二階段驗證的老問題:底層使用的 pquerna/otp 套件並未追蹤已使用過的驗證碼,只要還在標準 30 秒效期內,同一組 TOTP 就能被重複提交而驗證通過。這代表只要驗證碼曾經被側錄或攔截,攻擊者就有一段時間可以拿著同一組碼重放登入,不需要即時取得裝置或重新產生新碼。

受影響版本

  • GHSA-pxcx-fv34-x9p5:所有低於 2.41.1 的版本都受影響,因為 onboarding 端點的競態從一開始就存在,沒有下限版本。
  • GHSA-jr34-h97m-9hpx:自 2026 年 1 月底加入連字號過濾的版本起,到 2.40.1 之前的所有版本,底線繞過都成立。
  • GHSA-hf33-q6cf-c66f:自 2026 年 2 月中旬的建置版本起,到 2.35.1 之前,TOTP 重放都未被阻擋。

修補與緩解

三個修補分別對症下藥:2.41.1 把 onboarding 的檢查與寫入包進同一個交易,讓競態請求彼此互斥;2.40.1 把底線與連字號一併納入 Accept-Language 的過濾規則;2.35.1 則替 TOTP 驗證加上一份已用驗證碼的黑名單,在效期內擋掉重複提交。三份公告都建議搭配額外的防線,例如替 onboarding 加上一次性設定權杖、對 Accept-Language 做長度限制。

所有自架 nginx ignition 管理面板的維運者都應該立刻升級到 2.41.1 或更新版本,一次補齊三個洞,而不是只挑其中一個修。升級前建議先確認自己的實例是否曾經歷過「部署後尚未完成 onboarding」的空窗期,並檢查使用者清單裡有沒有來路不明的管理員帳號;同時盤點反向代理或 CDN 是否會把原始 Accept-Language 標頭直接轉送給後端,以及是否已啟用雙因子驗證卻從未檢查過登入紀錄裡的重複驗證碼。

原始來源:GHSA-pxcx-fv34-x9p5GHSA-jr34-h97m-9hpxGHSA-hf33-q6cf-c66f


End of article
0
Would love your thoughts, please comment.x
()
x