Cloudflare Pingora の脆弱性 CVE-2026-2833／2835／2836 が FIX：リクエスト・スマグリングなどに対応

Cloudflare Pingora Flaws Enable Request Smuggling and Cache Poisoning Attacks

2026/03/10 gbhackers — Cloudflare が公表したのは、同社のオープンソース・フレームワーク Pingora に存在する、複数の HTTP リクエスト・スマグリングとキャッシュ・ポイズニングの脆弱性を修正する、最新のセキュリティ・アドバイザリである。それらの脆弱性 CVE-2026-2833／CVE-2026-2835／CVE-2026-2836 が影響を及ぼす範囲は、インターネットへ直接公開されたスタンドアロンの Pingora デプロイメント (ingress proxy) となる。

その一方で Cloudflare は、自社の CDN および顧客トラフィックは影響を受けないと明確に説明している。同社のエッジ・ネットワークでは、Pingora を ingress proxy として使用していないため、内部基盤は悪用の対象とならないとしている。

脆弱性リクエスト・スマグリングの仕組み

リクエスト・スマグリングは、フロントエンド・プロキシとバックエンド・アプリケーション・サーバの間で、HTTP リクエスト境界の解釈が一致しない場合に発生する。

この不整合により、攻撃者は通常リクエスト内に悪意あるリクエストを埋め込み、別ユーザーのリクエストとしてバックエンドに処理させることが可能となる。

An attacker that sends an Upgrade request, then pipelines a partial HTTP request may cause a desync attack. (Source: Cloudflare)
An attacker that sends an Upgrade request, then pipelines a partial HTTP request may cause a desync attack. (Source: Cloudflare)

研究者である Rajat Raghav が特定したのは、Pingora における 3つのデシンク (desync) 攻撃の手法である。

問題のあるプロトコル・アップグレードのタイミング

攻撃者が HTTP Upgrade ヘッダーを送信すると、Pingora はバックエンドから 101 Switching Protocols 応答を受信する前に、パス・スルー・モードへと切り替えてしまう。

この動作を悪用する攻撃者は、Upgrade リクエスト直後に悪意の HTTP リクエストをパイプライン送信できる。Pingora は、このスマグリング・リクエストを検証せずにバックエンドへ転送するため、アクセス制御やセキュリティ・チェックが回避されてしまう可能性がある。

HTTP/1.0 フレーミングの誤操作

Pingora は、HTTP/1.0 リクエストにおける “Content-Length” と “Transfer-Encoding” が同時に存在する不正構文を厳格に拒否せず、”close-delimited” として処理する。

この不適切な解釈を悪用する攻撃者は、リクエスト末尾に部分的な HTTP ヘッダーを付加し、バックエンドとの深刻なデシンクを引き起こせる。

デフォルト・キャッシュ・キーの問題

3つ目は、キャッシュ・キー設計に起因する。デフォルト実装では URL パスのみを参照し、Host ヘッダーや HTTP スキームを考慮していなかった。その結果として、同一パスを持つ異なるサイト間でキャッシュ衝突が発生する。

それを悪用する攻撃者は、正規サイトの利用者に対して、改竄されたコンテンツを配信させるキャッシュ・ポイズニング攻撃を実行できる。

When an attacker pipelines a partial HTTP request header after the HTTP/1.0 + Transfer-Encoding request, Pingora would incorrectly interpret that partial header as part of the same request, rather than as a distinct request.(Source: cloudflare)
When an attacker pipelines a partial HTTP request header after the HTTP/1.0 + Transfer-Encoding request, Pingora would incorrectly interpret that partial header as part of the same request, rather than as a distinct request.(Source: cloudflare)
悪用による影響

スタンドアロン Pingora を、フロントラインのリバース・プロキシとして使用する組織は、重大なリスクに直面する。これらの脆弱性の悪用に成功した攻撃者は、以下を実行できる。

  • プロキシ層におけるセキュリティ制御 (カスタムルールや WAF) の回避。
  • リクエスト・デシンクによりセッションを乗っ取り、機密資格情報を窃取。
  • プロキシ・キャッシュの汚染を介した、悪意のペイロード配布。

すでに Cloudflare は、最新バージョンをリリースし、この問題に対処している。

現在の修正版では、HTTP フレーミング標準を厳格に適用し、チャンク転送符号を適切に検証し、接続アップグレード前にバックエンド確認を待機する設計へと変更されている。不安全なデフォルト・キャッシュ・キーも削除された。

対策
  • Pingora 管理チームにとって必要なことは、以下の項目の速やかな実施である。
  • Pingora を 0.8.0 へ即時アップグレード。
  • Ingress proxy ログ内で、異常な HTTP/1.0 リクエストや予期しない Upgrade ヘッダーを監視。
  • カスタム・キャッシュ・キー設計に Host ヘッダーおよび HTTP スキームを必ず含める。

Cloudflare が自社で開発しオープンソースとして公開している、Rust で書かれたプロキシ・フレームワーク Pingora で、リクエスト・スマグリングなどの深刻な脆弱性が修正されました。それらの問題の原因は、フロントエンド (外部からの受付) とバックエンド (実際の処理サーバ) の間で、”リクエストがどこで終わるか” という境界線の解釈を誤ってしまう、Pingora の設計にあります。ご利用のチームは、ご注意ください。よろしければ、Cloudflare での検索結果も、ご参照ください。