【速報】PHPの深刻な脆弱性「PHP2Shell」とは？確認できている事実と今できる対策を解説

2026年10月20日、PHPのセキュリティチームは、深刻度「Critical」の脆弱性2件を修正するセキュリティリリースを予告しました。公式発表に先立ってSNS上に情報が出回り、CVE番号や攻撃ツールの存在も報じられています。

一方で、影響を受けるバージョンや脆弱性の詳細は、現時点で公式には公表されていません。出回っている情報の中には、確認が取れていないものも含まれます。

本記事では、公式に確認できる事実と未確認の情報を区別して整理したうえで、修正版が公開されるまでの間に検討できる対策についてお伝えします。

• PHP公式は、CVSS v4.0で9.2と評価されたCritical脆弱性2件の修正版を、2026年10月21日23時（日本時間）に公開する予定です。状況によって変更の可能性があります。
• 影響を受けるバージョン、修正版のバージョン、技術的な詳細は、現時点で公式には公表されていません。
• 修正版の公開前にできることは、①PHP利用箇所の棚卸し、②暫定策の検討、③ログの保全、④修正版を即時適用する準備 です。
• 暫定策はPHP公式が示した対策ではありません。根本的な対策は修正版への更新であり、暫定策はそれまでのリスクを下げる手段と位置づけてください。

国内唯一のISMAP登録済
SBOM・脆弱性管理ツール

公式で確認できること

PHP公式サイト（php.net）が2026年10月20日に公開した告知の内容は、次のとおりです。

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0〜10で表す共通の指標です。9.0以上は最も深刻な「Critical」に分類されます。

PHP公式は、すべての利用者に対して「リリース後すぐに更新できるよう、今から準備すること」を呼びかけています。

また、欧州連合の機関向けにセキュリティ情報を発信するCERT-EUは、影響を受ける資産への即時のパッチ適用を準備するよう推奨しています。即時の適用が難しい場合は、インターネットに公開しているアプリケーションを、修正版が出るまで公開ネットワークから隔離することを検討するよう求めています。

報道・SNSで出回っている情報

公式告知の前後から、セキュリティ企業や研究者による情報発信が続いています。以下はPHP公式が確認していない情報を含みます。判断材料の一つとして参照し、公式情報が出た時点で必ず照合してください。

Sansecは「修正版の公開から短時間で大規模な攻撃が始まる」との見通しを示しています。修正版の公開によって差分から攻撃手法が分析されやすくなるため、公開後は可能な限り早く適用できる体制を整えておくことが重要です。

影響を受ける可能性がある環境

影響を受けるバージョンは確定していません。ただし、報じられている内容がPHP本体（コア）の処理に関わるものであれば、PHPで動くWebアプリケーション全般が対象になり得ます。

• WordPress、Drupal、MediaWiki、Magento（Adobe Commerce）などのCMS・ECサイト
• LaravelなどのフレームワークでつくられたWebアプリケーション
• 社内の管理画面や業務ツール
• 製品やアプライアンスに組み込まれたPHP

報道では、問題の処理はアプリケーションのコードが動く前の段階で実行されるとされています。そのため、「アップロード機能を使っていない」「CMSのプラグインで防御している」といった理由で、影響がないとは言い切れません。

サポートが終了したPHPに注意

PHP公式がセキュリティサポートを提供しているのは、8.2〜8.5のブランチです。

PHP 8.1以前はサポートが終了しているため、公式の修正版は提供されない見込みです。

サポート終了版を使っている場合は、後述の暫定策や隔離で当面のリスクを下げつつ、サポート対象バージョンへの移行を計画する必要があります。OSのディストリビューションや有償サポートによって修正が提供される場合もあるため、利用している提供元の情報もご確認ください。

修正版の公開前にできる対策

ここで紹介する暫定策は、PHP公式が示した対策ではありません。PHPのコア開発者は「唯一の対策はパッチの適用（PHPの更新）だ」と述べています。

暫定策は、修正版を適用するまでのリスクを下げるための手段として、効果と副作用を理解したうえで検討してください。

対策1：PHPの利用箇所を棚卸しする

最初に取り組むべきなのは、自社システムのどこで、どのバージョンのPHPが動いているかを把握することです。暫定策も修正版の適用も、対象が分からなければ進められません。

次の項目を一覧にしておくと、修正版の公開後にすぐ動けます。

検証環境、過去のキャンペーンサイト、サブドメインの管理画面、1台のサーバーに複数バージョンが入っているケースは見落とされがちです。レンタルサーバーやマネージドサービスを利用している場合は、事業者の対応予定を本日中に確認しておくことをおすすめします。

バージョンはphp -vで確認できます。ただし、コマンドラインで表示されるPHPと、Webサーバーが使っているPHPが異なる場合があります。DebianやUbuntuではls /etc/phpでインストールされているブランチを確認できます。

対策2：不要なmultipartリクエストをWebサーバーで遮断する

報道されている内容が正しければ、攻撃にはファイル送信などに使われるmultipart/form-data形式のリクエストが使われる可能性があります。ファイルアップロードが不要なサイトやパスでは、こうしたリクエストがPHPに届く前にWebサーバーで拒否することで、リスクをさらに下げられる可能性があります。

以下は設定の一例です。本番環境に適用する前に、必ず検証環境で動作を確認してください。

