緊急対応受付中
PHP脆弱性（PHP2Shell）緊急対策・診断
2026年10月21日、PHP本体に認証不要のリモートコード実行につながる重大な脆弱性（CVE-2026-109618、CVE-2026-109619）が公表されました。PHPで動いているWebサイトや業務システムをお持ちの方へ、確認すべきことと対策の進め方を整理しました。サポートが終了した古いバージョンをお使いの場合も、段階的な対応をご提案します。
01概要
概要：公表されている事実
以下は、PHP開発元や国内外の公的機関が公表している内容に限って整理したものです。
| 公表日と対象 | The PHP Groupは2026年10月21日、PHP本体の2件の脆弱性（CVE-2026-109618「RCE via OOM corruption」、CVE-2026-109619「RCE via stale global state」）に関するセキュリティアドバイザリと修正版を公開しました。出典：php.net セキュリティアドバイザリ |
|---|---|
| 通称 | この2件の組み合わせは「PHP2Shell（php2shell）」と呼ばれています。出典：IPA 重要なセキュリティ情報 |
| 深刻度 | いずれもCVSS v4.0で9.2（Critical）と評価されています。出典：php.net 事前告知、NVD CVE-2026-109618、NVD CVE-2026-109619 |
| 影響 | 悪用された場合、認証なしで、PHPの実行プロセスの権限で任意のコードを実行される可能性があります。PHP-FPM、Apache mod_php、php-cgiなど、Webリクエストを処理するPHP環境が対象です。確認済みの攻撃経路には、細工されたリクエスト（multipart形式のリクエスト処理など）が含まれますが、経路はそれだけに限られないとされています。出典：JPCERT/CC 注意喚起、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp |
| 修正版 | PHP 8.5.12、8.4.27、8.3.36、8.2.35。それぞれの系統で、これより前のバージョンが影響を受けます。出典：php.net、JPCERT/CC |
| 緩和策の 位置付け |
PHP開発元は設定による緩和策を示していますが、特定の攻撃経路を減らすものにとどまり、完全な対策は修正版への更新のみとしています。出典：php.net |
| サポート状況 | 公式にサポートされているのは8.2〜8.5系です。8.2系のセキュリティサポートは2026年12月31日で終了します。8.1以前は公式の更新版が提供されず、7.4・8.0・8.1向けには最小限のソースレベルの修正のみが公開されています。出典：php.net サポート中のバージョン、php.net サポート終了バージョン |
| より古い バージョン |
調査に関わったWiz社は、PHP 5.4以降のバージョンはいずれかの脆弱性の影響を受けるとしています。同社は、発見と検証にAIを活用したことも公表しています。出典：IPA、Wiz Research |
| 公的機関の 案内 |
国内ではJPCERT/CCとIPAが注意喚起を公開しています。米国CISAは、すぐに更新できないシステムや8.1以前のシステムについて、オフライン化の検討を推奨しています。出典：JPCERT/CC、IPA、CISA |
本ページの情報は2026年10月23日時点のものです。最新情報は公式情報をご確認ください。（php.net ／ JPCERT/CC ／ IPA）
02想定される影響
想定される影響
リモートコード実行の脆弱性が悪用された場合、一般的に次のような影響が考えられます。実際の影響は、システムの構成や保持しているデータによって異なります。
サーバーの不正操作（RCE）
外部から任意のプログラムを実行され、Webサイトの改ざんや不正なファイル（Webシェルなど）の設置につながるおそれがあります。
情報漏えい
サーバー上の設定情報、データベースへの接続情報、顧客情報などが読み取られる可能性があります。
ランサムウェア被害
侵入の足掛かりとして悪用され、データの暗号化や業務システムの利用停止につながる可能性があります。
他への攻撃の踏み台
乗っ取られたサーバーが、社内ネットワークや取引先、第三者への攻撃の中継点として使われるおそれがあります。
業務・サービスの停止
調査や復旧の間、Webサイトや業務システムを止めざるを得なくなる場合があります。
信用・コンプライアンスへの影響
個人情報が漏えいした場合、個人情報保護委員会への報告や本人への通知が必要になることがあり、取引先や顧客への説明も求められます。
03セルフチェック
今すぐ確認すべきこと
技術担当の方と一緒に、次の項目を確認してください。一つでも分からない項目があれば、早めの確認をおすすめします。
- 01PHPのバージョン確認：本番サーバーで動いているPHPのバージョンを確認する（例：
php -v、管理画面、ホスティング事業者の案内）。修正版（8.5.12／8.4.27／8.3.36／8.2.35）以上かどうかを確かめる。 - 02対象システムの棚卸し：コーポレートサイト、ECサイト、CMS、社内システム、導入しているパッケージ製品など、PHPが組み込まれているものも含めて洗い出す。
- 03公開範囲の把握：インターネットから直接アクセスできるシステムを特定し、優先度を付ける。
- 04最新パッチの適用：修正版、またはOS・ディストリビューションが提供する修正済みパッケージを、検証のうえで速やかに適用する。
- 05WAF・緩和策の確認：すぐに更新できない場合、WAFや公式アドバイザリに記載された設定変更でリスクを下げる（ただし完全な対策ではない）。
- 06ログ監視と侵害調査：不審なmultipart/form-data形式のリクエスト、メモリ上限関連のエラーやHTTP 500エラー、PHPのワーカープロセスの異常終了などがないか確認する。
- 07バックアップの確認：バックアップが取得されていること、侵害前の状態に復元できることを確認する。
- 08連絡体制の確認：開発会社・保守会社・ホスティング事業者の連絡先と、社内の判断者を確認しておく。
04サポート終了版
サポート終了（EOL）版をお使いの場合
PHP 8.1以前（8.0、7.x、5.xなど）のサポート終了版では、公式の修正版が提供されません。それでも、すぐに打てる手はあります。リスクを下げながら、無理のない順番で進めます。
-
緊急の緩和策
WAFによる仮想パッチ、公式アドバイザリに沿った設定変更、アクセス制限などで、まず攻撃を受けにくい状態にします。必要に応じて、外部公開の一時停止も選択肢として検討します。
-
段階的なバージョンアップ
影響調査とテストを行い、互換性を確認しながらサポート中のバージョンへ順を追って移行します。ディストリビューションやLTSベンダーの修正パッケージが使える場合は、それも組み合わせます。
-
必要に応じたモダナイゼーション
フレームワークやライブラリが古く、バージョンアップだけでは維持が難しい部分に限り、構成の見直しや作り直しを計画的に進めます。
一度に全面的に作り直す「ビッグバン型」の刷新は、原則としておすすめしていません。長期間かかるうえに、その間も古い環境のリスクが残り、切り替え時の不具合も大きくなりがちだからです。動いているシステムを守りながら、効果の大きいところから小さく確実に改善していきます。
06対応の流れ
緊急対応の流れ
-
お問い合わせ
フォームからご連絡ください。必須項目はメールアドレスのみです。
-
ヒアリング
システムの構成、PHPのバージョン、緊急度、業務への影響を確認します。
-
緊急診断
影響の有無、優先順位、侵害の痕跡を調べ、対応方針をご報告します。
-
対策の実施
修正版への更新、または緩和策を、業務への影響を抑えながら実施します。
-
確認と継続支援
対策後の動作と状態を確認し、必要に応じて段階的な移行や運用保守へ進みます。
07よくあるご質問
よくあるご質問
自社のサイトがPHPを使っているか分かりません。
WordPressなどのCMS、ECサイト、社内の業務システム、他社から導入したパッケージ製品の内部でPHPが使われていることがあります。サーバーやホスティング事業者の管理画面、開発会社・保守会社への確認で判明することが多いため、まずは対象システムの一覧をご用意ください。調査からお手伝いすることも可能です。
WordPressやフレームワークを最新版にすれば対策になりますか？
今回の脆弱性はPHP本体に存在するため、WordPressやフレームワーク、アプリケーションの更新だけでは解消されません。PHP本体を修正版（8.5.12、8.4.27、8.3.36、8.2.35）か、OSやディストリビューションが提供する修正済みパッケージへ更新する必要があります。
WAFを入れていれば安全ですか？
WAFや設定変更による緩和策は、更新までの間に特定の攻撃経路を減らす目的のもので、PHPの公式アドバイザリでも、完全な対策は更新のみとされています。WAFは時間を稼ぐための手段と位置付け、並行して更新の計画を進めることをおすすめします。
PHP 7.4や5.x など、サポートが終了した古いバージョンを使っています。どうすればよいですか？
PHP 8.1以前は公式の更新版が提供されません（7.4・8.0・8.1向けには最小限のソースレベルの修正が公開されています）。まず緩和策とアクセス制限でリスクを下げ、ディストリビューションやLTSベンダーの修正パッケージの有無を確認したうえで、サポート中のバージョンへ段階的に移行する計画を立てます。いきなり全面的に作り直すことは前提にしていません。
サービスを止めずに対応できますか？
構成によっては、検証環境での確認や切り替え手順を準備したうえで、停止時間を短く抑えた更新が可能です。一方で、IPAやCISAは、すぐに更新や有効な暫定対策ができない場合、外部からのアクセス遮断や一時停止も検討するよう案内しています。業務への影響を踏まえ、どの方法を取るかを一緒に判断します。
すでに攻撃を受けていないか確認できますか？
JPCERT/CCが示している観点（不審なmultipart/form-data形式のリクエスト、その前後のメモリ上限関連エラーやHTTP 500エラー、異常なPHPSESSID Cookie、PHPのワーカープロセスの異常終了など）を中心に、ログやサーバーの状態を調査します。ただし、痕跡が残らない場合もあるため、痕跡がないことは攻撃を受けていないことの証明にはなりません。
相談するにはどうすればよいですか？
お問い合わせフォームから、メールアドレスだけでご相談いただけます。分かる範囲で、PHPのバージョン、サーバーの種類、システムの用途、緊急度をお知らせいただくと、より早くご案内できます。