React2Shell騒動の裏で繰り広げられた攻防 WAF回避とAI利用攻撃が突きつける「WAFの新要件」：「WAFが入っているから大丈夫」は危険

「WAFを導入しているから安心」という常識が今、音を立てて崩れている。2025年末に発生した「React2Shell」攻撃は、WAFの仕様上の死角を突く巧妙な回避手法を顕在化させた。生成AIを駆使し、自律的に攻撃パターンを変化させるAIエージェントの脅威も現実のものとなりつつある。高度化する「WAF回避」の猛攻を前に、WAFの新要件を解き明かす。

PR／＠IT

PR

　WebサイトやWebアプリケーションを公開する企業にとって、WAF（Web Application Firewall）の導入はもはや「当たり前」のセキュリティ対策だ。コンプライアンス要件やサプライチェーン管理の観点もあり、WAF未導入のWebサイトは少数派となった。

　しかし、WAFによる脅威検知のすり抜けを目的とした「WAF回避攻撃」が劇的に進化・増加して、「WAFさえあれば大丈夫」というこれまでの前提が崩れ始めている。

　本稿は2025年末に猛威を振るった「React2Shell」（CVE-2025-55182）攻撃や、AIエージェントによる攻撃手法、これからの時代に求められる「WAFの新要件」について解説する。

React2Shellで露呈した「WAF回避」のスピードと仕様上の死角

　2025年12月に世界中のWebサイト運営者に衝撃を与えたReact2Shell攻撃は、特定のフレームワークの脆弱（ぜいじゃく）性を悪用し、サーバ上で任意のコード実行を可能にするものだ。特筆すべきは、脆弱性がもたらす被害の深刻さだけでなく、攻撃者がWAFによる検知を回避するために驚くべきスピードで手法を変化させた点だ。

瞬く間に変化した攻撃パターンと「検査サイズ制限」の壁

　この脆弱性が報じられた直後に観測されたのは基本的な攻撃パターンだった。しかし、ごく短時間のうちにWAFによる検知を逃れるためのさまざまな攻撃パターンが試行され始めた。セキュアスカイ・テクノロジーのクラウド型WAF「Scutum」（スキュータム）もこの試みを大量に観測した。

　その中でも多くのWAF製品にとって致命的となったのが「リクエストボディーの検査サイズ制限」を悪用した回避攻撃だ。攻撃の手口はシンプルかつ巧妙だ。HTTPリクエストのボディー部先頭に大量のダミーデータを配置し、肝心の攻撃コード（ペイロード）はその後方に配置する。Webアプリケーションはパラメーターの順序を問わず処理するため、攻撃コードがデータの先頭でも末尾でも攻撃は成立する。ところが、クラウドインフラのオプションとして安価に提供されるものなど、WAF製品の多くはリクエストボディーの先頭数KB〜128KB程度までしか検査しない仕様が一般的となっていた。

　その結果、検査範囲を超えるデータをWebアプリケーションとWAFの両方で明示的に拒否している場合を除き、こうした仕様のWAFは先頭のダミーデータだけを見て「正常」と判断して、後方に隠された攻撃コードは検査さえせずに通過させてしまった。この場合、WAFは「存在しない」のと同義であり、導入による安心感がある分、対応の遅れにつながった。React2Shellの事例は、攻撃手法の変化がいかに速く、WAFの仕様上の死角を的確に突くかを見せつける結果となった。

WAFベンダーが抱える「検査範囲」と「コスト」「レイテンシ」のジレンマ

　なぜボディー全体を検査せず、回避の余地を残す仕様のWAFが多いのか。そこにはWAFベンダーが抱える「インフラコスト」と「レイテンシ」（遅延）との闘いがある。

　検査対象のデータ量が大きくなるほど、必要なCPUやメモリのリソース消費が増大し、ベンダーのインフラ原価を圧迫する。データをバッファリングして検査する時間が長引けば、Webサイトのレスポンス（レイテンシ）が悪化する。安価で高速なWAFサービスを提供するためには、検査範囲を限定することが「合理的」な判断とされていた。

　React2Shellの攻撃は、攻撃者の手法変化によって、この「合理的な手抜き」とも言える仕様が防御性能の決定的な差として顕在化した。ベンダーが検査範囲の上限を拡大するなどの対応に追われる間に、攻撃者はダミーデータのサイズを変えるなど、事態はいたちごっこの様相を呈した。

Log4Shellからの変化──攻撃の進化スピードと防御の限界

　WAF回避の動きは今回に始まったことではないが、そのスピードは桁違いに加速している。2021年に「Apache Log4j」の脆弱性（Log4Shell）が大きな問題となった際も、WAF回避を試みるさまざまな難読化パターンが観測された。当時からScutumはこうしたWAF回避や難読化への対策に既に力を入れており、初期段階でスムーズに対処できた。

　2026年現在、攻撃者はさまざまな自動化ツールや生成AIを駆使し、防御側の対応よりもはるかに速いサイクルで攻撃手法を変化させている。多くのWAF、特にシグネチャ主体の検知をするWAFは、攻撃の変化スピードに防御が追い付かない状態に陥っている。

生成AIエージェントによる「自律的攻撃」の脅威

　この「攻撃側と防御側の不均衡」は、今後ますます拡大する恐れがある。特に注目すべきは、生成AIを活用した自律的な攻撃エージェントの存在だ。

