ModSecurityに脆弱性、WAFの検知をすり抜ける恐れ

オープンソースのWAFエンジン「ModSecurity」に、攻撃の検知をすり抜けられる脆弱性（CVE-2026-52747、CVSS 8.6）が公表されました。対象は libmodsecurity（v3系）の 3.0.0〜3.0.15、修正版 3.0.16 が2026年6月29日に公開済みです。厄介なのは、WAFが停止も乗っ取られもせず、「攻撃を攻撃と認識できなくなる」タイプだという点。ブロックログもエラーも出ないため、運用画面上は何の異常も見えません。自社のWAFがModSecurityベースなら、まずバージョンの確認を。

この記事でわかること

• 今回公表された2件のCVEの内容と、影響を受けるバージョン
• 「検知バイパス」型の脆弱性がなぜ気づきにくいのか
• 自社のWAFが対象かを見分ける手順（クラウドWAF・アプライアンスを含む）
• CVSS 8.6という評価の読み方（S:Cの意味、NISTとGitHubでスコアが割れた理由）
• OWASP CRS（ルール）を最新にしても直らない理由

何が起きたのか

OWASP ModSecurityプロジェクトは2026年6月29日、libmodsecurity 3.0.16 を公開し、2件の脆弱性を修正しました。いずれも「ルールによる検査をすり抜けられる」性質のものです。

実務上の優先度は明確です。CVE-2026-52761 はi386限定で、開発元も「このアーキテクチャ以外では発生しない」としています。64bit環境が主流の現在、多くの組織で対処が必要なのは CVE-2026-52747 のほう。ただし32bitのコンテナイメージや古いアプライアンスは例外です。

なぜログに何も残らないのか

WAFが正常に動作したまま、リクエストを「問題なし」と判定して通してしまうためです。ブロックしていないのでブロックログは出ず、クラッシュもしないのでエラーログにも残りません。

原因はCWE-180、つまり検証と正規化の順序が逆になっていることです。パーサが値を書き換えた後の文字列をルールが受け取るため、ルール側は「無害に見える文字列」を検査します。開発元の説明では A\r\nB が AB と連結された形でルールに渡されます。一方、バックエンドのWebアプリはリクエストボディを自分で解釈するため、改行が入ったままの元の値を受け取ります。つまりWAFが見ている文字列とアプリが受け取る文字列が食い違う状態です。たとえばSQLでは改行が空白と同じ区切りとして扱われるため、攻撃文字列の途中に改行を挟めばアプリ側では有効な構文のまま通り、WAF側のシグネチャには一致しない、という事態が仕組み上ありえます（この例は脆弱性の性質から導いた説明で、開発元が攻撃手法として公表したものではありません）。SQLインジェクションのような古典的な攻撃に対して、WAFという層だけが目隠しをされる状態です。

自社は影響を受けるのか

確認すべきポイントは2つ、「v3系を使っているか」と「そのバージョンが3.0.16未満か」です。

• 対象：libmodsecurity（ModSecurity v3系）の 3.0.0〜3.0.15。3.0.16 で修正済み。
• v2系（Apache用 mod_security2）：別コードベースであり、今回のアドバイザリの対象に含まれていません。v2側の変更履歴にも該当CVEの記載はありません。ただしv2は2026年4月28日公開の v2.9.13 でnginxサポートが削除されており、nginxでv2を使っていた環境はv3系へ移行する流れにあります。移行と同時に今回の対象範囲に入る点に注意してください。

バージョンの確認は、導入経路ごとに見る場所が変わります。

• nginx + コネクタ：nginx -V でModSecurityコネクタが組み込まれているかを確認し、あわせて libmodsecurity.so の実体を探す
• OSパッケージ：dpkg -l | grep -i modsecurity（Debian系）、rpm -qa | grep -i modsecurity（RHEL系）
• コンテナ：イメージ内に同梱されているため、ベースイメージの再ビルドが必要。稼働中のコンテナだけ見ても直らない
• クラウドWAF・アプライアンス製品：内部でModSecurityを利用している製品では自社に更新権がない。ベンダーに3.0.16の取り込み状況を問い合わせるのが唯一の確認手段になる

ここが実務上の落とし穴です。WAFはミドルウェアの一部やアプライアンスの内部部品として入ってくるため、資産管理ツールの「インストール済みソフトウェア一覧」には出てきません。外部公開面から棚卸しするEASM（外部攻撃対象領域管理）の考え方や、脆弱性管理の対象範囲にWAFエンジン自体が入っているかを、この機会に見直す価値があります。

CVSS 8.6はどう読むべきか

CVE-2026-52747 のベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N です。機密性 C:N・可用性 A:N がいずれも「なし」なのに8.6と高く出るのは、S:C（スコープ変更）と I:H が立っているからです。つまり壊れるのはModSecurity自身ではなく、その背後で守られているWebアプリケーション。WAFは無傷のまま、守るべき対象への影響だけが計上されています。

