PHP2Shell脆弱性レポート：影響範囲と対策

結論: PHP2Shell は、PHP エンジン本体に見つかった 2 件の重大な脆弱性（CVE-2026-109618 と CVE-2026-109619）の通称で、2026年10月21日の緊急リリースで修正されました。PHP の Web サーバーに到達できる未認証の攻撃者が、サーバー上でコードを実行できる可能性があります。PHP 8.5.12、8.4.27、8.3.36、8.2.35 のいずれかへ更新し、すべての PHP ワーカーを再起動したうえで、把握していない PHP を洗い出してください。

何が起きたのか：概要

2026年10月21日、PHP プロジェクトは 8.5.12、8.4.27、8.3.36、8.2.35 の 4 つのセキュリティリリースを同時に公開しました。インタープリタのリクエスト処理の中核にあった、2 件のリモートコード実行（RCE）の脆弱性を修正するものです。この 2 件は PHP2Shell と呼ばれるようになりました。PHP プロジェクトは、いずれも CVSS v4.0 で 9.2（Critical） と評価しています。同プロジェクトのアドバイザリは、PHP が PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed のどの形態で動いていても、「Web リクエストを処理するすべての PHP 環境」にリスクがあるとしています。詳細は開示予定日の前日に流出したため、パッチ適用までの猶予は通常よりはるかに短くなりました。数時間のうちに複数のセキュリティ企業が悪用の試みを報告し、10月22日から23日にかけては、米国の CISA、英国の NCSC、シンガポールのサイバーセキュリティ庁（CSA）、香港の HKCERT がそろって注意喚起を出しています。

本レポートでは、現時点で分かっていること、まだ不確かなこと、そして香港、中国本土、シンガポールに拠点を持つ企業の IT・セキュリティ責任者が今後 24 時間、72 時間、7 日間で行うべきことを整理しています。エンジニアだけでなく、判断と指示を行う立場の方に向けて書いています。

CVE-2026-109618 と CVE-2026-109619 とは何か

2 件の脆弱性はいずれも PHP 本体にあり、WordPress、Drupal、Laravel、Magento やプラグインよりも下の層に存在します。そのため、アプリケーションを最新にしていても防御にはなりません。有効なのは、PHP ランタイム自体の更新だけです。

CVE-2026-109618：メモリ不足による破損を突いたリモートコード実行

PHP のアドバイザリ（GitHub advisory GHSA-w8hw-w9fx-j79w）によると、メモリ不足（OOM）の処理によって、リクエストの内部データが中途半端に初期化された状態で PHP が中断されることがあります。その後のクリーンアップ処理が、この未完成のデータを正常なものとして扱ってしまいます。攻撃者が絶妙なタイミングで PHP ワーカーをメモリ不足に追い込めれば、この混乱を足がかりにプロセスを乗っ取れます。Google の対応ガイダンスは、サイズの大きいリクエストペイロードがメモリ不足を引き起こすために使われ得ると述べています。

CVE-2026-109619：残存したグローバル状態によるリモートコード実行

2 件目のアドバイザリ（GHSA-6wmf-4rv5-p3rp）は、リクエストが所有する内部状態が、メモリ解放後も残り続ける問題を説明しています。同じ PHP ワーカーが次に処理するリクエストが、通常の起動時初期化が行われる前にこの古い状態を使ってしまう可能性があります。シンガポールの CSA はこれを use-after-free の脆弱性に分類しています。PHP ワーカーは長時間稼働して多数のリクエストを処理するため、ある訪問者のリクエストが、同じワーカー上の次のリクエストに影響を及ぼし得ます。

最もリスクが高いのはどの構成か

PHP プロジェクトは、Apache と mod_php の組み合わせが最もリスクが高いとしています。この構成では、未認証のリクエストが アプリケーションコードの実行前に 攻撃を成立させる実証済みのエクスプロイトが存在します。この点は重要です。攻撃はあらゆる処理より前に到達するため、ログインページ、アプリケーション内蔵のファイアウォール、堅牢化した CMS 設定は役に立ちません。トロント大学のアドバイザリは、PHP-FPM 経由での CVE-2026-109619 の悪用には、適切なアプリケーション操作が必要だと補足しています。難易度は上がりますが、安全になるわけではありません。

実際の深刻度はどの程度か

PHP プロジェクト: 2 件とも CVSS v4.0 で 9.2（Critical）。
一部の公開脆弱性データベース: CVSS v3.x のスコアは、CVE-2026-109618 が 9.8、CVE-2026-109619 が 8.1。
watchTowr: PHP の普及度と、攻撃者に求められる条件の少なさを踏まえ、10.0 相当と見ています。

