HAProxyの設定を動的に管理するためのREST API「Data Plane API」に、認証を回避できる深刻な脆弱性(CVE-2026-109575)が見つかりました。深刻度はCVSSで9.8のCriticalです。特定のTLS設定のときに、認証なしでAPIの管理者権限を奪われ、HAProxyの設定を全面的に書き換えられる恐れがあります。注意したいのは、これがHAProxy本体ではなく、設定管理用のData Plane APIの問題だという点です。対象かどうかの確認と対応を、公式情報から整理します。
何が起きるのか
Data Plane APIは、HAProxyの設定を、再起動せずに動的に変更・管理するためのREST APIです。バックエンドの追加や設定変更を、自動化のしくみから行うために使われます。
今回の問題は、認証の欠如(CWE-306)です。特定のTLS設定、具体的には「TLSのCA(tls_ca)」と「数値のTLSポート(tls_port)」の両方を設定している場合に、Basic認証がプロセス全体で無効になってしまいます。クライアント証明書の検証(mTLS)は、HTTPSの経路にしか適用されないため、同じしくみを共有するHTTPのリスナーやUNIXソケットのリスナーが、「認証なしで通ってしまう(fail open)」状態になります。
この結果、管理用のエンドポイントに届ける攻撃者は、認証なしでData Plane APIの管理者権限を得られます。平文の設定を読み取ったり、設定を全面的に書き換えたりできるため、バックエンドの差し替えや、通信の誘導につながる恐れがあります。
Data Plane APIの認証バイパスの条件と対応(編集部作成)作成: 編集部 / もとの資料: 情シスのミカタ編集部
公開時点(2026年10月)で、悪用やPoC(実証コード)の公開は確認されていません。CISAの「悪用が確認された脆弱性の一覧(KEV)」にも載っていません。とはいえ、認証なしで設定を書き換えられる重大な問題のため、対象なら早急な対応が必要です。
影響する会社・しない会社
影響するのは、HAProxyと一緒にData Plane APIを有効にして使っている会社です。設定の自動化、HAProxy Enterprise、KubernetesのIngressとの連携などで使われます。とくに、Data Plane APIの管理用のエンドポイントを、インターネットや信頼できないネットワークから届く状態で動かしている場合、緊急度が高くなります。発動の条件は、TLSのCAと数値のTLSポートの両方を設定している構成とされています。
一方、HAProxyを使っていても、Data Plane APIを使っていない会社は、今回の脆弱性の直接の対象ではありません。また、これはHAProxy本体(ロードバランサー)の欠陥ではなく、設定管理用のData Plane APIという別の部品の問題です。「HAProxyを使っている会社すべてが危ない」という話ではない点に注意してください。
情シスが今日やること
- Data Plane APIを使っているかを確認する: HAProxyの構成で、Data Plane API(dataplaneapi)を有効にしているかを確かめます。自動化のしくみやKubernetes連携で、知らないうちに使っていることもあるため、運用担当や委託先にも確認します
- 発動条件と公開範囲を確認する: TLSのCAと数値のTLSポートの両方を設定しているか、管理用のエンドポイントがインターネットや社外から届く状態になっていないかを確認します
- 修正版へ更新する: コミュニティ版は2.9.29、3.0.25、3.2.17、3.3.9、3.4.4で修正されています。Enterprise版は対応するee版へ更新します
- 公開範囲を絞る: Data Plane APIの管理用エンドポイントを、インターネットに公開せず、localhostや管理用のネットワークに限定し、ファイアウォールやアクセス制御で到達元を絞ります。公開していた場合は、認証情報の変更も検討します
- 記録を残す: 確認した構成、更新した版、対応日を資産台帳に残します
認証なしで設定を書き換えられるのは、ロードバランサーのように「通信の入り口」にある機器では、とくに影響が大きい問題です。Data Plane APIを使っている会社は、更新と、公開範囲の絞り込みを、あわせて進めてください。
