ロードバランサー(通信を複数のサーバーに振り分けるソフト)の定番の「HAProxy」で、CPUを使い切らせる脆弱性2件が直りました。開発元は日本時間10月15日(現地10月14日)に、2.6から3.4までの各系列の修正版を一度に出しています。Debianも10月18日に、セキュリティの告知DSA-6570-1を出しました。CVEの番号は、まだ付いていません。
何が直ったのか
開発元のお知らせ(3.0.30の告知)によると、今回の版には「2つの重要なセキュリティの修正」が入っています。どちらも、相手が接続を開いたままにしている間、HAProxyのCPUが休めなくなるものです。
- HTTP/2のPINGフレーム(mux-h2): 途中で切れたPINGフレーム(接続の生存を確かめる短いデータ)を送られると、残りが届くまで何度も起こされ、CPUが100%に張り付きます。相手が接続を開いたまま残りを送らない間、または「timeout http-request」の時間が来るまで続きます。開発元は、これが問題になったのは、起こし方の仕組みが変わった3.1からだとしています。
- HTTP/1のチャンクの長さの行(h1-htx): 分割して送る形式(chunked)の要求で、チャンクの長さを書く行が受け取り用のバッファーより長いと、処理が先に進まず、同じデータを延々と読み直していました。今回の修正で、行が収まらないと分かった時点で「400(要求の誤り)」を返すようになりました。
開発元は、影響は中くらいで、そうした接続が全体のうちどのくらいの割合かで変わるとしています。データが漏れる種類の脆弱性ではありません。CVEは2件とも申請中です。
HAProxyの各系列の最新版と保守の期限(10月14日に一斉に更新)出典: HAProxy(公式サイト)(引用)
直った版は次のとおりです。いずれも現地10月14日に出ています。3.1系は保守が終わっていて(最後は2026年3月の3.1.17)、修正版は出ていません。
| 系列 |
直った版 |
保守の期限(開発元の表) |
| 3.4(LTS) |
3.4.7 |
2031年第2四半期 |
| 3.3 |
3.3.17 |
2027年第1四半期 |
| 3.2(LTS) |
3.2.26 |
2030年第2四半期 |
| 3.0(LTS) |
3.0.30 |
2029年第2四半期 |
| 2.8 |
2.8.31 |
2028年第2四半期(重大な修正のみ) |
| 2.6 |
2.6.35 |
2027年第2四半期(重大な修正のみ) |
DebianのDSA-6570-1
Debianは10月18日、DSA-6570-1で、HAProxyのサービス妨害につながる脆弱性2件を直したと告知しました。安定版(trixie)は、3.0.11-1+deb13u4で直っています。CVEの欄は「まだない(not yet available)」です。
![Debianのセキュリティの告知の画面。題は[SECURITY] [DSA 6570-1] haproxy security update、日付は2026年10月18日。パッケージはhaproxy、CVEはnot yet available。HAProxyにサービス妨害につながる脆弱性2件が見つかり、安定版(trixie)は3.0.11-1+deb13u4で直ったと書かれている](/_next/image?url=%2Fimages%2Farticles%2Fhaproxy-h2-ping-h1-chunk-dos-fix-dsa-6570-1%2Fdsa.webp&w=828&q=75)
Debianの告知DSA-6570-1。trixieは3.0.11-1+deb13u4で修正出典: Debian(debian-security-announce)(引用)
Debianのセキュリティ追跡のページでは、今回の2件(HTTP/2のPINGと、HTTP/1のチャンクの長さの行)が、trixieの3.0.11-1+deb13u4と、ひとつ前の安定版(bookworm)の2.6.12-1+deb12u4で、どちらも「直った」となっています。開発中の版(forky・sid)は、開発元の3.2.26で直っています。
Ubuntuは、10月19日の時点で、この2件の告知(USN)をまだ出していません。ほかのディストリビューションや、HAProxyを組み込んだ製品・コンテナのイメージは、それぞれの提供元の告知を確かめます。
一緒に直ったほかの不具合
3.0.30のお知らせでは、この2件のほかにも、運用に関わる修正が挙がっています。
- 乱数の強化: 内部の乱数の出力から、ログのUUIDやQUICの再試行のトークン、WebSocketの鍵の値を推測できるおそれがあったため、出力を混ぜる処理を足しました。
- stick-tableの複製: 大きすぎるキーを、ほかのHAProxy(peers)に複製するときに、送る側が落ちたり、バッファーの外を書き換えたりするおそれがありました。
- mapとACL: 仮想のファイルから読んだmapとACLを両方使う設定で、解放済みのメモリーを読み、動きがおかしくなったり、ワーカーが落ちたりするおそれがありました。
HAProxyの周辺では、設定を管理するData Plane APIの脆弱性も出ています(HAProxyのData Plane APIに認証バイパスの脆弱性 設定の全書き換えの恐れ)。あわせて確かめておくと効率的です。
影響する会社・しない会社
- 影響する: HAProxyで、外からのHTTP/2またはHTTP/1の通信を受けている会社です。Webサイトや社内システムの入口、APIの前段、コンテナの基盤の入口(Ingress)などで使われていることがあります。
- 影響する: DebianのパッケージのHAProxyを使っていて、trixieが3.0.11-1+deb13u4より前、bookwormが2.6.12-1+deb12u4より前の会社です。
- 影響する: 保守の終わった3.1系を使っている会社です。修正版が出ないため、保守の続いている系列(3.2か3.4のLTSなど)へ移る必要があります。
- 影響しない: 直った版以降を使っている会社です。HTTP/2のPINGの件は、開発元の説明では3.1以降で問題になったものです。
情シスが今日やること
- HAProxyがどこにあるかを洗い出す: Webの入口、ロードバランサー、コンテナの基盤、委託先が運用している環境まで含めて、HAProxyを使っている所を一覧にします。製品に組み込まれている場合もあります。
- 版を確かめる: 「haproxy -v」や「dpkg -l haproxy」で版を見て、上の表の直った版より前なら更新の対象です。
- 更新する: Debianなら、通常のパッケージの更新でhaproxyを上げ、HAProxyを再起動または再読み込みします。開発元の版なら、同じ系列の最新版に上げます。3.1系なら、LTSの系列へ移る計画を立てます。
- すぐ上げられないときのしのぎ方: HTTP/2のPINGの件は、「timeout http-request」を1〜5秒ほどにするとCPUの消費を抑えられると、開発元が書いています。HTTP/1のチャンクの件には回避策が書かれていないため、更新を急ぎます。
- CPUの見張りを確かめる: HAProxyのCPUが、通信の量に比べて高いまま下がらないことがないか、監視のグラフを見ます。更新のあとも、しばらく様子を見ます。
