OSSA-2026-039：OpenStack Octavia 的 HAProxy 設定注入漏洞可致 amphora 遠端程式碼執行
來源：oss-security 郵件論壇（OpenStack VMT 發布）· 2026-09-21
只要能建立或更新一個 listener，一般租戶就能在 OpenStack Octavia 管理的 amphora 上以 root 身分執行任意指令，還能讀出其他租戶的 TLS 私鑰與整個部署共用的 heartbeat key。OpenStack 漏洞管理團隊（VMT）於 2026 年 9 月 21 日發布 OSSA-2026-039，對應 CVE-2026-94571 與 CVE-2026-94572，CVSS 未公布。這是一個由輸入驗證缺陷一路串到遠端程式碼執行（RCE）的完整攻擊鏈，且只影響 Octavia 內建的 Amphora provider driver。
漏洞機制
Octavia 的 listener 與 pool 物件有一個 tls_ciphers欄位，L7 policy 則有 redirect_url與 redirect_prefix欄位；這些欄位的值會被原樣寫進 amphora 上產生的 haproxy.cfg，沒有拒絕換行字元等控制字元。研究者示範只要在 tls_ciphers值裡塞入一個換行，就能讓字串從 bind ... ciphers <value>這一行「跳」出來，另開一個新的 global區塊，並在裡面宣告一個帶指令的 program。HAProxy 本身允許設定檔中出現重複的 global區塊（只會印警告，Octavia 自己的 amphora agent 也依賴這個行為在後面附加第二個 global 區塊），所以注入的內容能被正常解析。
關鍵在於 HAProxy 以 master-worker 模式執行時，master行程會在把權限降到 nobody 之前，先 fork 出 program所宣告的指令，於是注入的指令是以 uid=0 執行。公開的概念驗證顯示，攻擊者只要透過 PUT `/v2/lbaas/listeners/{id}` 送出一個帶換行與 program指令的 tls_ciphers，amphora agent 重新載入 HAProxy 後指令即以 root 身分跑出 `id` 的結果。同一個欄位也能被當成任意檔案讀取原語（透過 http-request return ... file <path>），因為那一行同樣是在設定解析階段由 root 載入的。由於 amphora 本身掛在 OpenStack 控制平面網路上，取得 amphora root 之後還能經 nsenter進入 root network namespace，進一步碰到 Keystone、Nova、Neutron、Barbican 等控制平面服務。
受影響版本
| 項目 | 內容 |
|---|---|
| 受影響版本 | Octavia >=0.8.0 且 <16.1.0，以及 ==17.0.0、==18.0.0 |
| 版本細節 | listener/pool 的 tls_ciphers欄位自 Octavia 6.0.0 才引入，6.0.0 之前的受影響版本只能透過 L7 policy 的 redirect_url/redirect_prefix欄位觸發 |
| 不受影響 | 未使用 Amphora provider driver 的部署（其他 provider 不會把租戶輸入寫進 HAProxy 設定） |
| 修補方式 | 各分支各需要兩個修補：一個修 tls_ciphers、一個修 L7 policy redirect 欄位，已分別在 2025.1/epoxy、2025.2/flamingo、2026.1/gazpacho、2026.2/hibiscus 分支合併 |
這兩個問題最早只被當成低嚴重度的「加固建議」，修補在公開的 Gerrit review 上開發並合併，直到有人展示能藉此在 amphora 上取得 root RCE、並碰到控制平面網路，才被重新分類為安全漏洞並補發 OSSA 與 CVE 編號。CVE由 Chen YuXiang（中國科學院計算技術研究所）與化名 Rolix 的獨立研究者分別回報，其中 RCE 的部分是由 Infomaniak 的 Thomas Goirand 代為通報給 OpenStack VMT。
修補與緩解
用 Octavia 的 Amphora provider 跑負載平衡的雲端維運團隊，第一步是把 Octavia 升級到已合併修補的分支版本，對應版本落在 2025.1/epoxy、2025.2/flamingo、2026.1/gazpacho、2026.2/hibiscus 這幾個系列，Gerrit 上的修補連結（如 review.opendev.org/1001096、1001094、1001091、999553 等）可用來核對自己套用的 commit 是否包含在內。若暫時無法升級，可先在 API 層或反向代理前面加一道規則，拒絕 tls_ciphers、redirect_url、redirect_prefix與 L7 rule 的比對值中出現換行字元。
更長期的作法，是盤點自家對 Octavia API 的所有輸入欄位，凡是最終會被組進 HAProxy、Nginx 或任何設定檔範本的欄位，都要視為需要額外驗證的高風險輸入，不能只靠前端表單擋。也建議檢查 amphora 所在的管理網路的分段設計，讓 amphora 就算被攻陷，也無法直接碰到 Keystone、Barbican 這類控制平面服務，這是本次事件裡被額外點名的次要風險面。已經在雲端環境對外開放 Octavia API 的團隊，應優先假設現有 listener、pool、L7 policy 設定已遭注入，重新檢視相關資源再決定是否重建 amphora。
原始來源：
https://oss-security.openwall.org/lists/oss-security/2026/09/22/18
https://launchpad.net/bugs/2167565