AWSの防御「WAF」をすり抜ける脆弱性 CVE-2026-13762/13763、CloudFrontとロードバランサで攻撃が素通りの恐れ

Amazonのクラウド「AWS」で、Webサイトやアプリを攻撃から守る防御機能「AWS WAF（ワフ）」に、深刻な脆弱性が2件見つかりました。攻撃用の通信を細かく分割して送りつけると、WAFが中身を最後まで検査しきれず、悪意あるデータがそのまま通り抜けてしまう欠陥です。共通脆弱性番号は CVE-2026-13762（CloudFront向け）と CVE-2026-13763（ロードバランサ向け）、深刻度はいずれもCVSS 9.8（10点満点）。AWSは2026年6月29日にセキュリティ情報を公開しました。

WAFは、SQLインジェクション（データベースを不正操作する攻撃）などの悪意ある通信を入口で止める「防御の壁」です。多くの企業が、AWSの配信サービス「CloudFront」や負荷分散の「ロードバランサ（ALB）」の前段にWAFを置いて、自社サイトやAPIを守っています。その壁に隙間が空いていたことになります。CloudFront向けのCVE-2026-13762はAWS側で自動的に修正済みで利用者の対応は不要ですが、ロードバランサ向けのCVE-2026-13763は利用者自身が設定を変える必要があります。詳細は AWSの公式セキュリティ情報（2026-048）にまとまっています。

※CVSSはNVD（CVSS v3.1）基準の値。AWSが採用するCVSS v4.0では7.9です。いずれもログイン不要で、外部から仕掛けられます。

この欠陥は誰に、どんな被害をもたらすのか

この穴を突くのは、AWS WAFで守られたWebサイトやAPIに、SQLインジェクションなどの攻撃データを送り込もうとする攻撃者です。WAFは通常、送られてくる通信の中身（リクエスト本文）を検査し、危険なパターンを見つけたら遮断します。攻撃者にとってWAFは突破すべき関門ですが、今回の欠陥はその検査を正面から破るのではなく、すり抜ける手口を与えてしまいました。ログインは不要で、インターネット越しに誰でも試せます。

手口はこうです。通信の新しい方式「HTTP/2」で、攻撃データ本文を複数の小さなかけら（フレーム）に分割して送り、WAFには本文の一部しか検査させないようにします。WAFが「危険なものはなかった」と判断して通した後で、背後のサーバーは分割されたデータを元どおりに組み立てて処理するため、検査をすり抜けた悪意ある中身がそのままアプリへ届いてしまいます。

被害の本質は、「守っているつもり」の防御が実は素通しになっている点です。WAFを信頼してアプリ側の対策を簡素にしている場合、SQLインジェクションや不正な入力が背後のアプリに到達し、データの抜き取りや改ざんにつながりかねません。怖いのは、攻撃が成功しても表面上は普通の通信に見え、気づきにくいことです。なお、通信方式HTTP/2の細かな仕様を突く攻撃は近年たびたび問題になっており、当サイトでもHTTP/2の仕組みを悪用してWebサーバーを停止させる脆弱性を取り上げています。

WAF・CloudFront・ロードバランサとは何か

AWS WAF（Web Application Firewall）は、WebサイトやAPIに届く通信を検査し、攻撃とみなしたものを遮断する防御サービスです。SQLインジェクションやクロスサイトスクリプティング（不正なスクリプトを埋め込む攻撃）などをブロックする「あらかじめ用意されたルール集（マネージドルール）」を有効にして使うのが一般的です。

このWAFは単体では使わず、通信の入口に立つ別のサービスと組み合わせます。Amazon CloudFrontは、世界中に配置した拠点からコンテンツを高速配信するサービス（CDN）。Application Load Balancer（ALB）は、たくさんのアクセスを複数のサーバーに振り分ける負荷分散サービスです。どちらもWebサービスの最前線に置かれ、その手前でWAFが通信を検査します。今回の脆弱性は、この「WAF＋CloudFront」「WAF＋ALB」という、AWSで広く使われる定番構成に影響します。

2件の脆弱性、それぞれの中身

CVE-2026-13762：CloudFront経由のWAFすり抜け（自動修正済み）

