目次

報告された「php2shell」の脆弱性には、PHPの緊急アップデートで対応してください。WordPressだけを更新しても修正されません。提示されたレポートには、一律に「23:15から乗っ取りが始まる」とする根拠はなく、サーバー1台のログ調査では、ほかの環境で攻撃があったかどうかも判断できません。

要点#

  • レポートは、CVE-2026-109618とCVE-2026-109619を、認証なしのリモートコード実行につながる可能性があるPHPの脆弱性として挙げています。
  • PHPはアプリケーションのコードが動く前にリクエストデータを処理する場合があるため、公開アップロードフォームがなくても影響を受ける可能性があります。
  • レポートでは、PHP 8.2.35、8.3.36、8.4.27、8.5.12で修正されたとしています。インストール済みのパッケージを、PHPまたはホスティング事業者のアドバイザリと照合してください。
  • 著者は1台のVPSで明らかなトラフィックの変化を確認しませんでしたが、これはサーバーの安全性や、脆弱性が悪用されていないことを示すものではありません。

修正が必要なもの#

影響を受けるのは、WordPressやそのプラグイン、テーマの基盤となるPHP自体です。WordPressの管理画面ですべてが最新と表示されていても、基盤のPHPにセキュリティ修正が適用されているとは限りません。

秋山大志氏の10月21日のレポートによると、2つの脆弱性はリクエスト処理中と、それに関連する後処理でのメモリ操作に関係しています。報告されている影響は、単なるメモリリークではなくリモートコード実行です。実際に影響を受けるかどうかは、PHPのビルド、設定、実行環境によって異なります。

アップロードフォームを削除すれば解決すると考えてはいけません。攻撃者はリクエストを直接送信でき、WordPressが認証を確認したり独自のコードを実行したりする前に、PHPがその本文を解析する場合があります。

カウントダウンが成り立たない理由#

レポートによると、PHPのウェブサイト用リポジトリでは、予定されていた23:00より早い10月21日21:59（日本時間）にリリース告知とセキュリティアドバイザリが公開されました。GitHubでの技術的詳細の公開は22:34とされています。これらは報告上の公開時刻であり、すべてのダウンロード経路が同時に更新された証拠として扱うべきではありません。

「15分」という主張は、大規模攻撃がどれほど早く始まるかについてのSansecの予測に由来します。それが繰り返し伝えられるうちに、乗っ取りが始まる正確な期限へと変わりました。また、レポートにはパッチ公開前から情報が出回っていたとの記述もあり、攻撃者が公開時点で作業を始めたとは限りません。

AIは変更内容の分析に役立ちますが、それだけで15分以内に動作する攻撃コードが作られた証拠にはなりません。不具合の理解と、異なるサーバー構成で確実に悪用することは別の作業です。管理者は、根拠のないカウントダウンに合わせて対応を予定するのではなく、更新までの時間を短縮すべきです。

サイトを動かしているPHPを更新する#

ウェブリクエストを処理しているPHP実行環境を確認してください。複数のPHPがインストールされているサーバーでは、コマンドラインでのバージョン確認だけでは判断を誤る場合があります。

1. ホスティング管理画面や管理者専用の診断機能で、サイトのPHPバージョンと実行方式を確認します。 2. インストール済みのパッケージを、PHPのアドバイザリおよびベンダーのセキュリティ通知と照合します。ベンダーは、上流のバージョン番号を採用せずに修正をバックポートする場合があります。 3. 該当するセキュリティ更新をインストールし、事業者の指示に従って関連サービスの設定再読み込みや再起動を行います。 4. その後、稼働中のウェブ用実行環境を確認し、ログイン、投稿、サイトで使用する決済やアップロード機能をテストします。

レポートは、リモートコード実行が実証されたApacheのmod_phpを、最もリスクの高い構成として挙げています。PHP-FPMでは悪用の条件が一部変わりますが、特定のアプリケーション条件下で成立し得る経路も記述されています。したがって、「FPMを使っている」というだけでは更新を延期する十分な理由になりません。

古いPHPには移行計画が必要#

PHP 8.1以前について、レポートは上流からバージョン番号付きのセキュリティリリースは提供されていないとしています。7.4、8.0、8.1向けには限定的なソースコードのバックポートがあり、ディストリビューションや商用ベンダーが修正を提供している可能性もあると説明しています。ソースパッチは、存在するだけでは保護になりません。ビルド、デプロイ、検証が必要です。

メジャーアップグレードでは、まずサイトのコピーでテストしてください。WordPress、プラグイン、テーマを移行先のPHPに対応したバージョンへ更新し、重要な操作を試してエラーログを確認します。PHPのメジャーバージョン変更後は、古い拡張機能や独自コードが動かなくなる場合があります。

レポートによると、PHP 8.2のセキュリティサポートは2026年12月31日に終了します。10月22日時点では、移行に残された時間はわずかです。互換性があり、より長くサポートされる系列を優先し、選ぶ前にサポート期限を確認してください。一時的な設定変更は部分的な緩和策として扱い、安全の証明と考えないでください。

VPSのログから分かること#

秋山氏は、約14分40秒の時計のずれを補正したうえで、日本時間21:59から22:55までのApacheとPHP-FPMを使うVPSを調査したと報告しています。PHP関連URLへの探索リクエストは13件、PHPのパスへのPOSTリクエストは41件で、PHP-FPMの異常終了やメモリ不足エラーは記録されていませんでした。

この観察から言えるのは、確認できたログでは、その時間帯に明らかな急増が見られなかったという限定的な結論です。乗っ取りの開始時刻を裏付けるものでも、悪用がなかったと証明するものでもありません。通常のアクセスログには一般にリクエスト本文が含まれず、1台のFPMサーバーでほかの環境を代表することはできません。

時計のずれも重要です。リクエスト、エラー、セキュリティイベントを照合するには、正確なタイムスタンプが必要です。時刻同期を正し、関連ログを保存し、クラッシュがないことをパッチ不要の根拠にしないでください。

次の対応#

ホスティング事業者の通知またはOSベンダーのアドバイザリを使い、本番サイトを動かしているPHP実行環境のセキュリティ更新状況を、今日中に確認してください。

出典: https://blogs.itmedia.co.jp/agile/2026/10/php2shell_cve_2026_109618_panic.html

目次