この解釈の揺れは、もう1件のCVEでスコアの割れとして表面化しました。CVE-2026-52761 は NIST が5.3、GitHub（CNA）が5.8 で、差はScope（S:U か S:C か）の1項目だけです。「WAFの内側のアプリまで影響範囲に数えるか」で判断が分かれた形です。なお CVE-2026-52747 のCVSS v4.0は執筆時点でNVD未割当です。

スコアの数字を追うより、①そのWAFが守っているアプリの重要度、②WAFを唯一の防御にしていないかの2点で優先度を決めるほうが実態に合います（CVSSの解説）。

ルールを最新にすれば防げるのか

防げません。欠陥はルールではなくエンジンのパース処理にあります。ルールが値を受け取る前の段階で文字列が書き換わっているため、OWASP CRS（コアルールセット）をどれだけ更新しても、どんなカスタムルールを書いてもすり抜けます。

WAF運用というと「ルールの更新」と「誤検知のチューニング」に注意が向きがちですが、今回のケースはそれとは別にエンジン本体のバージョン管理が必要だと示しています。WAFを「ルールを育てる製品」として捉えていると、この観点が抜け落ちます。

2026年に入って2回目の修正

今回が単発の事故でないことは、直近の修正履歴を並べると見えてきます。

いずれも入力のパース・変換処理に集まっています。WAFは「あらゆる形式の入力を受け取って解釈する」役割を負うため、構造的に不具合が出やすい領域です。だとすればCVEを1件ずつ追うより、WAFエンジンを通常のパッチ運用サイクルに載せることが本題になります。

情報が届くまでの時間差も押さえておきたい点です。修正版の公開は6月29日、NVD登録が7月10日、JPCERT/CC Weekly Reportでの言及が7月15日。国内の注意喚起だけを入口にしていると、OSSの修正から2週間以上遅れて気づくことになります。利用中のOSSは開発元のリリース情報を直接追う経路も併せて持つべきです。

現場目線の課題

正直なところ、WAFは「入れて終わり」になりやすい製品です。導入時にベンダーやSIerが構築し、以後の運用はルールのチューニングと誤検知対応が中心になります。エンジンのバージョンを資産台帳で追いかけている現場は、実感としてもかなりの少数派でしょう。クラウドWAFやアプライアンスなら自社に更新権すらなく、ベンダーの取り込みを待つ間に何が起きているかも見えない。この「自分では動かせない層に穴がある」もどかしさは、境界機器全般に共通する悩みです。

加えて、説明の難しさもあります。これまで「WAFを入れているので一定の攻撃は防げます」と経営層や事業部門に説明してきた分だけ、「WAFはあるが素通りしていた可能性がある」という報告はしづらいものです。だからこそ、WAFは多層防御の一枚であって唯一の壁ではない、という前提を平時から共有しておくことが効いてきます。

情シスはどうすべきか

対処自体は「3.0.16へ更新する（またはベンダーの取り込みを確認する）」で完結します。そのうえでWAFの位置づけを整理するなら、公的資料を起点にするのが早道です。

• IPA「Web Application Firewall 読本」：WAFの機能・限界・導入検討の観点が体系的に整理されています。現在はアーカイブ扱いですが、「WAFで何が守れて何が守れないのか」の枠組みは今も有効で、社内説明の土台に使えます。
• IPA「安全なウェブサイトの作り方」：すり抜けられても被害に至らせないには、結局アプリ側の実装が要です。プレースホルダの利用など根本対策はこちら。

あわせてIDS/IPSやアプリ側のログ監視を組み合わせておけば、WAFの検知が抜けた場合の受け皿になります。地道ですが、Web担当や開発委託先に「WAFの限界」を改めて周知しておくことも実装側の油断を防ぎます。

まとめ

• libmodsecurity 3.0.0〜3.0.15 に検知バイパスの脆弱性（CVE-2026-52747、CVSS 8.6）。修正版は3.0.16。ログに異常が出ないため、バージョンを見に行かないと気づけない。
• OWASP CRSなどルールの更新では直らない。欠陥はエンジンのパース処理側にあるため、エンジン本体のバージョン管理が別途必要。
• 導入経路の確認が最初の一歩。nginxコネクタ・OSパッケージ・コンテナ・アプライアンス内蔵と経路が多く資産一覧に出てこない。更新権がない製品はベンダーへ確認する。

出典

• OWASP ModSecurity「About CVE-2026-52747 and CVE-2026-52761」
• NVD – CVE-2026-52747
• NVD – CVE-2026-52761
• GitHub Security Advisory GHSA-rcw9-2f5r-7p88（CVE-2026-52747）
• ModSecurity v3.0.16 リリース
• JPCERT/CC Weekly Report 2026-07-15「ModSecurityに複数の脆弱性」
• IPA「Web Application Firewall 読本」