STOP Inc.
サーバ監視運用事業

【緊急】PHP本体に認証不要のRCE脆弱性2件、修正前に情報流出。php2shellの概要と対応指針

#PHP #Wordpress #サーバ監視 #セキュリティ #受託開発 #脆弱性対策

2026年10月20日（協定世界時、以下UTC）、PHP本体に2件の重大な脆弱性があるという情報が、本来の公開予定日より前にインターネット上へ流出しました。CVE番号はCVE-2026-109618とCVE-2026-109619。研究者のあいだでは、攻撃者がサーバー上でシェル（コマンド実行環境）を握れることにちなんで「php2shell（PHP2Shell）」と呼ばれています。

PHPのセキュリティチームは同日中に緊急リリースの事前告知を出し、修正版は10月21日14:00 UTC（日本時間23:00）に公開される予定です。どちらもCVSS v4.0で9.2という「緊急（Critical）」レベルの評価で、WordPress、Drupal、Magento、Laravelなど、PHPで動くあらゆるWebサイトが影響を受ける可能性があります。今回は、現時点で確認できている事実と未確認の情報を切り分けたうえで、運用者が取るべき対応を整理します。

何が起きたのか：流出から緊急リリースまで

今回の件が厄介なのは、通常の「修正版と同時に詳細を公開する」という順序が崩れてしまったことです。経緯を時系列で並べると次のようになります（括弧内は日本時間）。

  • 10月20日 15:20頃 UTC（21日 0:20頃）：情報の流出　Hacker Newsに「PHPに2件のRCE（リモートコード実行）脆弱性が近く公開される」という未検証の投稿が出回り、詳細の一部が流出。「PHP2Shell」という名前のエクスプロイトツールの画面写真も出回りました。
  • 10月20日：研究機関による確認　セキュリティ企業watchTowrが、脆弱性が実在し公開待ち（エンバーゴ中）であることを確認。同社はCVE-2026-109618の再現にも成功したとしていますが、詳細は修正版の公開まで伏せています。
  • 10月20日 19:33 UTC（21日 4:33）：PHP公式の事前告知　PHPセキュリティチームがphp.netとメーリングリストで、2件の重大な脆弱性を修正するセキュリティリリースを予告。
  • 10月20〜21日：CERT-EUの勧告　EU機関向けのCERT-EUがSecurity Advisory 2026-018を公開し、2つのCVE番号を明示しました。
  • 10月21日 14:00 UTC（21日 23:00）：修正版リリース予定　PHPは、詳細が公になったり実際の攻撃が確認されたりした場合は前倒しする可能性もあるとしています。
  • 10月22日：本来の協調公開日　流出がなければ、この日に公開される予定でした。

本来、脆弱性の協調公開は「防御側が先に修正版を手にする」ことを前提にしています。今回はその前提が崩れ、攻撃者と防御側がほぼ同じ情報を持った状態でリリースを迎えることになります。ECサイト向けセキュリティ企業のSansecは、修正版の公開から15分以内に大規模な攻撃が始まると予想しています。

脆弱性の概要

項目内容
通称php2shell / PHP2Shell（非公式の呼び名）
CVE番号CVE-2026-109618、CVE-2026-109619（CERT-EUや研究者による特定。PHP公式の告知にはCVE番号の記載なし）
深刻度CVSS v4.0で各9.2（Critical）※PHPセキュリティチームの評価。ベクトルは未公開
種類PHPコア（本体）のリモートコード実行（研究者・報道による）
認証の要否不要（ログインなしで攻撃可能）と報じられている
影響バージョン公式には未発表。流出情報ではPHP 5以降、Sansecは5.4以降と説明
修正版10月21日14:00 UTC公開予定。対象はサポート中の8.2／8.3／8.4／8.5のみ
悪用状況実環境での悪用は確認されていない（10月21日時点）。CISAのKEVカタログにも未掲載