スコアには差がありますが、結論は変わりません。インターネットに公開された Web サーバーにおける未認証のリモートコード実行は、他の作業を止めてでも対応すべき事案です。

発見から実際の悪用までのタイムライン

報道内容はまだ訂正が続いています。以下のタイムラインは、一次情報または信頼できる報道の少なくとも 1 件で確認できた日付のみを使っています。時刻はすべて UTC です。

2026年8月: 研究者が独立にこの脆弱性を発見しました。報道では、Calif と Wiz のチームが、いずれも AI を活用した解析で発見したとされています。根本原因のひとつであるメモリ不足の問題は、2024 年の監査で気づかれていたものの、修正されないままだったと伝えられています。
2026年10月17日: Amazon Threat Intelligence が後日、この日付のハニーポットのテレメトリに悪用の試みがあったと報告しました。公開の 4 日前にあたります。
2026年10月20日: 10月22日に予定されていた開示に先立ち、Hacker News で詳細が流出しました。PHP プロジェクトは、10月21日 14:00 UTC の緊急リリースを発表しました。
2026年10月21日 13:34 UTC: 予定されたリリースの直前に、2 件の GitHub セキュリティアドバイザリが公開されました。
2026年10月21日: PHP 8.5.12、8.4.27、8.3.36、8.2.35 がリリースされ、8.1、8.0、7.4 には最小限のソースバックポートが提供されました。シンガポール CSA と米国 CISA が注意喚起を発表しました。watchTowr は自社のハニーポットネットワークで悪用の試みを確認したと報告し、Cloudflare も初期の試みを確認して一時的な WAF ルールを展開しました。
2026年10月22日: HKCERT が、香港の企業に PHP システムの確認とパッチ適用を促す警告を発表しました。CSA は注意喚起を更新し、Google Cloud は WAF と検知に関するガイダンスを更新しました。この日の時点では、どちらの CVE も CISA の Known Exploited Vulnerabilities（既知の悪用された脆弱性）カタログには追加されていませんでした。
2026年10月23日: HKCERT は 10月22日に初版を出したセキュリティ情報を更新し、この問題を 「極めて高いリスク（Extremely High Risk）」 と評価し、脆弱性が実際に悪用されていると明記しました。

教訓は明快です。開示から攻撃までの間隔は、いまや週単位ではなく時間単位で測られます。HKCERT も同じ点を指摘しており、AI ツールが開示、スキャン、悪用の試みまでの時間を短縮していると述べています。

影響を受ける PHP バージョンと、修正済みバージョンは？

メンテナンス中のすべてのブランチは、更新されるまで影響を受けます。それ以前の古いブランチのほとんども同様です。

PHP 8.5: 8.5.12 より前が影響を受けます。8.5.12 で修正。
PHP 8.4: 8.4.27 より前が影響を受けます。8.4.27 で修正。
PHP 8.3: 8.3.36 より前が影響を受けます。8.3.36 で修正。
PHP 8.2: 8.2.35 より前が影響を受けます。8.2.35 で修正。なお PHP 8.2 は 2026年12月31日にサポート終了となります。
PHP 8.1、8.0、7.4: 影響を受けます。いずれもサポート終了で、公式のバイナリリリースはありません。PHP プロジェクトは最小限のソースバックポートを公開しており、一部の Linux ディストリビューションや長期サポート（LTS）ベンダーはパッチ適用済みのパッケージを提供しています。
PHP 7.3 以前（PHP 5.x を含む）: 影響を受け、修正もありません。安全な道は、サポート中のブランチへアップグレードするか、システムをインターネットから切り離すかのどちらかです。

現場がつまずきやすい点が 2 つあります。

ベンダーのバックポートは旧バージョン番号のままです。 パッチ適用済みのディストリビューションやコントロールパネルのビルドでは、`php -v` が古いバージョンを表示することがあります。修正済みかどうかは、ベンダーの変更履歴やアドバイザリに 2 件の CVE ID が両方記載されているかで確認してください。
すべてのリポジトリが初日に更新されたわけではありません。 PHP プロジェクトは、サードパーティの rpms.remirepo.net リポジトリは公開初日に更新が提供されないため、利用者はディストリビューション公式パッケージに切り替えるか、ソースからビルドするよう明記して案内しています。

香港・中国・シンガポールの企業にとって、なぜ重要なのか

