「中間点」。その後にこそ本番がある
「PHPパッチを当てたから安心」はまだ半分。
php2shell対応後に
必ずやるべき
「事後対応」
チェックリスト
【レンタルサーバー利用者向けの対応も解説】
前回の記事では、2026年10月21日に緊急リリースされたPHPの重大脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）をめぐり、「PHPだけ直してWordPressを放置する」ことの危険性について警鐘を鳴らしました。
PHPを更新した後も、「これで対応が完了したのか」を確認する作業が必要です。
結論から言います。PHPのパッチ適用は、セキュリティ対応の「ゴール」ではなく「中間点」です。その後にこそ、本当に重要な作業が待っています。
更新後の対応を考える際、環境は大きく「自前サーバー（VPS・専用サーバー・クラウド）で運用している場合」と「共用レンタルサーバーを利用している場合」の2つに分かれます。同じ「パッチ適用後」でも、できること・できないことが異なり、確認すべき作業も変わるのです。たとえば共用レンタルサーバーでは、PHPのインストールやサービスの再起動・プロセス管理は、通常、ホスト（事業者）側の領域です。
「プロの手順」として紹介される手順には、レンタルサーバーでは利用者が実行できない工程が含まれます。
本記事では、パッケージを当てただけでは防御が完了していない技術的な理由、そもそも侵害されていなかったかを確認する「事後調査」、CMS側に残る宿題を、自前サーバーとレンタルサーバーの両方の読者の目線で解説します。レンタルサーバー利用者の方は、特に「2. の各ステップの【レンタルサーバーの場合】」と「3. 環境別ガイド」をお読みください。
1. なぜ「パッチ適用後」が最も重要なのか：実攻撃は今も続いている
まず、なぜ「パッチを当てた後」まで目を光らせる必要があるのか。その理由は、攻撃の現実にあります。この点は、レンタルサーバー利用か自前サーバー運用かを問わず共通です。
（2026年10月〜11月上旬）
・開示前から攻撃は始まっていた。
Amazonの脅威インテリジェンスは、公表の4日前にあたる10月17日、観測網（ハニーポット）に対するphp2shellの悪用試行を確認し、調査の起点を「公表日の10月21日」ではなく「少なくとも10月17日」とするよう推奨しています（観測した試行が実環境で成功し得たかは不明とされています）。10月21日以降も複数の攻撃者の痕跡が観測されており、「野外で広範な悪用試行が見られている」と報告されています。
・PoC（概念実証コード）が公開され、実際の成功事例も出ている。
10月24日、研究者のAdel Karimi氏が、パッチ適用前のPHP 8.4.26（シングルワーカーのApache mod_php、memory_limit 128MiB）で稼働するハニーポット3台で、35件のシェル起動を確認したと報告しています（報告書）。通信内容は公開されているPoCの系統とよく一致していたとされ、報告はCVE-2026-109618に対応する手口としています。なお、これは修正版（8.4.27以降）が破られたという報告ではなく、あくまでハニーポット（おとりサーバー）での観測です。
・「PHPサイト以外」への波及も始まった。
10月29日、Palo Alto Networksは、インターネットに公開されたPAN-OS（ファイアウォール）の管理インターフェースに対するphp2shellの実攻撃を確認したと発表。さらに研究者は、php2shellの悪用をLinuxカーネルの権限昇格脆弱性（CVE-2026-46300）と連鎖させてroot権限を奪取する攻撃を観測しています。米CISAは、PHPの2件のCVE（CVE-2026-109618 / CVE-2026-109619）を10月26日に、カーネル側のCVE-2026-46300を10月28日に、それぞれ「実際に悪用が確認された脆弱性カタログ（KEV）」へ登録済みです。
一方で冷静に見るべき事実もあります。Sophosの分析によれば、今回確認されたPAN-OSへの攻撃は「標的型」であり、他のプラットフォームへの広範な悪用能力が開発されたことを示すものではないとされます。ただし、これは「自分は大丈夫」を意味しません。実攻撃の報告を踏まえ、事後対応を進める必要があります。
パッチは「これ以降の侵入」を防ぐ扉ですが、「これまでの侵入」を消してくれるわけではありません。開示前の10月17日から攻撃試行が観測されていた以上、「自分のサイトは大丈夫だったか？」を確認する作業は、パッチ適用と同じくらい重要なのです。
2. 【鉄則】PHPを更新したら「すぐにやるべき」5つの事後対応（自前サーバー／レンタルサーバー別注記つき）
「PHPのパッケージ更新が完了した」
――この時点で、プロは決して作業を終えません。以下の5つの項目を確認します。侵害が疑われる場合の証拠保全は、再起動やファイル削除の前に判断してください。
なお、各ステップには【レンタルサーバーの場合】として、共用レンタルサーバー利用者が自分の環境で確認すべき行動を併記しています。環境ごとの違いを先に整理したい方は、「3. 環境別ガイド」もあわせてご覧ください。
スキャンや不審なリクエストの痕跡があるサーバーでは、再起動する前にPHPワーカーのメモリを保全することが推奨されています。なぜなら、再起動はメモリ上の証拠を消してしまうからです。メモリ上に残った攻撃の痕跡は、侵害の有無を判定する重要な手がかりになります。調査対象では、「とりあえず再起動してリセット」とする前に、証拠保全の要否を判断します。
共用サーバーでは、PHPワーカーのメモリの保全は、通常、ホスト側の領域です。一方、管理画面から取得できるログや、自分の管理領域にあるファイルは保存できます。そこで現実的な行動は、
兆候を発見したら、自己判断でPHPバージョンの切替・再切替などを重ねず、取得できるログ・ファイルを保存し、速やかにホストのサポートへ「生ログの提供」「調査・対応」を相談する
ことです。ホスト側にしか見えない情報（サーバー全体のエラーログ、ワーカーの状態、他テナントとの共通経路の有無等）は、提供や調査の可否を問い合わせてください。連絡前に、手元で確認した日時・ログ・兆候をまとめておくと調査が早く進みます。
ここが最も見落とされがちな落とし穴です。OSのパッケージマネージャでPHPを更新しても、稼働中プロセスの入れ替えが行われていなければ、古い（脆弱な）コードがメモリ上に残ります。PHP-FPMやApache（mod_php）では、更新時に自動で再起動されるかも含め、修正の反映を確認する必要があります。Googleのインシデント対応ガイダンス（Mandiantの知見を含む）も、この点を明確に指摘しています。
PHPを更新したら、PHP-FPM・Apache・LiteSpeed・キューワーカーなど、PHPを読み込むプロセスへの修正の反映を確認し、必要な再起動と実際に稼働中のバージョン（8.4.27等）の確認を行って「適用完了」としてください。
確認は、シェルの php -v（CLI）だけでなく、Webサーバー経由で配信されるphpinfo等（実際にリクエストを処理するPHP）でも行います。CLIとFPM・mod_phpは別のバイナリ・別の設定のことがあり、CLIだけ「修正済み」と表示されても、サイト側は未適用ということが起こりえます。phpinfoを使う場合はアクセスを制限し、確認後にファイルを削除してください。自分でイメージを管理するコンテナ環境では、修正済みPHPを含むイメージへの再ビルド・再デプロイなどが必要です。
PHPのサービス再起動は、共用レンタルサーバーでは通常、利用者が操作できません。その代わり、PHPのインストール・プロセス管理はホスト（事業者）側の領域であり、今回のような重大脆弱性ではホスト側で緊急メンテナンスとして対応が進んでいます（後述「3. 環境別ガイド」参照）。利用者の確認作業は次の2点です。
（1）ホストのお知らせ（公式サイト・管理画面内の告知）で、自分のサービス・PHP系列に対する緊急対応が完了したかを確認する。
（2）管理画面のPHPバージョン表示や、phpinfoが使える環境ではphpinfoで、自サイトが実際に動かしているバージョンを確認し、ホストの対応情報と照合する。
たとえばエックスサーバーでは、サーバーパネルの「PHP Ver.切替」画面にドメインごとの現在のPHPバージョンが表示され、切替もそこから行えます（公式マニュアル）。ただし、同社はPHP 5.1〜8.1にはバージョン番号を変えずに修正パッチを適用したと案内しています。古い番号の表示だけで未修正と判断せず、自ドメインの状態とホストの告知を照合してください。
前述の通り、攻撃試行は公表の4日前から観測されています。調査・ログ確認は「少なくとも10月17日までさかのぼる」ことが推奨されています。10月21日以降だけ見て「異常なし」と結論づけるのは、入り口で調査範囲を狭めてしまう典型的なミスです。あわせて、10月17日以降のログが実際に保存されているかを最初に確認してください。保存期間が短く、すでにログが消えている期間がある場合は、「調査できない期間がある」こと自体を記録し、その期間は侵害の可能性を否定できないものとして扱います。
調査範囲の設定は同じですが、前提が1つ増えます。「手元に残せるログの種類と期間がホストの仕様で決まっている」ということです。管理画面のアクセスログ機能では、日付ごとの確認やダウンロードなどができますが（たとえばエックスサーバーの「アクセスログ」公式マニュアル）、生ログ（rawログ）のダウンロード可否や保存期間はホスト・プランごとに異なります。まず「自分の環境で、いつからいつまでの何のログが見られるのか」を確定させるのが最初の作業です。見られない期間があれば、それを「調査できない期間」として記録する点は、自前サーバーと同じです。
対応期間中（少なくとも10月17日以降）のWebサーバーのアクセスログ・エラーログを確認し、通常とは異なる長大なクエリ文字列、深夜帯の大量アクセス、存在しないパスへの連続リクエストなどがないかを確認します。マルチパートのPOSTの直後にメモリ上限エラー（allowed memory size）や500エラー、PHPワーカーの異常終了・不審な再起動が続いていないか、記録されている場合には異常に大きなセッションID（PHPSESSID）のCookieがレスポンスに含まれていないかも、研究者が挙げている手がかりです。レスポンスのCookieは、通常のアクセスログで確認できるとは限りません。加えて、サイト上に見覚えのないファイル（特にPHPファイル）が増えていないか、事前にWordPressの認証ログを記録・保存していた場合は、知らないログイン成功記録がないかを確認します。侵入後によく設置されるのが「Webシェル」と呼ばれる遠隔操作用ファイルで、これはサイト上の静的解析・ファイル比較で検出を試みます。不審なアクセスの存在だけで侵害成功と断定せず、確認した範囲に痕跡がないことだけで侵害を完全に否定しないようにしてください。
「サイト上のファイル」はFTP（SFTP）・ファイルマネージャーで確認でき、共用サーバーでも実施できます。「WordPressの認証ログ」は、記録する仕組みが事前に導入され、保存されている場合に確認します。一方、エラーログや生ログの閲覧はホスト依存です。管理画面のアクセスログ機能（たとえばロリポップ！では「サーバーの管理・設定」メニューの「アクセスログ」公式マニュアル）で見られる範囲をまず確認し、管理画面で取得できないエラーログや生ログが必要な場合は、ホストに提供可否を問い合わせてください。保存期間や提供できる範囲はホストによるため、依頼は早いほど良いです。
php2shellには、PHPワーカーのメモリ内容が外部に漏れうるという指摘があります（研究者の分析では、レスポンスのCookieヘッダに数十KB規模のメモリ内容が含まれる手口が報告されています）。ワーカーのメモリには他のリクエストの認証情報が載っていた可能性があるため、修正前に外部公開されていたサーバーでは、「メモリ上に認証情報が存在し、読み取られた可能性」を否定できません。その可能性を踏まえ、WordPress管理者・DBユーザー・SFTP・サーバー管理画面のパスワードや、APIキー・シークレットキー・セッション署名鍵類の更新（ローテーション）を進めてください。侵害が確認された場合は、必要なアクセス制限や認証情報の失効を行い、不正なファイルなどへの対応後にも認証情報を更新します。また、構成によってはワーカーのメモリにTLS証明書の秘密鍵が載っていた可能性も指摘されています（Sysdig）。PHPから秘密鍵にアクセスできたかなどを確認し、漏えいが疑われる場合は、証明書の再発行（鍵の更新）や失効を検討してください。
上記に加えて、ホストの管理画面（サーバーパネル・コントロールパネル）のログインパスワードと、FTP（SFTP）の認証情報も確認対象に含めてください。これらすべてがphp2shellで漏えいしたと断定するものではありませんが、使い回しや不審な利用の有無も確認します。DBユーザーのパスワード変更は、ホストが案内する管理画面や手順に従って行います。変更後は、wp-config.php等の設定ファイルの書き換え忘れに注意してください。
なお、まだPHPを更新できない公開システムがある場合は、この5ステップの前段として、CISA・CERT-EU・Sophosなどが挙げる暫定策『インターネットからの公開を止める、またはZTNA等のネットワーク層認証の内側に置く』を検討してください。レンタルサーバーの場合は、この判断もホストと相談になります（共用サーバーでは、サイト単位のアクセス制限機能で可能な範囲を確認するか、ホスト側の案内に従ってください）。
3. 環境別ガイド：レンタルサーバーと自前サーバー（VPS・クラウド）で、ここが違う
5つのステップの「目的」は環境に関係なく共通ですが、「誰が何を操作できるか」が異なります。まずは、ご自身の環境がどちらに当てはまるかを正しく認識してください。
①ホストのお知らせで対応状況を確認する → ②管理画面・phpinfoで自サイトのPHPバージョンを確認する → ③暫定設定が必要か、有効な設定方法があるかをホストの案内で確認する → ④管理画面のアクセスログとWordPress・サイト内の痕跡を確認する → ⑤管理画面・FTP・DB・WordPress等の認証情報を更新する
の5点に整理できます。利用者が直接PHPプロセスを再起動する必要はありませんが、ホストに任せきりにせず、対応の対象と完了状況を確認することが大切です。
PHPバージョンの確認・切替やphp.iniの変更、ログ確認が、どこまで管理画面からできるかはホストごとに異なります。代表例を公式マニュアルベースで挙げます。
- エックスサーバー：サーバーパネルの「PHP Ver.切替」でドメインごとの現在のバージョン確認と切替が可能。「php.ini設定」でパネル上から設定を変更でき、「アクセスログ」を確認・ダウンロードできます。設定できる項目と適用方法は、利用環境に応じて確認してください。
- さくらのレンタルサーバ：サーバーコントロールパネルの「言語のバージョン設定」でPHPバージョンを変更できます。サーバー全体のphp.iniは直接編集できず、「php.ini設定」から変更します。管理者権限が必要な一部の項目は変更できません。
- ロリポップ！：ユーザー専用ページの「PHP設定」で、ドメイン別のPHPバージョン確認・変更が可能です。同マニュアルのphp.ini変更手順はCGI版が対象で、モジュール版・LiteSpeed版では変更できないと案内されています。
- ConoHa WING：コントロールパネルからPHPバージョンの変更とphp.iniの編集が可能です。設定の対象や適用方法は、マニュアルと利用環境を照合してください。
「ホストが対応済みか」は、必ず各社のお知らせ（公式サイト・管理画面内の告知）で確認してください。たとえばエックスサーバーは、PHPの脆弱性への対応について公式の案内ページを用意しています。同ページはCVE-2026-109618 / CVE-2026-109619の2件を対象とし、10月23日に追加告知された脆弱性は対象外と明記されています。見た目は動いているから大丈夫、ではなく、「対応の事実」と「自サイトが対象に含まれるか」の両方を確認してください。ホスト側で修正の反映まで完了したと案内されている場合、利用者がすべきなのは、自己判断での再適用ではなく確認（適用状態やログの確認）です。
管理画面や公開情報で確認できない場合は、次の事項をホストに問い合わせます。兆候がある場合ほど早めに相談してください。
- 生ログ（rawログ）・エラーログの提供：管理画面で取得できるものを保存し、より詳細なログが必要な場合は提供可否を確認する。対象期間は少なくとも10月17日までさかのぼり、保存・提供できる期間を確認する。
- 適用状況の確認：ホスト側のPHP緊急対応の完了状況と、対象バージョン（自プラン・自ドメインが含まれるか）。
- php.iniで変更できない項目の相談：
session.upload_progress.enabled=0の設定が必要か、有効に反映できる方法があるかをホストに確認する（ホスト側で無効化済みの場合もあります）。 - 兆候発見時の調査依頼：不審なリクエストの痕跡が見つかった場合、日時・ログ・兆候をまとめ、調査・対応の可否をサポートへ相談する（STEP 1のレンタルサーバー版）。
「レンタルサーバーだから何もしなくていい」ではありません。「自分で再起動しなくていい分、確認と依頼に取り組む」と捉えるのが、レンタルサーバー利用者の事後対応です。
4. WAFの正しい位置づけ：「つなぎ」であって「恒久対策」ではない
今回の騒動では、CDN大手のCloudflareが公表の約9時間前にWAFルールを展開し、WAFを利用する無料・有料の顧客にデフォルトで保護を提供したことが話題になりました。これは素晴らしい動きですが、その位置づけを誤解してはいけません。
PHP公式も、設定変更（session.upload_progressの無効化など）について、「特定の攻撃経路への露出を減らすものであり、環境を安全にするものではない」（更新だけが完全な解決策）という趣旨を明記しています。同様にSophosも、即時にアップデートできない組織には「インターネット公開のPHPシステムを一時的にオフラインにする、またはZTNA等のネットワーク層認証の内側に置く」ことを暫定対策として挙げ、アップグレードが最善の防御だとしています。
レンタルサーバー利用の場合：WAFの有無や種類はホスト・プランによって異なります。ホスト標準のWAFやセキュリティ機能がある場合は「有効化されているか」を管理画面で確認し、PHP対応（ホスト側の適用と自サイトの適用状態の確認）の代替にはならない点は、本節の原則どおりです。前回の記事で述べた「多層防御」の原則を、今回は「多層防御の使い方」として正しく実践しましょう。
5. 落とし穴：パッチ適用後も続く「次の脆弱性」と「更新による副作用」
「最新版に上げたから万事OK」
残念ながら、今回の件はそう単純には終わりません。パッチ適用後に知っておくべき「残る課題」が2つあります。どちらも、レンタルサーバー利用者には「ホストの対応を追いかける」という形で関わる課題です。
CVE-2026-115560
緊急修正版の公開から2日後の10月23日、PHPプロジェクトはセッションのアップロード進捗（session upload progress）機能に関する新たなRCEの経路を、情報提供アドバイザリとして公表しました（CVE-2026-115560）。
PHPはこれを「通常とは異なる設定とアプリケーションコードの組み合わせでのみ起こる、起こりにくい経路」としており、緊急リリースではなく通常のリリース周期で対応し、全文のアドバイザリは次回リリースで公開するとしています。PHPの情報提供告知には影響を受けるバージョンの一覧が掲載されていないため、10月21日の緊急修正版に更新したことだけで、この別件への対応まで完了したとは判断できません。公式の案内に沿って、該当条件と暫定策を確認してください。
2026年11月9日時点で、PHPによる全文のアドバイザリは未公開で、影響を受けるバージョンの一覧や深刻度（CVSS）も同告知には示されていません。また、このCVEの悪用の公的な報告は、私たちが確認した範囲では見当たりません。PHP公式の開発者向けフォーラムでは、PHP 8.5.13のリリース候補版（RC1）が11月5日に公開され、正式版は11月19日の予定と案内されています（php.netでは、同日にPHP 8.6.0の正式版も予定されています）。ただし、このCVEがどのリリースで修正されるかは、PHPから明言されていません。リリース時に、PHP公式の全文アドバイザリを必ず確認してください。
該当するのは、次の条件がすべて重なる場合です。
session.serialize_handlerが設定でphp_binaryまたはphp_serializeになっている- アプリケーションが
ini_set()でphpに切り替えてからsession_start()を呼んでいる - session upload progress が有効（初期設定で有効）
PHP公式は、実行中にセッションのシリアライズハンドラーを変更しないアプリケーションでは、アップロード進捗機能を有効のままにできるとも説明しています。設定値だけでなく、アプリケーションの処理と併せて判断してください。
暫定策として、サーバー側のphp.ini・PHP-FPMのプール設定など、リクエストの解析前に反映される設定で session.upload_progress.enabled=0 を適用し、必要なPHPワーカーの再起動を行うことが推奨されています（これはCVE-2026-109619の緩和策としても挙げられていた設定です。すでに有効に適用済みなら、この設定を維持します）。なお、upload progressの処理はアプリケーションのコードより先に動きうるため、アプリ側の ini_set() や、FPMの .user.ini に頼る方法では、必要なタイミングに間に合いません。アップロード進捗バーをセッション経由で実装している場合は、無効化で進捗が取得できなくなる点も確認してください。
共用サーバーでは、管理画面に「php.ini設定」があることだけで、この暫定策が有効に適用できるとは判断できません。例えば、さくらのレンタルサーバでは、管理画面から変更できる設定の範囲が案内されています。設定項目と読み込みのタイミングは環境によって異なるため、ホスト側の対応状況と、利用者側で必要な設定・有効な反映方法を確認してください。事業者の案内がない状態で、
.user.ini やWordPressのプラグインに設定しただけで対応完了としないでください。
つまり、「緊急パッチを当てた＝今後何もしなくていい」ではなく、次のPHPリリースも追いかける必要があるのです。レンタルサーバー利用者であれば、「ホストがどの時点でどの脆弱性に対応するか」のお知らせを追い続けることが、同じ意味で必須の作業になります。
SimpleXML環境でのプロセスクラッシュ
さらに現場視点で重要なのがこちらです。PHP開発者は、新しくリリースされた8.4.27および8.5.12において、SimpleXML拡張を使う一部アプリケーションでPHPプロセスがクラッシュしうる回帰バグ（php-src issue #24488）を確認しました。原因はphp2shellの修正パッチではなく、同梱された別のガベージコレクタ修正とされています。
修正コードは10月22日にPHP 8.4ブランチへマージ済みですが、2026年11月9日時点で、修正を含む正式版はまだ公開されていません。緊急修正版でも、同梱する別の変更によって不具合が起きることがある実例です。だからこそ前回の記事で申し上げた通り、ステージング環境での検証と、適用後の主要機能の確認が大切です。緊急時は、検証中の公開リスクも考慮して対応を進めてください。なお、クラッシュが出ても未パッチ版へ戻すのは避け、配布元やホストと修正版・回避策を確認するのが原則です。また、Windows向けビルドについても10月26日、同梱ライブラリ（Brotli）の別脆弱性（CVE-2026-111497）を修正した再ビルド版（8.5.12-1など）が提供されています。この脆弱性にはcURL拡張で自動解凍が有効な場合に到達しうるため、Windows環境では適用した配布パッケージを確認してください。「-1」はパッケージの再ビルド番号で、PHPの実行時バージョン自体は変わりません。利用環境ごとの細かな追跡も、事後対応の一部です。
この回帰バグへの実用的な自衛策は、普段から稼働確認ポイントを決めておくことです。パッチ適用直後〜数日間は、お問い合わせフォームやXMLフィードの取り込みなど、普段から動きが分かる主要機能をチェックし、急に500エラーやフリーズが増えたら「ホストのPHP更新と時期が重なっていないか」を確認します。ホスト側のバージョン更新の履歴は、お知らせで確認してください。phpinfoの表示は現在の実行環境を確認する手がかりになります。クラッシュが続く場合は、プラグイン・テーマの組み合わせと併せて、ホストへ状況を伝えて相談してください。
併せて、サポート状況の棚卸しも事後対応の一部です。PHP 8.1以前はすでにPHP公式のサポートが終了しており、PHP 8.2も2026年12月31日にサポート終了を迎えます。今回PHPプロジェクトはPHP 7.4・8.0・8.1向けの最小限のソースバックポートも提供しましたが、あくまで緊急対応です。ディストリビューションのバックポート版を使っている場合は、変更履歴やセキュリティ情報で両CVE（CVE-2026-109618 / CVE-2026-109619）への対応を確認し、サポート切れの環境は移行計画を立てましょう。
レンタルサーバー利用者にとっては、これは「ホストのサポート切れ告知をチェックする」という行動に置き換わります。管理画面のPHPバージョン表示が「非推奨バージョン」になっていないか、ホストが移行期限の案内を出していないかを確認し、期限前に自サイトの動作確認（プラグイン・テーマとの相性）を済ませておくのが、レンタルサーバー版の「棚卸し」です。
6. WordPress側の事後対応：侵入経路の「玄関」を掃除する
PHP側の事後対応が整ったら、次はWordPress（CMS）側です。前回の記事で「PHPとWordPressは運命共同体」と申し上げましたが、事後対応も同様に両輪です。このセクションの作業は、共用レンタルサーバーでも自前サーバーでも、手順はほぼ同じです。具体的には以下の3点を行います。
今回の緊急対応を機に、長期間放置されていたWordPress環境の更新も進めましょう。その必要性を示す実例が、9月に公開されたWordfenceの技術解説でも紹介されています。人気の移行・バックアッププラグイン「All-in-One WP Migration and Backup」の高深刻度の脆弱性（CVE-2026-19949、CVSS 8.8）は、WordPressのトラックバック経由で仕込まれたSQL文が、管理者がエクスポートしたアーカイブを復元する際に実行される「第二種SQLインジェクション」です。認証なしの攻撃者がプラグインの秘密のインポートキーを取得し、悪意のあるアーカイブ（.wpress）を取り込ませてリモートコード実行（RCE）に至る経路が指摘されました。Wordfenceの解説時点で500万以上の有効インストールを持つこのプラグインでは、修正版7.110が8月20日にリリースされています。
PHP本体を更新しても、プラグイン側の脆弱性は別に対応する必要があります。更新だけでなく、更新前に侵害されていなかったかの確認もセットで行ってください。
前述の通り、メモリ漏えいや侵害の可能性を踏まえ、WordPress管理者・データベース・サーバーへの認証情報について、更新・失効の対象を確認します。侵害が確認された場合は、初期対応時の認証情報の失効に加え、不正なファイルや侵入経路への対応後に改めて更新してください。特にバックアップ系プラグインが持つ「インポート用の秘密キー」のような仕組みは、漏えいすると復元機能そのものが攻撃の入口に化けます（前述のAll-in-One WP Migrationの事例がまさにそうでした）。鍵・シークレットの類も「作ったきり放置」せず、更新対象から漏らさないよう管理してください。
レンタルサーバー利用の場合は、ここに「管理画面（サーバーパネル・コントロールパネル）の認証情報」と「FTP（SFTP）の認証情報」も含めて確認してください。可能なホストでは二段階認証（2FA）も併せて有効にしてください。
事後対応の締めとして、侵害への対応と状態の確認を行ったうえで、復旧用のバックアップを取り直すことが重要です。調査のために保存したデータと、復旧に使うバックアップは分けて管理してください。万一の際の復旧計画（前回記事の「切り戻し」）は、実際に復元テストをして、復元できることを確かめる必要があります。定期的な復元訓練（DRテスト）まで含めた運用を、今回を機に組み込むことを推奨します。
レンタルサーバー利用の場合：ホストが提供する自動バックアップがある場合は、その仕様（保存世代・保存期間・復元方法・追加料金）を管理画面で確認し、WordPress内プラグインのバックアップと別系統での保管も検討してください。ホスト側バックアップの復元は管理画面から可能なこともありますが、復元の対象や上書きの範囲はホストごとに異なります。手順の確認は準備であり、実際の復元テストの代わりにはなりません。本番に影響しない検証環境等での復元方法をホストや保守担当者と確認し、未実施の場合は「復元テスト未実施」として残してください。
7. まとめ：セキュリティ対応の完成は「確認と検証」で行われる
「PHPのパッチを当てた。WAFも効いている。よし、これで安心だ」
もし貴社の対応がここで止まっているなら、事後対応の確認が残っています。
- パッケージ更新だけで適用完了と判断せず、PHP-FPM・Apacheなどの稼働中プロセスに修正が反映され、Web側が修正済みPHPで動いていることを確認する。共用レンタルサーバーでは再起動はホストの領域なので、「ホストのお知らせ確認→管理画面・phpinfoと事業者の修正情報の照合」に置き換える。
- 侵害調査は「公表日（10月21日）」だけを起点にせず、「少なくとも10月17日」までさかのぼる。兆候のあるサーバーは再起動の前に必要な証拠保全を判断する。共用レンタルサーバーでは、取得できるログやファイルを保存し、メモリ等の保全や追加の調査は早めにホストへ相談する。
- WAF・設定変更はPHP本体の修正の代替にはならない。PHP公式は修正版の適用を求め、CloudflareもPHP更新とWAF保護の併用を推奨している。ホスト標準のWAFも、PHP対応と組み合わせて利用する。
- 緊急パッチ後も作業は続く。別件のCVE-2026-115560の該当条件と暫定策を確認し、次回リリースやホストの対応を追う。共用レンタルサーバーでは、管理画面で設定できることだけで有効と判断せず、ホストの対応状況と反映方法を確認する。
- CMS側の事後対応（プラグイン最新化・認証情報の見直し・復元を検証したバックアップ）も進める。レンタルサーバー利用者は、管理画面とFTP等の認証情報、ホスト側バックアップの仕様も確認する。
今回のphp2shellは、緊急パッチという「走り」を私たちに強いました。
しかし、その後の静かな確認作業（侵害調査、認証情報の見直し、CMSの最新化、復旧訓練）こそが、次の脆弱性が見つかったときに備えられる組織をつくるのです。
この「確認作業」は、自前サーバーとレンタルサーバーで分担が変わるだけで、なくなるものではありません。サーバーの根幹をホストに預けたレンタルサーバー利用者ほど、「確認できる範囲を確実に確認し、確認できないものは相談して対応を決める」規律が重要になります。
前回の記事で「パッチ適用はミニプロジェクトである」と申し上げました。
そして、そのプロジェクトでは、確認した範囲と結果、残る課題を記録し、「確認し、検証し、次に備える」ところまでを管理することが大切です。
参考情報・出典
- Tenable：php2shell（CVE-2026-109618 / CVE-2026-109619）FAQ
- Cloudflare Blog：PHP脆弱性に対するWAF保護
- Sophos：php2shell PoC公開と悪用状況の追跡
- PHP公式：PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35の公開と、追加のアドバイザリ
- Google Cloud：PHP脆弱性への対応ガイダンス（Mandiantによる証拠保全・再起動・調査の案内）
- AWS Security Blog：公表前（10月17日）のPHP2Shell悪用試行の観測
- CISA：実際に悪用が確認された脆弱性カタログ（KEV）の公開データ
- Palo Alto Networks Unit 42：PHP2Shellに関する脅威情報
- 0x4D31 honeypot-data：PHP2Shell悪用の確認報告（2026年10月24日・ハニーポット）
- Sysdig：PHP2Shellの影響（ワーカーのメモリに載りうる情報）
- PHP公式フォーラム：PHP 8.5.13RC1の告知（正式版は11月19日予定）
- PHP公式リポジトリ：SimpleXMLに関する回帰不具合（Issue #24488）
- Wordfence：All-in-One WP Migration and Backupの脆弱性（7.110は8月20日リリース）
- WordPress公式：侵害されたサイトへの対応
- FBI：Improve Cyber Resiliency（バックアップ・復元テスト）
- PHP公式：Supported Versions（サポートされているバージョン一覧）
- エックスサーバー：PHPのバージョンについて（サーバーパネル「PHP Ver.切替」の公式マニュアル）
- エックスサーバー：php.ini設定について
- エックスサーバー：アクセスログ
- エックスサーバー：PHPの脆弱性への対応に関する公式案内
- さくらインターネット：PHPのバージョンを変更したい
- さくらインターネット：php.iniの設定内容を変更したい
- ロリポップ！：PHP設定
- ロリポップ！：ユーザー専用ページメニュー紹介（アクセスログ等）
- ConoHa WING：PHPの設定をする
PHP更新後の確認・WordPress保守でお悩みの方へ
「サーバー側のPHP対応は済んだが、自社で何を確認すべきか分からない」
「WordPress・テーマ・プラグインの更新や動作確認を相談したい」
「サーバー事業者・制作会社・社内担当者の役割分担を整理したい」
「バックアップや復旧手順を含め、保守・運用体制を見直したい」
株式会社ヒューコネクトでは、Webサイトの保守・運用についてご相談を承っています。
ご利用のサーバーやCMS、現在の管理体制を伺い、必要な作業と担当範囲を整理したうえで、対応方針と支援内容をご案内します。