nginxの例（httpコンテキストに追加）

map $http_content_type $block_multipart {

default 0;

"~*multipart" 1;

}

PHPにリクエストを渡す各serverブロックの先頭に追加

if ($block_multipart) {

return 403;

}

Apache 2.4の例（バーチャルホスト設定など）

<If "req('Content-Type') =~ /multipart/i">

Require all denied

</If>

これらの設定では、Content-Typeにmultipartを含むリクエストを、メソッドを問わず拒否します。PHP 8.4以降ではPOST以外のメソッドでもmultipartを解析できるため、POSTだけに絞らないことが推奨されています。

• サーバーのIPアドレスに直接アクセスされる場合も想定し、既定のserverブロックやバーチャルホストにも設定します。
• Apacheでは%{CONTENT_TYPE}ではなくreq('Content-Type')を使います。前者はレスポンス側の値を指すため、意図どおりに遮断できません。
• 設定後は、外部からテスト用のmultipartリクエストを送り、拒否されることを確認します。

curl -sS -o /dev/null -w '%{http_code}\n' -F test=1 https://example.com/

遮断している間は、ファイルアップロードが使えなくなります。WordPressのメディアアップロードに加え、ファイル欄がなくてもmultipart形式で送信するフォーム（Contact Form 7など）も動作しなくなる場合があります。事業への影響を確認し、関係部署と合意したうえで実施してください。

アップロード機能が必要なパスを除外する方法もありますが、その場合、除外したパスは引き続き攻撃を受ける可能性がある点にご注意ください。

対策3：WAFの活用と、不要な公開の一時停止

WAF（Webアプリケーションファイアウォール）を利用している場合は、提供元から緊急のルール更新が出ていないか確認します。

WAFを経由せずにサーバーへ直接届く通信は防げないため、WAFだけに頼らず、サーバー側の対策と組み合わせてください。

検証環境や、今日使う必要のないPHPアプリケーションは、修正版を適用するまで公開を停止する、VPNの内側に移すといった対応も有効な選択肢です。サポート終了版のPHPを使っているシステムでは、隔離が現実的な手段になる場合があります。

対策4：ログを保全する

修正版の適用後に、それまでに侵入されていないかを確認する必要があります。デプロイやログのローテーションで記録が消える前に、WebサーバーとPHPのログを別の場所に退避しておいてください。

対策5：修正版を即時適用できるよう準備する

修正版を即時適用できるように、以下の準備をすすめてください。

• PHP公式サイトとアナウンス用メーリングリストを確認できる体制を用意する（前倒し公開の可能性があるため）
• 適用の優先順位（インターネット公開系を最優先）と担当者を決める
• 再起動手順と、適用後の動作確認項目を準備する
• 夜間の作業体制と、関係者への連絡ルートを決めておく

修正版の公開後にやること

修正版が公開されたら、次の順番で対応します。（※公開後に、公式情報をもとに本節を更新予定です）

1. PHP公式のアドバイザリで、影響を受けるバージョンと各ブランチの修正版を確認する
2. インターネットに公開しているホストから順に更新する
3. PHP-FPMやWebサーバーを再起動し、キューワーカーなどの常駐プロセスも再起動する
4. Dockerを使っている場合は、修正済みのベースイメージで再ビルド・再デプロイする
5. 動作確認後、必要に応じて暫定策（multipartの遮断など）を解除する
6. 保全したログをもとに、侵害の痕跡がないか確認する

DebianやUbuntuなどのディストリビューションは、修正を古いバージョン番号のまま取り込む（バックポートする）ことがあります。バージョン番号だけで判断せず、ディストリビューションのセキュリティ情報やパッケージの変更履歴を確認してください。

• 不審なmultipartリクエストや、PHPプロセスの異常終了がないか
• Webの公開ディレクトリやアップロード先に、新しく作られた・変更されたファイルがないか
• .user.iniやauto_prepend_fileの設定が変更されていないか
• cronや自動起動の設定、SSH鍵が追加されていないか
• PHPの実行ユーザーから想定外のプロセスや外部への通信が発生していないか

痕跡が見つかった場合は、サーバーを隔離してログを保存し、専門家への相談を含めて対応を検討してください。

緊急の脆弱性に、すぐ答えられる体制を

今回のように修正版の公開前に情報が出回るケースでは、「自社のどこで、どのバージョンが動いているか」をすぐに答えられるかどうかが、初動の速さを左右します。

脆弱性管理クラウド「yamory」は、ホスト、コンテナ、クラウド、アプリケーション内部のソフトウェア構成と脆弱性を一元的に可視化します。対応の優先順位を自動で判定するオートトリアージや、ソフトウェアのEOL管理、対応状況の管理にも対応しています。緊急時の棚卸しや、日々の脆弱性管理の効率化にお役立てください。

yamoryの資料をダウンロードする

• PHP: News Archive - 2026（Upcoming Critical PHP Security Release）
• PHP: Supported Versions
• PHP Manual: Session Runtime Configuration
• CERT-EU: Critical Vulnerabilities in PHP（2026-018）
• watchTowr: PHP Remote Code Execution FAQ
• Huntress: Rapid Response: php2shell
• Sansec: Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619

脆弱性管理クラウドyamoryの詳しい機能をご紹介しています。