PHP は Web の非常に大きな割合を支えています。HKCERT は、Web サイトの 75% 超が PHP を使っているとする報告と、インターネットに接続された PHP ホストが約 510 万台という推計を引用しています。それでも、アジアの多くの企業にとって大きなリスクは、メインの Web サイトではありません。把握していない PHP です。

資産台帳に載らない場所に PHP が潜んでいる

HKCERT は、PHP がアプリケーション、ネットワーク機器やセキュリティ機器、ストレージ、監視システムの 管理画面や運用に関わる部分 に組み込まれている可能性があると警告しています。こうした組み込みの PHP は OS とは別のバージョンで動いていることが多く、通常の棚卸しでは見落とされます。確認すべき代表的な場所は次のとおりです。

Web ホスティングのコントロールパネル。 cPanel、Plesk、HestiaCP、VestaCP などは、独自の PHP ビルドを同梱しています。
レガシーなイントラネットや、人事・予約・チケット管理ツール。 何年も前に現地の制作会社が作ったまま、PHP 7 から上げていないものです。
PHP ベースの Web コンソールを持つ、ネットワーク、ファイアウォール、VPN、NAS、監視の各機器。
WordPress、WooCommerce、Magento、OpenCart で作られたマーケティングサイトや EC サイト。 第三者がホスティングしていることも少なくありません。
PHP を同梱したコンテナやイメージ。 再ビルドの頻度が低いものです。

規制当局や保険会社から確認される

規制対象の企業にとって、これは証跡の問題でもあります。シンガポール CSA は、PHP が動くすべてのシステムの監査、インターネットに公開されたサーバーの優先対応、間接的に同梱されたコンポーネントの確認を各組織に求めています。HKMA や SFC の監督下にある香港の企業、そして中国の等級保護制度（MLPS）の義務を負う中国本土の拠点は、監査人、顧客、サイバー保険会社から、次の単純な問いを受けると考えておくべきです。いつ知り、何にパッチを当て、どう証明できるのか。 日付入りのパッチ記録、スキャン結果、保全されたログがあれば答えられます。「大丈夫だと思います」では答えになりません。

今、何をすべきか：24 時間、72 時間、7 日間の計画

以下の手順は、PHP プロジェクトのアドバイザリと、HKCERT、CSA、CISA のガイダンスに沿っています。選択肢ではなく、順序立てた手順として扱ってください。

24 時間以内：洗い出し、パッチ適用、再起動

自社が所有・ホスティングするすべての PHP ランタイムを棚卸しする。 インターネットに公開されたサーバーから着手します。コントロールパネル、機器、コンテナ、第三者がホスティングするサイトも含めてください。ホスティング事業者やソフトウェアベンダーには、パッチの適用状況を書面で確認します。
修正済みリリースへ更新する。 PHP 8.5.12、8.4.27、8.3.36、8.2.35 を導入するか、ディストリビューションやコントロールパネルのベンダーが出したパッチ適用済みパッケージを使います。Ubuntu や SUSE などはすでに更新を公開しています。
すべての PHP ワーカーを再起動する。 古いワーカーが残っている間は、修正は有効になりません。PHP-FPM のプール、mod_php の Apache、長時間動いている PHP プロセスをすべて再起動してください。コンテナは再ビルドして再デプロイします。ベースイメージを更新しても、稼働中のコンテナには何の効果もありません。
mod_php を最優先で対応する。 Apache と mod_php の組み合わせが最もリスクが高いため、これらのサーバーを作業の先頭に置きます。
ベンダーのバックポートを使っている場合は、バージョン文字列ではなく CVE ID で修正を確認する。

今日パッチを当てられない場合：露出を減らす

PHP プロジェクトは、設定変更でこれらの脆弱性を完全に緩和することはできないと明言しています。一時的な対策は、特定の攻撃経路を狭めるだけです。数時間以内に更新できないシステムでは、次の対策をできるだけ多く適用しつつ、更新の計画も並行して進めてください。