公式に確認されていること／まだ確認されていないこと

今回は噂や推測が入り混じっているので、情報の確度を分けて把握しておくことが大切です。

  • PHP公式が認めていること：重大な脆弱性が2件あること、いずれもCVSS v4.0で9.2であること、修正版を10月21日14:00 UTCに出すこと。影響バージョン・修正版・技術的な詳細はリリースと同時に公開するとしています。
  • 研究者・関係機関が言っていること：CVE番号、リモートコード実行であること、認証不要であること。watchTowrやSansecなど複数の企業が独立に確認しており、信頼度はかなり高いと考えてよいでしょう。
  • 未確認のもの：正確な影響バージョンの範囲、根本原因、具体的な攻撃条件。セキュリティ企業Patchstackは複数の悪用事例を確認したと発表していますが、技術的な根拠は示されておらず、現時点では未確認情報として扱うのが妥当です。

技術的な手がかり（未確認）

流出情報や一部の研究者の分析では、PHPの「セッションアップロード進捗（session upload progress）」機能に関わるメモリ安全性の不具合（解放済みメモリの使用＝use-after-free）が、細工したファイルアップロード形式（multipart/form-data）のPOSTリクエストで突かれる、という攻撃経路が指摘されています。一方で、標準的な最適化オプションでビルドされた本番用のPHPでは、同じ条件の再現に至らなかったとする検証も出ており、見解は割れています。

なお、GitHubなどには「PoC（概念実証コード）」をうたうリポジトリがすでに複数出回っています。こうした非公式のコードには、検証目的を装ったマルウェアが紛れていることも珍しくありません。業務端末で安易にダウンロード・実行しないよう注意してください。

影響範囲：アプリの更新では防げない

今回の脆弱性は、WordPressのプラグインやフレームワークではなく、PHPそのもの（実行環境）にあります。そのため、WordPress本体やプラグインをいくら最新にしても塞がりません。対策の担い手は、サーバーのPHPを管理している人、つまり自社のインフラ担当者、レンタルサーバー・マネージドホスティング事業者、あるいはコンテナのベースイメージを管理しているチームです。

Apacheのmod_php、Nginxと組み合わせるPHP-FPM、CGIなど、どの動かし方でもPHPが外部からのリクエストを処理している限り、影響を受ける前提で考えておくのが安全です。

サポート終了（EOL）バージョンには修正が出ない

もっとも深刻なのが、すでにサポートが終了した古いPHPです。PHPが修正版を出すのはサポート中の4系統だけで、8.1以前には公式の修正は提供されません。

系統修正前の最新版サポート状況修正の提供
PHP 8.58.5.11アクティブサポート（〜2027年12月31日）あり
PHP 8.48.4.26アクティブサポート（〜2026年12月31日）あり
PHP 8.38.3.35セキュリティ修正のみ（〜2027年12月31日）あり
PHP 8.28.2.34セキュリティ修正のみ（〜2026年12月31日）あり
PHP 8.1、8.0、7.x、5.x―サポート終了なし

Shodanの集計では、PHP 8.1以前を動かしているインターネット公開ホストが約88万4,000台あるとされます（バージョンを表示していないホストもさらに約74万台）。影響範囲がPHP 5系までさかのぼるという流出情報が正しければ、これらのサーバーは公式パッチなしで攻撃にさらされることになります。PHP 8.2もサポート期限は2026年末なので、今回の件を機に移行計画を前倒ししておくのがよいでしょう。

対応指針

今回は「リリースされたら更新する」という通常運用では間に合わない可能性があります。リリース前・暫定対策・リリース後・侵害確認の4段階で整理します。

