PHP2Shellとは、PHP本体に見つかった2件の重大な脆弱性（CVE-2026-109618・CVE-2026-109619）の通称です。攻撃者はログイン不要で、Webサーバーへのリクエストだけで任意のコードを遠隔実行できます。
2026年10月21日に修正版が公開されましたが、そのわずか3日後には実際の攻撃が確認されています。PHPでWebサイト・ECサイト・社内システムを運用している企業がすぐに行うべきことは、稼働中のPHPバージョンの確認、パッチ適用（できない場合は隔離）、そして未対策期間の侵害調査の3つです。
本記事では、PHP2Shellの概要と自社での確認方法、そしてHBLABが実際に用いているフレームワーク・バージョン別の対応チェックリストを解説します。
1. PHP2Shellとは？
PHP2Shellが危険なのは、問題が特定のプラグインやアプリケーションではなく、PHPの実行環境そのものにある点です。まずは、PHP2Shellを構成する2つの脆弱性を確認しましょう。
1-1. CVE-2026-109618とCVE-2026-109619
- CVE-2026-109618： メモリ不足（OOM）時の処理不備に起因し、リモートコード実行につながる脆弱性。
- CVE-2026-109619： リクエスト処理に起因する脆弱性。前のリクエストで残ったグローバル状態が悪用される。
いずれもCVSS v4.0のスコアは9.2（緊急）です。IPA（情報処理推進機構）によると、悪用された場合、遠隔の第三者によって任意のコードを実行されるおそれがあります。
1-2. PHP2Shellが特に危険な理由
最大の問題は、アプリケーションのコードが動く前の段階で悪用できることです。攻撃者にはアカウントもパスワードも管理者権限も必要ありません。
そのため、WordPressやプラグイン、フレームワークを更新してもPHP2Shellは解消されません。根本的な対策は、PHP本体のアップデート（またはバックポートの適用）しかありません。
1-3. 公開から実際の攻撃までの経緯
| 日付（2026年） | 出来事 |
|---|---|
| 10月20日 | 修正版の公開前に脆弱性の情報が拡散 |
| 10月21日 | PHPが緊急修正版を公開：8.2.35／8.3.36／8.4.27／8.5.12 |
| 10月22日 | IPAが緊急の注意喚起を公開 |
| 10月23日 | 関連する脆弱性CVE-2026-115560が公表（5-3参照） |
| 10月24日 | 未修正のPHP 8.4.26で稼働するハニーポットに35件のWebシェルが設置されたと研究者が報告 |
現在も、PHP2Shellを狙ったスキャンや攻撃は広範囲で続いています。
2. PHP2Shellの影響を受けるPHPバージョンと環境
PHP2Shellの影響範囲は非常に広く、Wizの分析によれば、PHP 5.4以降のすべてのバージョンが、2件のうち少なくとも1件の影響を受けます。
| PHPバージョン | 修正状況 |
|---|---|
| 8.2〜8.5 | 公式修正版あり：8.2.35／8.3.36／8.4.27／8.5.12 |
| 7.4／8.0／8.1 | サポート終了（EOL）のため公式リリースなし。ソースコードのバックポートのみ |
| 7.3以前／5.x | 修正手段なし |
Webリクエストを処理するPHPの実行形態は、PHP-FPM、mod_php（Apache）、php-cgi、FrankenPHP、LiteSpeedのいずれも影響を受けます。
3. 自社システムがPHP2Shellの影響を受けるか確認する方法
各サーバーで実際に動いているPHPバージョンを正確に把握できていない企業は少なくありません。漏れがないよう、環境ごとに一つひとつ確認しましょう。
3-1. 稼働中のPHPバージョンを確認する
- サーバー上：php -vとphp-fpm -v（またはphp-fpm8.x -v）を実行する。
- ブラウザ：phpinfo()のページで確認する（確認後はファイルを必ず削除）。
- WordPress：管理画面の［ツール］›［サイトヘルス］でPHPバージョンを確認する。
注意： CLIのPHPと、PHP-FPM／ApacheのPHPはバージョンが異なる場合があります。Webリクエストを実際に処理しているPHPを確認してください。
3-2. コンテナ・ステージング・ホスティングも確認対象に
本番サーバーだけでなく、コンテナイメージ、ステージング／デモ環境、バックグラウンドワーカー、共用サーバー上のサイトも確認しましょう。放置されたデモサイトや過去のキャンペーンサイトは、真っ先に狙われやすい箇所です。
コンテナ環境では、パッケージを更新するだけでは不十分です。イメージを再ビルドして再デプロイして初めて修正が反映されます。
3-3. 外部スキャンツール利用時の注意点
PHP2Shellの無料チェックツールは数多く公開されています。ただし、PHPバージョンを非表示（expose_php = Off）にしていても安全とは限りません。ツールがバージョンを読み取れなくなるだけで、攻撃自体は成立してしまいます。スキャン結果は参考にとどめ、最終判断はサーバー上の実際のバージョンで行ってください。
4. 【HBLAB】PHP2Shell対応チェックリスト：フレームワーク・バージョン別の対処法
HBLABの基本方針は、「対処方法は稼働中のPHPバージョンで決まり、PHPを上げられるかどうかはフレームワークで決まる」というものです。以下の5ステップで、現状把握から根本解決までを進めます。
Step 1：実際に稼働しているPHPバージョンを特定する
3-1の方法（php -v、php-fpm -v、phpinfo、WordPressのサイトヘルス）で、システムごとに「アプリケーション・フレームワーク・バージョン・稼働中のPHP・公開（Public）か社内（Internal）か」の一覧を作成します。
一覧ができたら、次はシステムごとに対処方針を判定します。
Step 2：PHPバージョン別に対処方針を判定する
| 稼働中のPHP | 対処方針 | やるべきこと | 結果 |
|---|---|---|---|
| 8.2〜8.5 | パッチ適用 | 8.2.35／8.3.36／8.4.27／8.5.12または同等のディストリビューション提供パッケージへ更新し、PHP-FPM／Apacheを再起動、コンテナイメージを再ビルド | 解消 |
| 7.4／8.0／8.1 | バックポート | バックポート済みのディストリビューション提供パッケージやベンダーのLTS版を利用するか、ソースコードのバックポートを適用して自社でビルド。あわせて8.2以上への移行を計画 | 正しく適用すれば解消。ただしランタイムはサポート終了のまま |
| 7.3以前／5.x | 隔離＋移行 | 直ちに隔離し、修正版のあるPHPへ移行 | 移行完了で解消 |
| アプライアンス | ベンダー依存 | Web管理画面を隔離し、ベンダーのファームウェア更新を適用 | ベンダーの修正で解消 |
ただし、PHPを上げられるかどうかはフレームワーク次第です。Step 3の表で、フレームワークごとの具体的な作業を確認しましょう。
Step 3：フレームワーク別の対処表で「やるべきこと」を確認する
| フレームワーク | バージョン | 対応PHP（目安） | 対処方針 | 解消のためにやるべきこと |
|---|---|---|---|---|
| WordPress／WooCommerce | 6.x | 7.2〜8.x | パッチ適用またはバックポート | サーバー／ホスティング側でPHPを更新（WordPressやプラグインの更新では解消しない）。PHP 8.2以上との互換性をプラグインごとに確認 |
| WordPress | 4.x、旧5.x | 5.6〜7.x | 隔離＋移行 | PHP 7.3以前なら隔離。WordPress・テーマ・プラグインを更新した上でPHPを更新 |
| EC-CUBE ⚠️ | 4.3 | 8.1〜8.3 | パッチ適用またはバックポート | PHPを更新。8.1稼働なら8.2以上へ |
| EC-CUBE ⚠️ | 4.0〜4.2 | 7.x〜8.1 | バックポート | PHPにバックポートを適用し、EC-CUBE 4.3への更新を計画 |
| EC-CUBE ⚠️ | 2.x、3.x | 5.x〜7.x | 隔離＋移行 | 隔離した上で、EC-CUBE 4.3または他プラットフォームへ移行 |
| Laravel | 12、13 | 8.2〜8.5（12）／8.3〜8.5（13） | パッチ適用 | PHPを修正版へ更新、再起動、イメージ再ビルド |
| Laravel | 10、11 | 8.1〜8.3（10）／8.2〜8.4（11） | パッチ適用またはバックポート | PHPを更新。フレームワークのセキュリティサポートが終了しているため12または13へ |
| Laravel | 6〜9 | 7.2〜8.2 | バックポート | PHPにバックポート（PHP 7.3以前なら隔離）。段階的にLaravel 12／13へ |
| Laravel | 5.x | 5.6〜7.x | 隔離＋移行 | 隔離。段階的にLaravel 12／13へ更新、または再構築 |
| CakePHP | 4、5 | 7.4以上（4）／8.1以上（5） | パッチ適用またはバックポート | PHPを更新。CakePHP 5へ |
| CakePHP | 2、3 | 5.x〜7.4 | バックポート | 7.4稼働ならバックポート、それ以外は隔離。CakePHP 5へ移行 |
| CakePHP | 1.x | 4.x〜5.x | 隔離＋移行 | モダンなフレームワークで再構築 |
| Symfony | 6.4 LTS、7.x | 8.1以上（6.4）／8.2以上（7.x） | パッチ適用 | PHPを修正版へ更新 |
| Symfony | 4.4、5.4 | 7.1〜8.x | パッチ適用またはバックポート | PHPを更新。6.4／7.xへ |
| Symfony | 1.x〜3.x | 5.x〜7.x | 隔離＋移行 | 隔離。Symfony 6.4／7.xへ移行 |
| CodeIgniter | 4.x | 7.4以上（4.5以降は8.1以上） | パッチ適用またはバックポート | PHPを更新。CodeIgniter 4を最新に保つ |
| CodeIgniter | 3.1.13 | 最大8.1 | バックポート | PHP 8.1にバックポート。8.2以上へは保守フォークpocketarc/codeigniterを利用。長期的にはCodeIgniter 4またはLaravelへ |
| CodeIgniter | 2.x、旧3.x | 5.x〜7.x | 隔離＋移行 | 隔離。3.1.13を経由して更新、または再構築 |
| Yii | Yii2 | 7.x〜8.x | パッチ適用またはバックポート | PHPを更新。Yii2を最新に保つ |
| Yii | 1.1 | 主に5.x〜7.x | バックポート | 7.4以上ならバックポート、それ以外は隔離。Yii2またはLaravelへ移行 |
| Laminas／Mezzio | 現行版 | 8.x | パッチ適用 | PHPを修正版へ更新 |
| Zend Framework | ZF2、ZF3 | 5.5〜7.x | バックポート | 7.4稼働ならバックポート、それ以外は隔離。Laminasへ移行 |
| Zend Framework | ZF1 | 5.x | 隔離＋移行 | Laminas、Symfony、Laravelで再構築 |
| Magento／Adobe Commerce | 2.4.8、2.4.9 | 8.3〜8.4（2.4.8）／8.3〜8.5（2.4.9） | パッチ適用 | PHPを修正版へ更新 |
| Magento | 2.4.4〜2.4.7 | 8.1〜8.3 | パッチ適用またはバックポート | PHPを更新。2.4.8以上へ |
| Magento | 1.x | 5.x〜7.2 | 隔離＋移行 | Magento 2または他プラットフォームへ移行。OpenMageを中継として利用可能 |
| Drupal | 11／10 | 8.3以上／8.1以上 | パッチ適用（11）、パッチ適用またはバックポート（10） | PHPを更新。Drupal 10はDrupal 11へ |
| Drupal | 7、8、9 | 5.x〜8.1 | バックポート／稼働PHPに準ずる | サポート終了済み。可能ならPHPを更新・バックポートし、Drupal 11へ移行 |
| Joomla | 5／4 | 8.1以上／7.2〜8.x | パッチ適用、パッチ適用またはバックポート | PHPを更新。Joomla 5へ |
| Joomla | 3 | 5.3〜8.0 | バックポート | 7.4〜8.0ならバックポート、それ以外は隔離。Joomla 5へ移行 |
| Phalcon | 5.x／3.x、4.x | 8.0以上／7.x | パッチ適用、バックポート | PHPを更新し、Phalcon拡張を再ビルド。旧版はPhalcon 5へ |
| Slim、Lumen | 最新版 | 7.4〜8.x | パッチ適用またはバックポート | PHPを更新。公開APIを優先 |
| Kohana、FuelPHP、Silex | 全バージョン | 5.x〜7.x | 隔離＋移行 | 開発終了済み。LaravelまたはSymfonyへ移行 |
| phpMyAdmin | 5.2／4.x | 7.2〜8.x／5.x〜7.x | パッチ適用、隔離＋移行 | PHPを更新し、phpMyAdminをインターネットから外す |
| 素のPHP（フレームワークなし） | — | システムによる | Step 2の判定に従う | PHP 7.3以前なら、PHPCompatibilityで互換性を確認し、Rectorでコードを自動修正 |
PHP2Shell影響範囲診断
「自社のどのシステムが影響を受けているのか分からない」とお悩みの企業様へ。HBLABが稼働中のPHPシステムを棚卸しし、実際のPHPバージョンを特定した上で、システムごとに「パッチ適用／バックポート／隔離」を判定します。期間の目安は1〜3日です。
「隔離＋移行」に該当するシステムでは、移行までの間、攻撃される可能性をできる限り下げることが最優先です。
Step 4：パッチ適用できないシステムを隔離する
隔離は脆弱性を解消するものではなく、移行までの間の攻撃リスクを下げるための措置です。HBLABでは次の6項目を推奨しています。
- インターネットから切り離す： VPNまたはIP制限経由のアクセスのみに限定し、不要なシステムは停止する。
- リバースプロキシ／WAFの背後に置く： PHP2Shell向けルールを適用し、リクエストサイズを制限、アップロード不要なエンドポイントではmultipartを遮断する。
- ネットワークを分離する： サーバーからの外向き通信を遮断し、ペイロードの取得やリバースシェルを防ぐ。
- 権限を最小化する： DBアカウントを最小権限にし、不要なシークレットやAPIキーをサーバーから削除する。
- 監視する： アクセスログ、ファイル改ざん検知、Webユーザーが生成した不審なプロセスのアラートを設定する。
- 期限付きのリスク受容を記録する： 責任者と移行完了予定日を明確にする。
隔離はあくまで一時的な措置です。根本解決には、明確な移行ロードマップが欠かせません。
Step 5：移行（マイグレーション）ロードマップを策定する
- 棚卸し： アプリケーション、フレームワーク、バージョン、稼働PHP、公開／社内の区分を一覧化する。
- アプリケーションごとに方針を決める：
- 既存環境のままランタイムを更新：PHP 8.2以上で動くフレームワークなら、PHPの更新のみ。
- フレームワークを段階的に更新：例）Laravel 5 → 12、Magento 2.3 → 2.4.8。
- 保守フォークを中継に利用：CodeIgniter 3（pocketarc）、Magento 1（OpenMage）。
- リプラットフォームまたは再構築：Zend Framework 1、Kohana、Silex、CakePHP 1、フレームワークを使わない古いPHPアプリケーション。
- SaaSへの置き換え：大きなカスタマイズが不要なWebサイトや小規模EC。
- 互換性チェック： PHPCompatibility（PHP_CodeSniffer）で新しいPHPでの問題箇所を洗い出し、Rectorで自動修正する。
- 修正済みPHPでステージングを構築し、主要機能をテストした上で本番へ切り替え、コンテナイメージを再ビルドする。
- 旧システムを停止・削除し、棚卸し一覧を更新する。
大規模なレガシーシステムの場合は、レガシーシステム刷新の進め方やHBLABのマイグレーションサービスもあわせてご覧ください。
5. すぐにPHP2Shellのパッチを適用できない場合の暫定策
テスト期間の確保やサービス停止の調整が必要なため、すぐにはパッチを適用できないシステムも少なくありません。その間にリスクを下げる方法を紹介します。
5-1. WAF／仮想パッチとアクセス制限
WAFやCDNでPHP2Shell向けのルールを適用し、リクエストサイズの制限、アップロード不要なエンドポイントでのmultipart遮断、管理画面へのIP制限を行います。
IPAは、有効な暫定策がない場合には、修正完了まで外部からのアクセス遮断やサービスの一時停止も検討するよう呼びかけています。
5-2. session.upload_progressの設定変更だけでは不十分
暫定策としてsession.upload_progress.enabled = 0の設定を紹介する記事もあります。しかしGMO Flatt Securityの分析では、この設定変更だけではPHP2Shellへの十分な対策にならず、回避される可能性があると結論づけられています。根本対策は、あくまでPHP本体の更新です。
5-3. 関連する脆弱性CVE-2026-115560にも注意
10月23日、PHPはセッション処理に関する脆弱性CVE-2026-115560を新たに公表しました。10月21日の修正版では解消されず、次回の定期リリースで修正される予定です。
この脆弱性は特定のセッション設定を持つアプリケーションに限られ、10月26日時点で悪用は報告されていません。修正版が出るまでは、PHPが推奨するsession.upload_progress.enabled = 0を、PHP2Shellのパッチ適用とあわせて設定しておきましょう（パッチの代わりにはなりません）。
6. パッチ適用後に必ず行うべき侵害調査
PHP2Shellのパッチは、適用した時点以降の攻撃を防ぐものです。それ以前にすでに侵入されていたかどうかは分かりません。HBLABでは、2026年10月17日以降のログを調査することを推奨しています。
6-1. ログで確認すべき兆候
- メモリ上限エラーを伴う不審なmultipartアップロードリクエスト
- 短時間に連続するHTTP 500エラー
- レスポンス内の異常に大きなPHPSESSID Cookie
- PHP-FPMやWebサーバーユーザーから生成された不審な子プロセス
- Webサーバーからの不審な外向き通信
6-2. Webシェル・改ざんファイルの確認
現在のソースコードを、Gitや正常なバックアップと比較します。特にアップロード・キャッシュ・tmpディレクトリに新たに作られたPHPファイルや、10月17日以降に更新されたファイルに注意してください。
6-3. 認証情報（APIキー・DBパスワード）の更新
侵入の兆候がある場合は、サーバー上のシークレットはすべて漏えいしたものとみなし、DBパスワード、APIキー、トークン、決済・ERP連携キーを変更します。あわせて、アプリケーション用アカウントの権限も見直しましょう。
HBLABのPHP2Shell侵害調査サービス
「パッチは適用したものの、それ以前にマルウェアを仕込まれていないか不安」という企業様へ。HBLABが10月17日以降のログを分析し、Webシェル、不審なファイル・プロセス、外向き通信を調査した上で、影響度と対処方針をご報告します。期間の目安は3〜5日です。
7. PHP 8.1以前（EOL）のシステムはどうすべきか
PHP2Shellは、サポート終了のランタイムで動くシステムのリスクをあらためて浮き彫りにしました。重大な脆弱性が見つかっても公式の修正版は提供されず、取れる手段はバックポート、隔離、移行に限られます。
フレームワークやアプリケーションが古いPHPに縛られているなら、システムのモダナイゼーションを検討する好機です。HBLABは、AI Assessment Toolによる現状分析から、移行・テストまで一貫して支援します。詳しくはHBLABのモダナイゼーションサービスをご覧ください。
8. HBLABの業界別PHP2Shell対応ソリューション
業界によってPHPの使われ方は異なり、優先して対処すべきポイントも変わります。例えば、小売・ECでは決済ページ、製造業ではフレームワークを使わずに構築された社内システム、教育機関ではMoodleが優先対象になります。HBLABは業界ごとのPHP環境の特性に合わせた対応プランで、根本原因の解消から長期的な運用まで、3つのレイヤーでご支援します。
- 緊急対応（0〜7日）： 影響範囲診断、ランタイムのパッチ適用、侵害調査、システムの隔離
- 根本対策（1〜3か月）： フレームワークの更新、レガシーアプリケーションのモダナイゼーション
- 長期運用： コンテナ・CI/CDの標準化、継続的な脆弱性管理による再発防止
HBLABの脆弱性修正・保守サービス
PHP2Shellへの対応でお困りの際は、今すぐHBLABにご相談ください。迅速な対応をご支援するとともに、貴社の業界に合わせた脆弱性修正・保守サービスの各プランをご案内します。
9. PHP2Shellに関するよくある質問
WordPressサイトもPHP2Shellの影響を受けますか？
はい。サーバーのPHPが未修正であれば影響を受けます。WordPressやプラグインの更新では解消されないため、サーバー／ホスティング側でPHPを更新する必要があります。
レンタルサーバーを使っていれば対応は不要ですか？
確認が必要です。事業者側でPHPを更新しているケースもありますが、多くのレンタルサーバーではPHPバージョンを利用者がコントロールパネルで選択します。稼働中のバージョンと事業者からのお知らせを確認してください。
PHPバージョンを非表示にしていれば安全ですか？
いいえ。バージョンを隠してもスキャンツールが読み取れなくなるだけで、脆弱性そのものは残ります。
まとめ
PHP2ShellはPHP本体の脆弱性で、ログイン不要で遠隔から悪用でき、すでに実際の攻撃も確認されています。稼働中のPHPバージョンを特定し、パッチ適用またはバックポートを行い、修正できないシステムは隔離した上で、10月17日以降の侵害調査を実施しましょう。対応のどの段階でも、HBLABがPHP2Shellの根本解決までご支援します。