インターネットから切り離すか、隔離する。 HKCERT と watchTowr は、すぐにパッチを当てられない PHP システムへの公開アクセスを制限または撤去することを推奨しています。リスクを「減らす」のではなく「取り除く」ことができる、唯一の暫定措置です。
CVE-2026-109619 の場合： `php.ini`、FPM プール、またはサーバー設定で `session.upload_progress.enabled=0` を設定し、すべてのワーカーを再起動します。`ini_set()` や `.user.ini` には頼らないでください。PHP 8.5 では、あわせて `fatal_error_backtraces=0` を設定します。
CVE-2026-109618 の場合： Web サーバーやプロキシで、ボディサイズ、フィールド数、マルチパートの部品数、ヘッダー数、ネストの深さなど、リクエストのサイズを制限します。`post_max_size` は低く保ちます（アドバイザリの目安は、アップロードなしで 8M、ありで 32M）。コンテナや cgroup のメモリ制限で、影響を受けたワーカーだけが強制終了されるように封じ込めます。アドバイザリには `memory_limit=-1` に設定する方法も記載されていますが、これだけでは安全にならないと注意書きがあります。
利用できる環境では、マネージド WAF ルールを有効にする。 Cloudflare は一時的なルールを展開しました。Google Cloud は、Cloud Armor のマネージドルールとリクエストボディの検査上限の設定を推奨しています。これはシートベルトであって、修正ではありません。たとえば CloudLinux は、同社のファイアウォールルールでは 2 つの攻撃経路のうち 1 つをまだ防げないと述べています。

72 時間以内：すでに侵害されていないか確認する

悪用の試みは 10月21日から報告されており、Amazon は早くも 10月17日の試みを報告しています。パッチ適用は入り口を閉じますが、先に侵入されたかどうかは教えてくれません。

ローテーションされる前にログを保全する。 Web サーバー、PHP-FPM、WAF、ファイアウォールのログを、少なくとも 10 月中旬以降の分について保管してください。CSA は、10 月中旬まで遡ったログの確認を特に推奨しています。
不審なリクエストやプロセスの挙動を探す。 過大または不正な形式のリクエスト、メモリ不足エラーやワーカークラッシュの急増、PHP や Web サーバーのプロセスがシェルや想定外の子プロセスを起動していないかを確認します。
永続化の痕跡を確認する。 Web ルートやアップロード用フォルダにある新規・変更された PHP ファイル、見覚えのない cron ジョブ、新しいローカルアカウント、想定外の外向き通信を調べます。英国 NCSC は、バックドアに注意するよう特に呼びかけています。
異常があればエスカレーションする。 侵害の兆候が見つかったら、ホストを隔離し、証拠を保全して、インシデント対応チームを動かします。稼働中のサーバーを掃除するより、信頼できるイメージから再構築するほうが安全です。

7 日間以内：構造的な弱点を塞ぐ

PHP 8.1 以前を廃止する。 バックポートは時間を稼ぐだけで、サポート終了のブランチを長期的に安全にするものではありません。PHP 8.2 も 2026年12月31日にサポート終了となるため、移行を計画してください。
棚卸しの抜けを埋める。 今回の件で把握していなかった PHP が見つかったなら、資産台帳は不完全です。組み込み型システムやベンダー管理のシステムを台帳に加えてください。
パッチ適用に時間の物差しを持たせる。 インターネットに公開された重大な修正について、次回のメンテナンス枠ではなく時間単位の目標を文書で定め、それに対する実績を報告します。
対応を記録する。 棚卸し、パッチ適用時刻、検証、ログ確認を日付入りで記録してください。取締役会、規制当局、顧客、保険会社が求める証跡になります。

パッチ、バックポート、緩和策、隔離：どれを選ぶべきか

多くの環境では、これらを複数同時に使うことになります。比較は次のとおりです。

4 つの対応方法の比較

公式アップデート（8.5.12、8.4.27、8.3.36、8.2.35）。 2 件の脆弱性をどちらも塞ぎます。再起動と、アプリケーションの簡単な動作確認が必要です。完全な修正はこれだけで、サポート対象のすべてのシステムの基本方針になります。
ベンダーやディストリビューションのバックポート。 メジャーアップグレードなしで、古いブランチの 2 件を塞ぎます。ベンダー次第であり、バージョン番号が変わらないことがあるため、CVE ID で確認してください。PHP 8.1、8.0、7.4 のつなぎとしては妥当ですが、行き先にはなりません。
設定による緩和策と WAF ルール。 数分で特定の攻撃経路を狭められます。PHP プロジェクト自身が述べているとおり不完全で、正当なアップロードや進捗バーを壊す場合もあります。更新の準備中にのみ使ってください。
隔離または一時停止。 インターネットへの露出を完全に取り除きますが、可用性を犠牲にします。PHP 7.3 以前、パッチを当てられない機器、1 日以内に更新できないあらゆるシステムでは、これが正しい判断です。欧州やカナダのいくつかの公的機関は、最初の 48 時間でこの道を選びました。

より大きな教訓：AI がパッチ適用の猶予を縮めた

PHP2Shell が通常の重大なバグと違う点は 2 つあります。ひとつは、脆弱性が AI を活用したツールで発見されたことで、攻撃者も同じツールを持っているという点です。もうひとつは、情報の流出とパッチ適用済みビルドの早期公開により、攻撃者が数時間のうちに新旧のコードを比較できたという点です。HKCERT 自身の見出しも、AI が攻撃と防御の両方を加速し、対応の猶予を縮めていると明言しています。

