【緊急】古いPHPに致命的な脆弱性。今すぐPHP 8へ移行を

2026-10-21

PHP本体に、リモートコード実行につながる重大な脆弱性が2件あると警告されました。サポートが終了したバージョンには、公式の修正パッチが提供されない見込みです。

何が起きているのか

2026年10月20日、PHPのセキュリティチームは緊急セキュリティリリースの事前告知を行いました。対象は2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）で、いずれもCVSS v4.0で9.2と評価されています。
修正版は2026年10月21日 14:00 UTC（日本時間 23:00）にリリースされる予定です。watchTowrなどのセキュリティ企業によると、いずれもリモートコード実行の脆弱性であり、認証なしでサーバーを操作される恐れがあります。
情報は公表前に漏えいし、「PHP2Shell」と呼ばれる攻撃ツールが出回っているとも伝えられています。Sansecは、修正版の公開から数分で大規模な攻撃が始まる可能性があると予測しています。

「問題はWebサイトのコードではなく、PHP自体にあります。根本的な対策は、PHPのバージョンを更新することだけです。」

古いバージョンほどリスクが高い理由

PHPがセキュリティサポートを提供しているのは8.2以上のみです。PHP 5、7、8.0、8.1はすでにサポートが終了しています。漏えいした情報では、PHP 5.4以降が影響を受ける可能性があるとされていますが、PHPによる正式な確認はまだありません。

実際には、サポート終了バージョンで稼働しているサイトは、この2件の脆弱性について公式の修正が提供されない可能性が高いということです。今後見つかる脆弱性も同様です。

特に、Magento、Shopware、WooCommerce、WordPressなどを使うECサイトやCMSサイトは、自動化された攻撃の標的になりやすく、注意が必要です。

ひと目でわかるポイント

脆弱性ID	CVE-2026-109618、CVE-2026-109619
深刻度	重大（CVSS v4.0：9.2）
種類	PHP本体のリモートコード実行
修正版	2026年10月21日 14:00 UTC（日本時間 23:00）予定
サポート対象のPHP	8.2以上
サポート終了のPHP	8.1以前（5.x、7.xを含む）

本稿執筆時点のPHP公式告知および各セキュリティ企業の情報に基づきます。影響を受けるバージョンの正式な範囲は、修正版と同時にPHPから公表されます。

PHP 8へ移行するメリット

脆弱性の修正は、移行の利点の一部にすぎません。現行のPHP 8系へ移行すると、次のような効果が期待できます。

安全性：今後見つかる脆弱性にも、公式のセキュリティパッチが引き続き提供されます。
パフォーマンス：PHP 8にはJITコンパイラなどの改善があり、PHP 7や5に比べて同じサーバー構成でも表示が速くなる傾向があります。ただし効果の大きさはサイトごとに異なります。
互換性：新しいプラグイン、テーマ、ライブラリは、PHP 8以上を要件とすることが増えています。古いままでは、これらの更新が受けられません。
長期的なコスト：計画的な段階移行は、インシデント後の緊急対応やサイト復旧に比べて、はるかに低コストです。

技術解説：この2件の脆弱性が深刻な理由

下の表では、確認済みの事実と、報告にとどまる情報を分けています。噂ではなく、事実に基づいてリスクを判断していただくためです。

悪用された場合、何が起こるのか

RCEの脆弱性では、攻撃者がPHPプロセスの権限で任意のコードを実行できます。商用Webサイトでは、この権限で通常次のようなことが可能です。

データベース接続情報やAPIキーが含まれることの多い、アプリケーションの設定ファイルを読み取る。
サイトのディレクトリにファイルを書き込む。たとえばWebシェルを設置し、いつでも再侵入できる状態にする。
顧客データや注文情報にアクセスしたり、ログインや決済ページに不正なコードを挿入したりする。
サーバーを足がかりに、同じネットワーク内の他のシステムを攻撃する。

これはRCE一般に見られる典型的な影響です。特定の攻撃事例の調査結果ではありません。

まだわかっていないこと

PHPは根本原因を公表していません。第三者による未検証の分析では、ext/session内のphp_session_rfc1867_callback()に関わるuse-after-freeで、multipart/form-dataリクエストのアップロード進捗の処理部分にあるとされています。また、この機能は初期設定で有効であり、リクエストはアプリケーションが起動する前に処理されるとも指摘されています。

一方で、この具体的な不具合は公開済みのPHPには存在しないとする別の評価もあります。そのため、これは仮説として扱っています。すべての構成で悪用できるとも断言しません。

実務上の結論：疑わしい機能を1つ無効にしただけで、安全になったとは考えないでください。専門家は、その対策が両脆弱性のすべての攻撃経路を塞ぐことは証明されていないとしています。確実な答えは公式の修正版だけです。

