WordPressもBrotliの脆弱性の影響を受けうる

Googleが開発する圧縮ライブラリ「Brotli」のデコーダの脆弱性（CVE-2026-111497）が、2026年10月27日に米CISAの「既知の悪用された脆弱性（KEV）カタログ」へ追加されました。WordPressはBrotliを同梱しませんが、サーバーのlibcurl経由で受け取る応答がBrotliで圧縮されていれば、同じ脆弱性の影響を受けうると、セキュリティ企業のPatchstackが10月30日に解説しています。WordPress本体のアップデートでは直らない点が、今回の要点です。

修正の場所はWordPressではなくOSのBrotli
認証なしで届くのはpingback、oEmbedやフィードは条件つき
いま確認されているのは「落ちる」ところまで
まずBrotliを更新し、できなければ自動展開とpingbackを止める
本体やプラグインの更新では終わらない種類の対応
出典

修正の場所はWordPressではなくOSのBrotli

Patchstackによると、この脆弱性はBrotliデコーダの範囲外書き込み（out-of-bounds write）で、影響を受けるのはBrotli 1.0.3から1.2.0まで、修正版は1.0.10、1.1.1、1.2.1で、いずれも10月21日に公開されました。Debianのセキュリティトラッカーも、同じ影響範囲と修正版を載せています。Patchstackは、Googleによる深刻度評価が9.2だとしています。

Patchstackによると、WordPressの外部通信は、cURLが使える環境ではlibcurl経由で行われ、cURLのトランスポートがすべてのハンドルでCURLOPT_ENCODINGを空文字に設定しています。サーバーのlibcurlがBrotliに対応していると、相手の応答がBrotli圧縮であるときに、curl_exec()の内部でデコードされます。つまり、WordPressやプラグインを最新にしても、OS側のBrotliが古いままなら、脆弱性は残ります。

認証なしで届くのはpingback、oEmbedやフィードは条件つき

Patchstackが挙げる入口は、WordPress側が外部のURLを取りにいく機能です。

XML-RPCのpingback：認証なしでxmlrpc.phpへpingback.pingを送り、攻撃者のサーバーのURLを指定する（ピンバックを受け付ける公開済みの投稿が必要で、初期状態では存在します）
プラグインやテーマが、訪問者指定のURLをwp_remote_get()やwp_safe_remote_get()で取得する処理
oEmbedやフィード取得（SimplePie）：oEmbedは投稿者権限以上のアカウント、フィードは管理者が設定したものが対象で、誰でも突ける経路ではありません

攻撃用のペイロードは、攻撃者のサーバーが返す応答の中に入ります。そのため、サイトへのリクエスト内容を見て止めるWAFでは見分けにくい、とPatchstackは説明しています。PHP製のファイアウォールでも、PHPが実行される前にlibcurlがデコードするため、間に合いません。

いま確認されているのは「落ちる」ところまで

Patchstackが紹介する検証（10月27日公開）で確認できたのは、サービス拒否（PHPのワーカーのクラッシュや、CPU使用率100%に張り付く状態）です。WordPress/PHPの環境でのコード実行は、確認されていないとしています。公開されているシェルの攻撃チェーンはNode.jsとBun向けで、PHP（ApacheやFPM）向けのものはまだない、という整理です。同じサーバーでNode.js製のツールも動かしている場合は、その点も確認してください。一方、CISAのKEVカタログの説明は、細工されたBrotliの圧縮ストリームによって、サービス拒否のほか、メモリ内容の開示や任意のコード実行の可能性があると書いています。KEVの名称は「Unchecked Return Value Vulnerability」で、Patchstackの「範囲外書き込み」とは呼び方が異なりますが、同じCVE番号です。

KEVに載っているのは、悪用が確認されているためです。対応期限は、米連邦機関向けに2026年11月10日と定められています。日本の事業者に直接の期限はありませんが、対応を急ぐ目安にはなります。

まずBrotliを更新し、できなければ自動展開とpingbackを止める

根本対策は、Brotliの修正版への更新です。Linuxのディストリビューションなら、セキュリティ更新（libbrotli1など）を適用します。気をつけたいのは、DebianやUbuntuが、既存のバージョンのパッケージに修正を取り込む（バックポート）形で対応している点です。たとえばDebianのトラッカーでは、bookworm（Debian 12）は1.0.9-2+deb12u1、trixieは1.1.0-2+deb13u1が修正済みとされています。バージョン番号が古く見えても修正済みの場合があるので、dpkg-queryでパッケージのリビジョンを確認します。DockerのWordPress公式イメージ（wordpress:latest）は、Patchstackによると、まだ脆弱なパッケージを含んでいるため、自分のレイヤーでパッケージを更新する必要があります。

すぐ更新できない場合の一時的な回避策として、Patchstackは次の3つを挙げています（Patchstackは、どれもライブラリ更新の代わりにはならないとしています）。

http_api_curlフックで、CURLOPT_ENCODINGをidentityに、CURLOPT_HTTP_CONTENT_DECODINGを0にして、libcurlによる自動展開を止める（mu-plugin向け）
xmlrpc_methodsフィルターでpingback.pingとpingback.extensions.getPingbacksを外す。なお、xmlrpc_enabledフィルターではpingbackは止まらない
ApacheやnginxでXML-RPCへのアクセスを拒否する。ただしoEmbedやプラグインの経路は残る

外向き通信でContent-Encoding: brの応答が返る、ApacheのログにAH00051が出る、PHP-FPMがsignal 11で落ちる、といった症状は、検知の手がかりになります。コアダンプにlibbrotlidec.soが現れたら、この脆弱性を疑ってください。ほかに、xmlrpc.phpへの認証なしのpingback.pingのPOST（宛先が見慣れない、または新しく登録されたドメイン）、クラッシュせずにCPU使用率100%のまま止まる、www-dataがシェルやcurlを起動している、といった兆候も挙げられています。更新後は、ステージングなどで外部通信を確かめてください。

本体やプラグインの更新では終わらない種類の対応

この件の要点は、修正の場所がWordPressの更新画面に一度も出てこないことです。直したいコードはOSのlibbrotliにあり、WordPress 7.1.4（10月28日）にもBrotliの修正は入っていません（WordPress.orgの7.1.4のリリース記事には、Brotli、cURL、このCVEへの言及はありません）。そのため「どの層を誰が更新するか」で対応を分けるのが近道です。VPSやDockerならlibbrotli1のリビジョン確認とイメージの再ビルドを、共用のレンタルサーバーなら事業者の告知を確認したうえで、http_api_curlでの自動展開の停止とpingbackの停止を、利用者側でできる防御として入れておきます。回避策のフィルターは外部APIやフィードの取得にも効くため、ステージングで取得処理を一通り確かめてから本番へ入れてください。