php.iniの設定変更やWAFで防げる？ php2shellの暫定策の効果と限界

なぜ暫定策が話題になっているのか

PHP 本体の脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）の修正版は、2026年10月21日 23:00（日本時間）に公開される予定です［php.net］。この記事は公開前の 21日夜に書いています。脆弱性の概要はphp2shell の解説記事をご覧ください。

今回は修正版の公開前に情報が漏れたとされ、それまでの間にできることとして、いくつかの暫定策がセキュリティ企業から示されました。修正版が出たあとも、レンタルサーバー会社の作業待ちや、更新後の動作確認で、すぐには当てられないサイトがあります。その間に暫定策をどこまで頼れるのかを、出典ごとに整理します。

なお、PHP 公式は 21日夜の時点で回避策を発表していません。告知には「詳細、影響バージョン、修正版はリリースと同時に公開する」とあるだけです［php.net］。以下の暫定策は、どれもセキュリティ企業や海外の公的機関によるものです。

php.ini の設定変更（session.upload_progress）

Session Upload Progress とは

Session Upload Progress は、ファイルのアップロード中に、その進み具合（何バイト届いたか、終わったか）を PHP がセッションに記録する機能です。アップロード画面の進捗バーを作るときに使います［php.net マニュアル］。

PHP のマニュアルによると、この情報はスクリプトが実行される前にセッションへ書き込まれます。つまり WordPress などのアプリが動く前に、PHP 本体が処理しています。初期設定は session.upload_progress.enabled = 1（有効）です。

国内のセキュリティ企業 GMO Flatt Security は、php2shell がこの機能に関係していると推定しました。ただし技術的な詳細は公式には公開されておらず、原因は確定していません。

提案から「やや緩和」への追記まで

GMO Flatt Security は 21日に公開したブログで、パッチ前の対策として session.upload_progress.enabled=0（機能を無効にする）を提案しました。その後、同日 14時付けで次のように追記しています。

本設定変更は、役に立つ可能性はありますが、攻撃は依然として可能であると見られ、ややの緩和策に留まります。根本的にはパッチが必要です。［GMO Flatt Security］

同じ追記で、この設定だけでは緩和にとどまり、攻撃そのものは避けられない見込みだとも書いています。窓の杜や ITmedia も、記事を修正して同じ趣旨を伝えています。

海外の Sansec と Patchstack は、この設定に session.use_strict_mode = 1（初期化されていないセッション ID を受け付けない設定）を組み合わせる方法を挙げています。ただし、どちらも「保証にはならない」「脆弱性を直すものではない」としています。Sansec によると、セッションを Redis やデータベースに保存しているサイトでは、strict mode が働かないため効果がありません。

副作用と設定のしかた

副作用は小さいとされています。Patchstack によると、止まるのは進捗バーで、アップロードそのものは通ります。Sansec によれば、Magento・Shopware・WooCommerce はもともと PHP の進捗バー機能を使っていません。

この項目は、PHP のマニュアルで INI_PERDIR（php.ini や .htaccess など、ディレクトリ単位の設定で変える項目）に分類されています。プログラムの中から ini_set() で変えることはできません。レンタルサーバーでは、管理画面の php.ini 設定で変えられる場合があります。変えられるかどうかや手順は、サーバー会社の案内を確認してください。

WAF・Web サーバーで multipart 送信を遮断する

multipart/form-data は、ファイル付きのフォームを送るときの形式です。Sansec は、PHP がアプリのコードより前にこの形式のデータを解析する点を攻撃の入口と見ています。そのため、Web サーバー（nginx や Apache）や WAF（Web アプリへの攻撃を見分けて止める仕組み）の段階で、この形式の送信を断るよう提案しています。PHP に解析させなければ、PHP の問題は表に出ないという考え方です。

ただし、この方法は攻撃の入口についての推定にもとづいています。効果について公式の裏付けはありません。

副作用は大きく、次の点に注意が必要です。

• Sansec は、サイト全体で遮断するとサイトのすべてのファイルアップロードが止まるとしています。WordPress のメディアライブラリへの画像追加もできなくなります。
• ショップによっては、カートや決済のフォームも multipart で送ります。Sansec は、ルールを入れたらテスト注文をするよう勧めています。
• Patchstack は、遮断する場所をファイルを受け付けないページに絞るよう勧めています。広く遮断すると、メディアライブラリ、添付ファイル付きの問い合わせフォーム、決済やアカウントのページが動かなくなると注意しています。

このルールは、PHP を更新したら外します［Sansec］。VPS や専用サーバーで Web サーバーの設定を自分たちで変えられる場合の選択肢で、共用のレンタルサーバーでは、利用者が設定できないことが多いと考えられます。

Cloudflare の緊急ルール

changelog で確認できたこと

Cloudflare の公式の更新履歴（changelog）には、10月21日付けで2件の緊急リリースが載っています。