なぜ今日中に動くべきか

猶予はごくわずか。Sansecは、修正版の公開から約15分で大規模な攻撃が始まる可能性があると予測しています。これは予測であり、実測値ではありません。修正のソースコードが公開されると、攻撃者は差分を比較して脆弱性を把握することがよくあります。
狙い撃ちである必要がない。認証不要と説明されているため、自動スキャンのボットが、相手が誰かを知らなくても大量のサイトを試せます。
対処できるのはランタイム層のみ。プラグインやComposerの更新では、PHP本体の欠陥は直りません。PHPを更新し、サービスを再起動する必要があります。
古いバージョンには逃げ道がない。PHP 8.1以前は、公式の修正が提供されない可能性が高いです。移行しなければ、脆弱性は開いたままになります。

監視すべき兆候

公式の侵害指標はまだありません。専門家は、最も可能性が高い兆候として、PHPプロセスが不審な子プロセスを起動することを挙げています。シェルやcurl、wgetなどの起動、Webディレクトリ内の見慣れないPHPファイル、未知の宛先への外部接続です。これは予測であり、観測された兆候ではありません。公式の指標が出次第、更新します。

PHPのバージョン別・対応方針

対応方法は、サイトが稼働しているPHPのバージョンによって変わります。該当するグループをご覧ください。

PHP 8.2 / 8.3 / 8.4 / 8.5 ・サポート対象: 修正版が出たら直ちに更新

修正版の予定：8.5.12、8.4.27、8.3.36、8.2.35。PHPによる確認前の情報ですので、公式告知と照合してください。
パッケージの更新、またはコンテナイメージの再ビルドを行い、PHP-FPMまたはWebサーバーを再起動します。
コマンドラインのphp -vだけでなく、実際にサイトを配信しているプロセスでバージョンを確認します。
外部公開サイトとECサイトを最優先にします。

PHP 8.0 / 8.1 ・サポート終了: 8.3または8.4へ早めに移行

公式の修正が提供されない可能性が高いです。同じ系統内のマイナー更新だけでは不十分です。
長期サポートの続くバージョンへ一気に移行します。コードの変更量は通常、中程度です。
間に合わない場合は、OSベンダーやホスティング事業者にバックポートの有無を確認し、下記の暫定策を適用します。

PHP 7.x / 5.x ・以前にサポート終了: 早急に計画を立て、移行へ

公式の修正はありません。今回の脆弱性も、今後見つかるものも、開いたままになります。
バージョン差が大きく、コード修正やプラグイン、テーマの入れ替えが必要になることが多いため、事前の調査と評価が欠かせません。今日から着手してください。
移行までの間は、下記の暫定策でシステムを隔離します。

修正できるまでの暫定策

これらはリスクを下げるだけで、更新や移行の代わりにはなりません。

VPNやIP許可リストでアクセスを制限する。または、設定を強化したリバースプロキシの背後に置く。
使っていないPHPのエンドポイントやサービスを停止する。
完全なバックアップを取り、ログ出力を増やし、PHPプロセスによるシェル起動や不審な外部接続を監視する。
重要度が低く、保護が難しいシステムは、一時停止も検討する。
[未確認] session.upload_progress.enabledを無効にし、アップロード不要なルートでmultipart/form-dataを遮断する。疑われる攻撃経路を1つ減らせる可能性があるとして、一部の専門家が提案しています。ただし、両脆弱性のすべての経路を塞ぐ証拠はありません。

推奨スケジュール

本日: PHPバージョンの棚卸し、更新コマンドの事前準備。サポート終了版には暫定策を適用。修正版が出たら直ちに適用し、外部公開サイトを優先。
24時間以内: PHP 8系の全システムで適用と再起動を確認。ログとサイト内の不審なファイルを点検。
7日以内: サポート終了のPHPで稼働するシステムの調査を終え、移行計画を確定。
30日以内: PHP 8.3または8.4へ移行し、テストを実施。

技術解説：なぜ「ファイアウォールで防ぐ」だけでは不十分なのか

Sansecによると、この攻撃はアプリケーションのコードが実行される前にPHPを狙います。そのため、セキュリティプラグインやサイト内のルールといったアプリケーション層の防御は、間に合わない可能性があります。前段のWAFでリスクを一部下げられる場合もありますが、仕組みが公開されていない段階では、汎用的な異常リクエスト検知ルールの効果は限定的だと、複数のセキュリティ情報源が指摘しています。

脆弱性はランタイムにあるため、確実な対策は修正済みのPHPへ更新し、PHP-FPMまたはWebサーバーを再起動することです。パッケージを入れ替えただけで再起動しなければ、古いプロセスは脆弱なまま動き続けます。