1. リリース前にやっておくこと

  1. PHPが動いている場所をすべて洗い出す：Webサーバーだけでなく、コンテナイメージ、CI環境、管理画面付きのアプライアンス製品、cPanelやPleskなどのホスティング管理ツールに同梱されたPHPも対象です。
  2. インターネットに公開されているものを優先順位の先頭に：レスポンスヘッダーの X-Powered-By: PHP/x.y.z や PHPSESSID クッキーは、PHPが動いている目印になります。
  3. 更新手順を事前に準備する：パッケージ情報の更新、承認フローの段取り、サーバーごとの更新・再起動コマンドを用意し、「23時に誰が実行するか」まで決めておきます。
  4. 修正が出ないサーバーの扱いを決める：EOLのPHPは、サポート版への移行、ディストリビューションやホスティング事業者によるバックポートの確認、ネットワークでの隔離、一時停止のいずれかを選びます。
  5. バックアップとログの強化：公開サーバーのスナップショットを取り、Webサーバー・PHP-FPMのログを詳細化しておくと、後の侵害調査が格段に楽になります。

サーバー上のPHPバージョンやパッケージは、たとえば次のように確認できます。

# PHPのバージョン（CLI）
php -v

# Debian / Ubuntu系
dpkg -l | grep -i php

# RHEL / AlmaLinux / Rocky Linux系
rpm -qa | grep -i php

# パッケージ管理外の独自ビルドも探す
find / -xdev -name 'php*' -type f 2>/dev/null

注意したいのは、コマンドラインの php と、実際にWebリクエストを処理しているPHP-FPMやmod_phpが別のバイナリ・別のバージョンであるケースが少なくないことです。php-fpm8.3 -v のようにFPM側も個別に確認するか、管理者だけが見られる場所で phpinfo() を一時的に確認すると確実です（確認後は必ず削除してください）。

2. 暫定的な緩和策（パッチの代わりにはならない）

PHP公式は回避策を公表していません。以下はいずれも、コミュニティやセキュリティ企業が推奨している「時間稼ぎ」の手段です。

  • セッションアップロード進捗機能の無効化：推測されている攻撃経路に基づく対策です。この機能はPHPの初期設定で有効になっていますが、アップロードの進捗バーを独自に実装しているような場合を除けば使われていないことが多く、無効化しても影響は小さいはずです。ただし根本原因が別にあれば効果はありません。
  • WAF（Webアプリケーションファイアウォール）：CloudflareはCTOのDane Knecht氏を通じて、既知のエクスプロイトに対するWAFルールを無料プランを含む全顧客に展開したと表明しています。他のWAF製品でも、アップロードを受け付けないURLへの大きなmultipart POSTを制限するなどの対策は有効です。ただし、メモリ破壊系の脆弱性はシグネチャで捉えきれないことも多い点は留意が必要です。
  • ネットワークでの隔離：CERT-EUは、すぐに更新できない場合はインターネット公開アプリを公開ネットワークから切り離すことを検討するよう呼びかけています。

アップロード進捗機能を無効化する場合は、php.ini（共用サーバーなどで許可されていれば .user.ini）に次の1行を追加し、PHP-FPMまたはWebサーバーを再読み込みします。

; php.ini
session.upload_progress.enabled = Off

# 反映（PHP-FPMの例。サービス名は環境に合わせて変更）
sudo systemctl reload php8.3-fpm

3. リリース後にやること

  1. 公式情報で修正版を確認する：影響バージョンと修正版の番号は、php.netのリリース告知とphp-srcのGitHubセキュリティアドバイザリで確認します。SNSなどで出回っている番号を鵜呑みにしないでください。
  2. 公開サーバーから順に更新し、必ず再起動・再読み込みする：パッケージを更新しても、PHP-FPMやApacheを再起動しないと古いバイナリが動き続けます。
  3. ディストリビューション版は「バックポート」に注意：DebianやUbuntu、RHEL系の公式パッケージは、バージョン番号を変えずに修正だけを取り込むことがあります。番号だけで判断せず、パッケージの変更履歴（changelog）に該当CVEが含まれているかを確認しましょう。
  4. コンテナはイメージを再ビルドする：公式のPHPイメージなどベースイメージが更新されたら、それを使ってアプリのイメージを作り直し、再デプロイします。