中堅企業にとっての実務的な帰結は、「パッチは毎月第 2 火曜日に当てる」という運用が、インターネットに公開されたシステムのセキュリティポリシーとしてはもう成り立たない、ということです。守りになるのは、曜日を問わず機能する短い鎖です。

自社が何を動かしているかを知る。 組み込み型や第三者ホスティングのソフトウェアも含めた、最新の棚卸し。
何が公開されているかを見る。 定期的な外部脆弱性スキャンにより、攻撃者より先に重大な指摘事項を見つけます。
時間を決めてパッチを当てる。 責任者を明確にし、重大な修正に文書化した時間目標を置き、再起動と検証の手順まで含めます。
試みを見逃さない。 悪用の試みを示せるログ保管と監視を整え、身代金要求のメッセージで初めて気づくことのないようにします。

ブロセントが支援できること

ブロセント（Brocent）は、香港、中国本土、シンガポール、そしてアジア太平洋地域全体の企業に、マネージドITサポートとサイバーセキュリティサービスを提供しています。PHP2Shell のような事案では、次のサービスが関係します。

露出の確認。 インターネットに公開された PHP やその他の重大な露出を見つけるための外部脆弱性スキャン、またはより広範な ITセキュリティアセスメント。
時間を決めたパッチ適用。 パッチ適用状況のレポート付きで運用する、マネージドの脆弱性スキャンとパッチ管理。このサービス単体をご希望の場合は、パッチ管理の料金をご覧ください。
棚卸しと堅牢化。 組み込み型システム、コントロールパネル、レガシーアプリケーションをひとつの台帳にまとめ、サポート終了の PHP からの移行を計画する ITアセスメントと監査。
境界の防御。 システムの更新が済むまでの補完的な対策としての、ファイアウォールや WAF ルールなどのネットワークセキュリティオプション。

ご自身の環境のシステムが影響を受けるかどうか判断がつかない場合は、ブロセントにお問い合わせください。上記のチェックリストを一緒に進めます。

よくある質問

PHP2Shell とは何ですか？

PHP2Shell は、2026年10月21日に開示・修正された、PHP インタープリタの 2 件の重大な脆弱性 CVE-2026-109618 と CVE-2026-109619 の通称です。PHP を動かして Web リクエストを処理しているサーバーで、未認証の攻撃者がコードを実行できる可能性があります。

WordPress、Drupal、プラグインを更新すれば直りますか？

直りません。脆弱性はアプリケーションより下の層、PHP エンジン自体にあります。塞げるのは、更新された PHP ランタイムか、修正をバックポートしたベンダーのパッケージだけです。CMS やプラグインの更新も引き続き必要ですが、別の作業として扱ってください。

PHP2Shell が修正されている PHP のバージョンはどれですか？

PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。PHP 8.1、8.0、7.4 については、2 件の CVE ID が両方記載されているディストリビューションまたは長期サポートベンダーのパッケージを使ってください。PHP 7.3 以前には修正がないため、アップグレードするか隔離する必要があります。

PHP2Shell は実際に悪用されていますか？

複数の情報源によれば、悪用されています。watchTowr と Cloudflare は 2026年10月21日から悪用の試みを報告し、Amazon は 10月17日付の試みを報告しており、HKCERT が 10月23日に更新したセキュリティ情報は、脆弱性が実際に悪用されていると明記しています。10月22日の時点では、CISA はどちらの CVE も Known Exploited Vulnerabilities カタログに追加していなかったため、状況は今も動いています。

今日パッチを当てられない場合の回避策はありますか？

部分的なものだけです。PHP プロジェクトは、設定変更でこれらの脆弱性を完全に緩和することはできないとしています。`session.upload_progress` の無効化、リクエストサイズ制限の強化、WAF ルールの有効化で、特定の攻撃経路は減らせます。露出そのものを取り除ける暫定措置は、システムをインターネットから切り離すことだけです。

サーバーがパッチ適用済みかどうか、どう確認すればよいですか？

`php -v` を実行し、修正済みバージョンと比べます。ディストリビューション、コントロールパネル、ベンダー製ビルドを使っている場合は、バックポートでバージョン番号が変わらないことが多いため、変更履歴やアドバイザリに 2 件の CVE ID が記載されているかを確認してください。そのうえで、更新後にすべての PHP ワーカーが再起動されていることを確かめます。