　2024年にイリノイ大学UIUCの研究者を含むチームが発表した論文^※では「GPT-4」を搭載したエージェントに、実在する公開後間もない未修正脆弱性の詳細なCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）情報を与えて攻撃ターゲットを指定するだけで自律的にコードを生成・実行し、対象とした15件の脆弱性のうち13件の悪用に成功したことが報告されている。大規模言語モデル（LLM）を用いたエージェントが、脆弱性を含む対象システムの構造理解から攻撃コードの生成・実行まで自律的に行えることが示唆された。

※LLM Agents can Autonomously Exploit One-day Vulnerabilities（Apr 2024）

　この研究以降のLLMの進化を考慮すると、人間よりもはるかに安価かつ高速に、無限に攻撃パターンを生成してくるAIエージェントの存在は、Webセキュリティ分野における従来の前提を根本から覆す。脆弱性の公表から数分で新しい手法の攻撃が大量に送り込まれてくる可能性がある時代に、WAFにこれまでとは次元の違う「新要件」が求められるようになるのは確実だ。

「基本性能」への回帰──シグネチャ依存からの脱却

　これからのWAFには何が必要なのかを考えると、「WAFとしての基本性能」への回帰に行き着く。

　WAFに求められる新要件は以下の5点だ。

1. 網羅性：
   通信の中で、攻撃コードが隠蔽（いんぺい）可能な全ての箇所をチェックする能力（ボディー全体と広範なヘッダを含む網羅的な検査）。
2. 汎用（はんよう）的な防御能力：
   難読化などのWAF回避攻撃に対し、個別対応ではなく構造的に検知できる能力。
3. 対AI防御能力：
   AIがアプリケーションの構造に合わせて動的に生成した攻撃ペイロードを、文脈から判断して検知する能力。
4. 誤検知防止性能：
   上記を満たしながらも可能な限り誤検知を発生させず、万が一発生しても「単なるオン／オフ」ではなく柔軟な確率調整ができる能力。
5. 総合的な技術力：
   レイテンシや利用コストを抑えながら、十分な検知パフォーマンスを実現するインフラ構築力。

　これらを満たすには、特定の文字列パターンとマッチングさせる「シグネチャ検知」を中心とするレガシータイプのWAFでは不十分だ。シグネチャ方式は、いわば「既知の悪いパターン」を単純に登録して待ち構える手法だ。そのため、React2Shellで見られた手法や、攻撃者がAIを使ってパターンを微修正したり、文字列の並びを変えたりして難読化を行えば、シグネチャには合致せず簡単にすり抜けられてしまう。また、シグネチャ方式は正常通信内の文字列に反応して誤検知する頻度が高く、対策としてそのシグネチャをオフにすると、今度はもともと止めようとしていた攻撃を通してしまうという根本的な課題を抱えている。

　これからのWAFは、表面的な文字列だけでなく、攻撃者の意図をセマンティック（意味論的）に解釈して検知するロジックをベースにすることが必須となる。

Scutumのアプローチ　死角を作らない検査とAI型エンジン

　こうした課題に対して、Scutumは10年以上前から独自の進化を遂げてきた。

ボディー全体と広範なヘッダを含む網羅的な検査

　リクエストボディーの検査範囲を制限せず、全体を検査する。React2Shellで見られたボディー部を長くする回避攻撃も標準で防御可能だ。

誤検知を減らす「AI型検知エンジン」

　シグネチャに依存せず、ベイジアンネットワークとアノマリ検知（機械学習）による確率推論を行う。文脈から正常な通信であることを判断し、誤検知を抑える。

国内開発、運用によるスピード対応

　国内での一貫した研究、開発、運用体制によって、攻撃パターン変化の高速化にも対応。Log4Shellなどでも24時間以内に防御ロジックを反映した実績を持つ。

事例：ファミリーマートが選んだ「基本性能」

　この「基本性能」の高さに着目し、Scutumを採用したのがファミリーマートだ。決済アプリ「ファミペイ」で金融機関レベルのセキュリティを求めた同社は、なぜScutumを選んだのか。比較検証のプロセスや運用の実態について、こちらの事例記事で詳しく説明している。

ファミリーマート Scutum導入事例

新要件に基づくWAFの見直しを

　攻撃の手法は進化しているが、防御の技術も進化している。WAF回避攻撃が一般化しても「当たり前のことを当たり前にやる基本性能」が高いWAFを選ぶことで、慌てることなくビジネスを継続している企業は多数存在する。AIの脅威にも、それに対抗し得るロジックを持つWAFであれば十分に渡り合える。

　「WAFが入っているから大丈夫」という考え方そのものが、Webセキュリティ対策における重大なリスクとなる。被害に遭っていない今こそが、WAFを見直す絶好のタイミングだ。今一度、導入済みのWAFの再点検をお勧めする。

• リクエストボディーの検査サイズに上限はないか（検査逃れが可能になっていないか）
• 誤検知が発生した際、安易にシグネチャをオフにする運用になっていないか
• 新しい脆弱性や回避手法に数時間から1日で対応できているか

　今から手を打てば、2026年の新たな脅威にも十分に間に合うだろう。セキュアスカイ・テクノロジーは、今利用中のWAFの検証をサポートし、必要に応じてScutumによる「基本性能」の高い防御環境を提案する。少しでも不安を感じた場合は、セキュアスカイ・テクノロジーに相談してみてはいかがだろうか。

※この記事は、ビットフォレストより提供された記事を＠IT編集部で一部編集したものです。