4. 侵害されていないかの確認

更新前の空白期間に侵入されていた場合、パッチを当てても仕込まれたバックドアは残ります。この種の攻撃の最終目的はほぼ例外なく「Webシェル」の設置なので、更新後は痕跡の確認に切り替えます。

  • 流出が始まった10月20日以降に、ドキュメントルートやアップロード・キャッシュ用ディレクトリに作成・変更されたPHPファイルがないか
  • php-fpm、php-cgi、httpd、apache2などのプロセスが、シェルやスクリプト言語、curl・wgetなどを子プロセスとして起動していないか
  • Webサーバーから見慣れない宛先への外向き通信（リバースシェルなど）がないか
  • CMSの管理者ユーザー、cronジョブ、スケジュールタスクが勝手に増えていないか
# 10月20日以降に作成・変更されたPHPファイル
find /var/www -type f -name '*.php' -newermt '2026-10-20' 2>/dev/null

# Webシェルによく見られる関数呼び出しを含むファイル
grep -rlE 'eval\(|base64_decode\(|assert\(|system\(|passthru\(|shell_exec\(' /var/www 2>/dev/null

2つ目のコマンドは正規のプラグインやライブラリも多数ヒットするため、結果は「怪しいファイルの候補リスト」として、更新日時や設置場所とあわせて判断してください。不審な挙動が見つかった場合は、サーバーをネットワークから切り離し、ログを保全したうえで調査に移り、そのサーバー上にあった認証情報（データベースのパスワード、APIキーなど）はすべて変更します。

立場別：まず何をすればいいか

立場まずやること
レンタルサーバー・マネージドWordPressの利用者事業者のお知らせを確認し、PHPバージョンを管理画面で選べる場合はサポート中の8.2以降になっているか確認。8.1以前を選んでいるなら、動作確認のうえ切り替える
自社でサーバーを運用しているPHPの棚卸し、更新手順の準備、リリース直後の適用と再起動、その後の侵害確認までを一連の作業として計画する
開発・コンテナ運用チームDockerfileのベースイメージとそのバージョン固定を確認し、修正版のイメージが出たら再ビルド・再デプロイ。CI環境のPHPも忘れずに
EOLのPHPを抱えている公式修正は出ない前提で、移行・バックポート・隔離・停止のいずれかを今日中に決める

まとめ

php2shellは、Webの大部分を支えるPHPの本体に、認証不要で悪用できるとされる重大な脆弱性が2件見つかり、しかも修正版より先に情報が流出したという、きわめて条件の悪いケースです。Log4Shellほど依存関係の調査に手間取ることはなく、「PHPを更新して再起動する」という対策自体はシンプルですが、修正版が出た瞬間に差分から攻撃方法が割り出されるため、更新までの数時間〜数日が勝負になります。

今やるべきことは、PHPの棚卸し、公開サーバーの優先付け、更新手順の準備、そしてEOLサーバーへの方針決定です。日本時間23時のリリース後は、公式の修正版を速やかに適用し、そのあと侵害の痕跡がないかまで確認して、はじめて対応完了と言えます。8.1以前のPHPがまだ残っている場合は、今回を最後の警告と受け止めて移行を進めましょう。

本記事は、PHP公式の告知、CERT-EUの勧告、各セキュリティ企業の公開情報（2026年10月21日21時・日本時間時点）をもとに整理したものです。執筆時点では修正版は未公開で、影響バージョン・修正版・技術的な詳細はPHP公式から発表されていません。CVE番号や攻撃手法に関する記述の一部は研究者・報道による情報であり、今後の公式発表で変わる可能性があります。実際の対応にあたっては、必ずphp.netの最新のリリース情報をご確認ください。

参考情報

関連記事