• Cloudflare Managed Ruleset に「Generic Rules - Anomalous Execution - 1〜4」の4つのルールを追加。本文では「2つはブロック、2つはログのみ」とありますが、表では4つともブロックになっていて、食い違っています。
• Cloudflare Free Ruleset にも緊急リリース。本文は「2つのルール」、表は4つのルールを載せていて、こちらも食い違っています。

changelog には PHP や CVE 番号の記載はありません。これらのルールが php2shell 向けだという説明は、Sansec や Patchstack などの二次情報です。両社によると、ルールは無料プランを含むすべての利用者に提供されています。両社は、Cloudflare の CTO がこれを「一時しのぎ」と位置づけていることも伝えています。

オリジン直アクセスという抜け道

Cloudflare の WAF は、Cloudflare を通ってくる通信だけを検査します。サイトのサーバー（オリジン）の IP アドレスを攻撃者が知っていれば、Cloudflare を通さずにサーバーへ直接送れます。Sansec は、ルールが守るのはオリジンが Cloudflare 以外からの接続を断っているサイトだけだとしています。

Cloudflare の開発者向けドキュメントは、オリジン側で Cloudflare の IP アドレス（cloudflare.com/ips で公開）からの通信を許可し、それ以外を遮断する設定を推奨しています。理由として、そうしないと Cloudflare の防御を素通りした通信がサーバーに届くと書いています。ただし、設定を誤ると正規の訪問者の通信まで届かなくなるとも注意しています。

これから Cloudflare を使い始める場合、Sansec は、無料プランでネームサーバーを切り替える作業には何時間もかかることがあると書いています。修正版が公開される夜中に慌てて始めるより、修正版の適用を確実にするほうが現実的です。

サイトを公開網から切り離す

EU の機関向けの CERT-EU は、すぐにパッチを当てられない場合、インターネットに公開しているアプリを、修正を適用できるまで公衆網から切り離すことを検討するよう勧めています。CERT-EU 自身、この勧告の内容は漏えいした情報にもとづく予備的なものだとしています。

サイトを止めれば、外からの攻撃は受けません。その代わり、問い合わせや注文が止まります。Sansec は、1日止められるならそうするのがよいとする一方で、注意点も挙げています。

• WordPress や Magento のメンテナンスモードでは防げない。アプリがメンテナンス中かどうかを判断する前に、PHP がリクエストを解析するため
• 止めるなら PHP-FPM を停止し、PHP を通さない静的なメンテナンスページを出す
• 閲覧だけ残したい場合は、GET と HEAD 以外のリクエストを断る方法もある（ログインや注文はできなくなる）

Patchstack も、すぐに更新できないリスクの高いサイトには、更新が出るまで止めることを検討するよう勧めています。決済や個人情報を扱うサイトで、修正版をいつ当てられるか分からない場合の選択肢です。レンタルサーバーでは PHP-FPM を自分で止められないことが多いので、サーバー会社の管理画面で公開を止められるかを確認します。

4つの暫定策の比較

ここまでの4つの暫定策と修正版への更新を、効果・副作用・おすすめ度で比べたのが図3です。おすすめ度は、修正版を当てるまでの時間稼ぎとして、Webセキュリティ診断センター編集部が判断した目安です。効果と副作用の出典は、それぞれの節に書いたとおりです。

結論：根本対策はパッチ

GMO Flatt Security は「根本的にはパッチが必要」と書き、Sansec の記事でも「PHP を更新することが唯一の緩和策」という発言が引用されています。SOCRadar も、PHP は回避策を出しておらず、更新が提供元の裏付けのある唯一の修正だとしています。暫定策を入れたから更新を後回しにしてよい、ということにはなりません。

1. 修正版が出たら、すぐに当てる：当てたあとは PHP-FPM か Web サーバーを再起動し、Web 側で動いている PHP のバージョンを確かめます。
2. レンタルサーバーなら、サーバー会社の告知を確認する：PHP 本体の更新はサーバー会社が行うことが多いので、適用の予定と完了の告知を確認します。
3. 修正版を当てるまでの間に、暫定策を組み合わせる：upload_progress の無効化は副作用が小さいので補助として、ほかの策は自社のサイトの使い方と副作用を確かめたうえで選びます。
4. 暫定策は、更新後に元に戻す：multipart の遮断ルールなど、業務に影響するものは外します。
5. 更新後に、乗っ取られていないかを確かめる：更新前に入り込まれていた場合、その跡は更新後も残ります。

参考にした情報

• php.net（PHP 公式のセキュリティリリース告知） / サポート中のバージョン
• PHP マニュアル「Session Upload Progress」 / 「Runtime Configuration（セッション）」
• CERT-EU Security Advisory 2026-018
• Cloudflare changelog（Managed Ruleset 緊急リリース） / （Free Ruleset 緊急リリース） / Cloudflare IP addresses
• GMO Flatt Security ブログ
• Sansec / Patchstack / SOCRadar（いずれも二次情報）
• 窓の杜（Yahoo!ニュース） / ITmedia NEWS