CloudFrontの前段にAWS WAFを置いている構成で、細工されたHTTP/2の分割リクエストにより、本文の検査が不完全になる欠陥です。これにより、本来WAFが止めるべき攻撃データが検査をすり抜けます。こちらはAWS側のサーバーで修正が完了しており、利用者が行うべき作業はありません。CloudFrontを使っているだけで、すでに保護された状態です。

CVE-2026-13763：ロードバランサ（ALB）経由のWAFすり抜け（要設定変更）

Application Load BalancerでHTTP/2を有効にしたターゲットグループにAWS WAFを組み合わせている構成で、複数フレームに分割したHTTP/2リクエストにより、本文の一部しか検査されない欠陥です。CloudFrontと異なり、こちらは利用者側での設定変更が必要です。AWSは2026年5月22日に対策用の設定を提供しており、ターゲットグループの属性で、HTTP/2の通信を「十分なデータがそろってからWAFで検査する」挙動に切り替えることで、本文全体が検査されるようになります。

なぜ「分割」で検査をすり抜けられるのか

今回の鍵は、通信方式「HTTP/2」の仕組みにあります。HTTP/2では、ひとつのリクエストの本文を「フレーム」と呼ぶ複数のかけらに分けて送れます。本来、検査する側（WAF）と処理する側（アプリのサーバー）は、これらのかけらを同じように組み立てて同じ中身を見るべきです。ところが、WAFが本文の途中までしか見ずに判断してしまうと、検査側と処理側で「見ている中身」がずれます。

攻撃者は、このずれを意図的に作り出します。危険なデータを、WAFが検査する範囲の外（後ろのフレーム）に押し込むように分割すれば、WAFは「問題なし」と判断し、背後のサーバーだけがその危険なデータを受け取って処理します。検査する側と処理する側で解釈が食い違うこの種の問題は、「HTTPリクエストスマグリング（密輸）」（CWE-444）と呼ばれます。対策は、WAFが本文を最後まで（十分な量がそろってから）検査するようにして、このずれをなくすことです。

いま何をすべきか

対応はサービスごとに分かれます。CloudFront（CVE-2026-13762）はAWSが自動で修正済みのため、利用者の作業は不要です。一方で、Application Load Balancer（CVE-2026-13763）を使い、WAFと組み合わせてHTTP/2を有効にしている場合は、設定変更が必要です。ターゲットグループの属性で、HTTP/2通信をWAFで検査する挙動を、データがそろってから検査する方式へ切り替えてください。具体的な手順は AWSのセキュリティ情報とターゲットグループのドキュメントを確認してください。

まずは自社の構成で、どこにWAFを置き、どのサービス（CloudFront／ALB）と組み合わせ、HTTP/2を有効にしているかを棚卸しするのが第一歩です。WAFのボディ検査（リクエスト本文の検査）に頼って攻撃を止めている場合は、ALBの設定変更を優先してください。あわせて、WAFはあくまで多層防御の一枚であり、アプリ側でも入力チェックやパラメータの安全な扱いを徹底しておくことが、こうしたすり抜けへの最終的な備えになります。

まとめ

CVE-2026-13762とCVE-2026-13763は、AWS WAFがHTTP/2の分割リクエストの本文を検査しきれず、攻撃データがすり抜ける欠陥です。CloudFront向けはAWSが自動修正済みで対応不要、ロードバランサ（ALB）向けは利用者の設定変更が必要です。WAFという「守りの壁」に空いた隙間ゆえ、対象構成の利用者は早めの確認をおすすめします。

防御サービスを入れていても、その仕組みの細部を突かれれば守りは崩れます。WAF任せにせず、構成の棚卸しとアプリ側の対策を合わせて見直す機会にしたいところです。

よくある質問

参照元

• ・AWS — Security Bulletin 2026-048（CVE-2026-13762 / CVE-2026-13763）
• ・NVD — CVE-2026-13762（CloudFront）
• ・NVD — CVE-2026-13763（Application Load Balancer）
• ・AWS — ターゲットグループ（ALB）ドキュメント
• ・AWS — AWS WAF
• ・MITRE — CWE-444（HTTPリクエストスマグリング）