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

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

PHP 本体の脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）を直した修正版、PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が 2026年10月21日に公開されました［php.net］。どちらの脆弱性も、認証なしで外部からプログラムを実行される（RCE）おそれがあります。脆弱性の概要はphp2shell の解説記事をご覧ください。

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

公開前は、PHP 公式は回避策を出していませんでした。修正版の公開と同時に出たセキュリティアドバイザリで、初めて公式の緩和策が示されています［php.net］。

PHP 公式が発表した緩和策

PHP 公式のアドバイザリは、すぐに更新できない場合の対策を、脆弱性ごとに挙げています。前置きとして「完全な対策は更新だけで、以下の対策は特定の攻撃の経路を減らすが、インストールを安全にするものではない」と書いています［php.net］。

CVE-2026-109618（メモリ不足の処理で内部のデータがおかしくなる）

メモリが足りなくなったときの処理で、PHP が初期化の途中のデータを正しいものとして扱ってしまう脆弱性です。公式の緩和策は次の3つです［php.net］。

• memory_limit=-1 にする：アプリから上書きできない形で設定します。公式は、PHP-FPM のプールや Apache の設定の php_admin_value を例に挙げ、プール・ディレクトリ・アプリのどこかで有限の値に戻されていないかも確かめるよう求めています。これで攻撃者が PHP のメモリ上限を使ってエラーを起こすことはできなくなりますが、メモリの確保そのものの失敗からは、まだ脆弱な処理に届くことがあるとしています。
• post_max_size を小さくする：ファイルのアップロードが要らないアプリは 8M、アップロードが必要なら 32M を目安とし、upload_max_filesize は post_max_size より小さくします。Web サーバーやプロキシの側でも、リクエストの大きさ、入力項目の数、multipart のパートの数、ヘッダーの数、入れ子の深さに上限をかけることを検討するよう勧めています。この上限は、Content-Length が使えないリクエストにもかかるようにします。
• コンテナや cgroup でメモリに上限をかける：サーバー全体が使えなくならないよう、問題のワーカーだけを止める設定が望ましいとしています。RLIMIT_AS や RLIMIT_DATA で代わりにしてはいけない、とも書いています。これらは脆弱なメモリ確保の失敗を起こしうるためです。

CVE-2026-109619（解放したはずの状態が次のリクエストに残る）

リクエストのために確保したメモリを解放したあとも、その場所を指す内部の状態が残り、同じワーカーが処理する次のリクエストがそれを使ってしまう脆弱性です。公式の緩和策は次の4つです［php.net］。

• session.upload_progress.enabled=0 にして、すべてのワーカーを再起動する：確認されているセッションの経路はふさげますが、ほかの変形はふさげません。詳しくは次の節で説明します。
• PHP 8.5 では fatal_error_backtraces=0 にして、すべてのワーカーを再起動する：確認されている、致命的エラーのバックトレース（エラーまでの呼び出し履歴）を使う経路だけをふさぎます。
• リクエストごとに当てている設定のうち、無効なものや非推奨のものを取り除く：初期化の前に警告などを出す設定が対象です。error_reporting や display_errors、@ で表示を隠しても効果はありません。
• 攻撃者が起こせる致命的エラーや実行時間切れを直す：コールバック、アップロードやインポートの処理、後片付けの処理で起きる失敗も含みます。

session.upload_progress の無効化

Session Upload Progress とは

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

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

修正版の公開前、国内のセキュリティ企業 GMO Flatt Security は、php2shell がこの機能に関係していると推定していました。公開後の PHP 公式のアドバイザリでは、この設定が CVE-2026-109619 の緩和策の1つとして挙がっています［php.net］。

公式も「確認された経路だけ」をふさぐ策としている

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

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

PHP 公式も、この設定でふさげるのは確認されているセッションの経路で、ほかの変形はふさげないとしています［php.net］。CVE-2026-109618 には効かないので、入れても修正版が要ることは変わりません。窓の杜や ITmedia も、記事を修正して GMO Flatt Security の追記と同じ趣旨を伝えています。

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

副作用と設定のしかた

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

設定する場所について、PHP 公式は、php.ini、PHP-FPM のプール設定、リクエストの解析より前に効くサーバーの設定を使い、ini_set() や PHP-FPM の .user.ini には頼らないよう書いています。設定したら、すべてのワーカーを再起動します［php.net］。レンタルサーバーで変えられるかどうかや手順は、サーバー会社の案内を確認してください。

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

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

この方法は、PHP 公式の緩和策には入っていません。公式が挙げているのは、multipart を全部断ることではなく、Web サーバーやプロキシで multipart のパートの数やリクエストの大きさに上限をかけることです［php.net］。

全部断る場合は副作用が大きく、次の点に注意が必要です。

• 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 がこれを「一時しのぎ」と位置づけていることも伝えています。WAF のルールは、PHP 公式の緩和策には入っていません。

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

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

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

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

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

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

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

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

PHP 公式も、mod_php では認証なしのリクエストで、アプリのコードが動く前に攻撃を起こせることが実証されているとしています［php.net］。メンテナンスモードで防げないのは、このためです。

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

暫定策の比較

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

結論：根本対策はパッチ

PHP 公式は、完全な対策は更新だけで、緩和策を入れてもインストールが安全になるわけではないとしています［php.net］。GMO Flatt Security も「根本的にはパッチが必要」と書いています。暫定策を入れたから更新を後回しにしてよい、ということにはなりません。

1. 修正版をすぐに当てる：PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 に更新します。当てたあとは PHP-FPM か Web サーバーを再起動し、Web 側で動いている PHP のバージョンを確かめます。Linux ディストリビューションには修正が事前に渡されているので、ディストリのパッケージを使っている場合は、その更新を確かめます［php.net］。
2. remi のリポジトリを使っている場合は注意する：PHP 公式は、有志が運営する rpms.remirepo.net には当日は更新が出ないとして、ディストリのパッケージに切り替えるか、ソースからビルドするよう勧めています［php.net］。
3. レンタルサーバーなら、サーバー会社の告知を確認する：PHP 本体の更新はサーバー会社が行うことが多いので、適用の予定と完了の告知を確認します。
4. 修正版を当てるまでの間に、暫定策を組み合わせる：サーバーの設定を変えられるなら、PHP 公式の緩和策を php.ini やプール設定で入れ、すべてのワーカーを再起動します。ほかの策は、自社のサイトの使い方と副作用を確かめたうえで選びます。
5. 暫定策は、更新後に元に戻す：multipart の遮断ルールなど、業務に影響するものは外します。memory_limit や post_max_size を変えた場合も、元の値に戻すかを決めます。
6. 更新後に、乗っ取られていないかを確かめる：更新前に入り込まれていた場合、その跡は更新後も残ります。

参考にした情報

• php.net「Security advisory: Critical remote code execution vulnerabilities, update now」 / サポート中のバージョン
• GitHub（php-src）のセキュリティアドバイザリ：GHSA-w8hw-w9fx-j79w（CVE-2026-109618） / GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• 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（いずれも二次情報）
• 窓の杜（Yahoo!ニュース） / ITmedia NEWS