PHPに重大な脆弱性「PHP2Shell」。想定される被害とWordPress運用者が確認すべきこと

2026年10月21日、PHPで認証なしのリモートコード実行につながる重大な脆弱性2件が公表され、修正版が公開されました。CVE番号はCVE-2026-109618とCVE-2026-109619で、「PHP2Shell」とも呼ばれています。

まず確認したいのは、Webサイトで実際に動いているPHPへ修正が適用されているかです。WordPress本体やプラグインの更新だけで、PHP本体の問題が解消されるわけではありません。レンタルサーバーなら提供会社の対応状況を確認し、VPSや自社管理サーバーなら管理担当者が更新と稼働状態を確かめる必要があります。

この記事では、公式発表で確認できる事実と、攻撃が成立した場合に考えられる被害を分け、企業サイトの担当者が進める確認を整理します。情報の確認日は2026年10月22日です。

何が起きたのか。WordPressのさらに土台にある問題

PHPは、WordPressなどのWebシステムをサーバー上で動かすための言語・実行環境です。今回の問題は、特定のWordPressプラグインの欠陥ではなく、そのPHP本体にあります。

PHP公式は、Webリクエストを処理するPHP環境を広く注意対象とし、修正版への即時更新を呼びかけています。ログインしていない外部の相手による攻撃が成立し得るため、「管理画面のパスワードを強くしたから対応済み」とは言えません。PHP公式のセキュリティ勧告

2件の脆弱性は、いずれもメモリーの扱いに関係します。専門的な仕組みをすべて理解してから対応する必要はありませんが、どの製品を直す話かは押さえておきましょう。

• CVE-2026-109618：メモリー不足時の処理で内部データが不完全な状態となり、後続の処理でメモリー破損やコード実行につながる問題
• CVE-2026-109619：処理済みのリクエストに属する古い内部状態が残り、後のリクエストで解放済みメモリーを扱ってしまう問題

公式アドバイザリーでは、どちらもCritical、CVSS v4.0の基本スコア9.2とされています。ただし、攻撃の成立条件や実証された経路は同一ではありません。CVE-2026-109618の公式詳細、CVE-2026-109619の公式詳細

PHP-FPMなら安全、という判断はしない

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどを注意対象として挙げています。特にmod_phpでは、アプリケーションのコードが動き始める前に攻撃へ到達する実証があり、リスクが高いと説明されています。

一方で、すべての実行方式・設定で同じ攻撃がそのまま成功すると断定するのも正確ではありません。例えばCVE-2026-109618の詳細では、FPMも影響を受け得るとしつつ、mod_phpと同じ完全な攻撃実証が示されたわけではないと区別されています。

この違いは、優先順位や防御方法を管理者が判断する材料です。「自分のサーバーはFPMだから更新不要」という免除条件ではありません。利用中の方式を確認し、提供元が案内する修正を適用することが必要です。PHP公式勧告、OOM関連の公式アドバイザリー

修正済みバージョンと、古いPHPの扱い

10月21日に公開された、PHPプロジェクトの修正版は次のとおりです。スマートフォンでは表を横にスクロールして確認できます。

確認時点で、上記より新しい正式版が出ている場合は、その版に今回の修正が含まれるかも確認します。PHP 8.2については2026年末のサポート終了も近いため、今回の緊急修正と、その後の移行計画を分けて進めたいところです。PHP公式リリース情報、公式ダウンロード

Linuxディストリビューションやサーバー会社が、元のバージョン番号を大きく変えずに修正を取り込む「バックポート」を行う場合もあります。表示番号だけで適用済み・未適用を決めず、対象CVE、パッケージの版、提供元の告知を照合してください。

古い系列向けにソースの修正が用意されることと、通常のサポートが復活することも別です。古いPHPを使い続ける前提にせず、保守担当と移行条件を確認しましょう。カナダの公的機関による修正版と旧系列の案内

攻撃が成立した場合、どんな被害が考えられるか

リモートコード実行とは、外部の攻撃者が、影響を受けるサーバーで本来許可されないプログラムを動かせる状態です。公式に実証されたコード実行は、Web処理を担うアカウントの権限で行われます。即座にサーバー全体の最高権限を得られる、という意味ではありません。

ただし、Web用の権限であっても、サイトのファイルや設定情報へアクセスできる構成はあります。以下は、この性質から考えられる被害の例です。今回、すべてのサイトでこれらが起きたと確認したという説明ではありません。

• サイトの改ざん：ページの書き換え、不正なリンクや別サイトへの誘導
• 情報の流出：アクセス可能な設定ファイル、保存された問い合わせ、顧客情報などの読み出し
• 継続的な不正アクセス：不審なファイルを設置され、修正後も侵入口が残る
• 不正処理やサービス停止：迷惑メール送信などへの悪用、負荷の増大、サイトの停止

WordPressなら、設定ファイルに含まれるデータベース接続情報を読まれることで、保存データの読み書きにつながる可能性もあります。実際の被害範囲は、ファイルの権限、DBの権限、保存している情報、ネットワーク構成で変わります。

そのため、「画面が普通に見える」「ログイン履歴に異常がない」だけで侵入がないとは判断できません。逆に、PHPを使っているだけで侵害が確定したとも言えません。更新状況の確認と、不審な動きの調査を分けて進めます。コード実行の権限に関する公式説明

レンタルサーバー利用者が、いま確認すること

レンタルサーバーでは、PHP本体の更新は通常、提供会社が管理します。ただし、契約中のサービス、選択しているPHP系列、対象サーバーによって対応範囲が異なる場合があります。「大手だから済んでいるはず」と推測せず、公式のお知らせと契約者向けの案内を確認します。

サポートへ聞く際は、契約情報と対象ドメインに加えて、次の点をまとめると話が進みやすくなります。

1. CVE-2026-109618とCVE-2026-109619は、利用サーバーで対応済みか
2. 選択中のPHP系列にも修正が適用されているか
3. 利用者側でPHPの切り替えや追加操作が必要か
4. 稼働中のWeb処理にも修正が反映され、再起動等が完了しているか
5. 未対応の場合、適用予定と当面の制限方法は何か

管理画面の「PHP 8.3」のような表示だけでは、末尾の修正版や個別パッチまで分からないことがあります。公式の対応情報やサポート回答を保存し、「何を根拠に対応済みと確認したか」を残しておきましょう。

なお、サーバー会社が保守していることと、自分のWordPressや独自システムの動作確認は別です。PHPが切り替わったあとは、問い合わせ、予約、購入など、重要な機能をサイト担当者側でも確認します。

WordPress・VPSの管理者が行う更新前後の確認

WordPressでは、「ツール」→「サイトヘルス」→「情報」のサーバー項目などから、Web側で動いているPHPの情報を確認できます。対象ドメインの情報を記録し、サーバーの管理画面と照合します。

SSHを使う管理者は、CLI側の確認もできます。

php -v

WP-CLIが実行されるPHPを確認する例は次のとおりです。パスは自分の管理対象へ置き換えます。

wp --path=/path/to/wordpress eval 'echo PHP_VERSION, PHP_EOL;'

ただし、この二つの結果はコマンド実行時のPHPです。ブラウザからアクセスしたときのPHP-FPMやApacheモジュールと、同じとは限りません。CLIの表示だけでWeb側の修正完了を判断しないでください。確認用のphpinfoページを公開したまま残す方法も避けます。

更新は、稼働している環境への反映まで確認する

VPSや自社管理サーバーでは、OS・PHP提供元が案内する修正済みパッケージを使います。コンテナなら、イメージを更新するだけでなく、修正版のイメージから実行環境を作り直す必要があります。複数台構成なら、古いPHPを使う処理系が残っていないかも確認します。

更新前には、DB・ファイル・設定のバックアップと復旧手順を確かめます。ただし、緊急修正を通常の更新日まで何日も待つ理由にはしません。必要な確認を絞り、管理担当者が適用と稼働プロセスの再起動・入れ替えを進めます。

同系列の修正版への更新と、8.1から8.4のような系列の移行は、互換性確認の範囲が異なります。番号が大きいものへ切り替えれば終わりと考えず、WordPress・テーマ・プラグイン・独自コードへの影響を確認します。

更新後は、トップページの表示だけでなく、管理画面、フォーム送信と受信、予約や決済、画像アップロード、定期処理、エラーログを点検します。サイトが動いていることと、修正済みPHPで動いていることの両方が完了条件です。

すぐ更新できないとき。WAFやメンテナンス表示だけで安心しない

公式資料には、入力サイズや一部機能を制限する暫定策もあります。しかし、特定の攻撃経路を減らすもので、更新に代わる完全な対処ではないと明記されています。

例えば、CVE-2026-109619ではセッションのアップロード進捗機能などに関する対策が示されていますが、設定する場所やワーカーの再起動も関係します。アプリケーション内で設定を書き換えれば同じ効果になるとは限りません。古い内部状態に関する公式アドバイザリー

また、インターネット上で見かけた対策をそのまま使い、全サイトへメモリー制限解除などを一律に適用することも避けます。メモリー枯渇や停止のリスクを含むため、ホスト全体の制限やアプリの動きを理解した管理者の判断が必要です。

WAFのルールが提供されても、修正版への更新を不要とする根拠にはしません。WordPressのメンテナンス用プラグインもPHP上で動くため、PHPへリクエストが届かなくなったとは限りません。特にアプリの処理前へ到達する経路がある今回の問題では、画面をメンテナンス表示にしただけで隔離完了と考えないことが重要です。

更新までの公開継続が難しい場合は、Webサーバー・リバースプロキシ・ネットワーク側でのアクセス制限や、一時的な公開停止を管理者と検討します。英国NCSCも、すぐに修正できない組織には、一時的なオフライン化の検討を勧めています。NCSCの注意喚起

不審なファイルや通信がある場合は、更新だけで終えない

PHPを更新しても、すでに置かれた不正ファイルや盗まれた認証情報が自動で消えるわけではありません。更新は侵入口を修正する作業であり、侵入後の復旧とは別です。

見覚えのないファイル、意図しないページ変更、不審な外向き通信、Web処理からの異常なプロセス実行、知らないアカウントなどがあれば、サーバー会社や保守担当へ連絡します。アクセスログ、エラーログ、操作記録と、発見日時を保全し、調査に必要な証拠を失わないようにします。

怪しいファイルをすぐ全部削除したり、理由が分からないままバックアップで上書きしたりすると、侵入経路や影響範囲を追いにくくなります。公開制限、証拠保全、侵害範囲の確認、信頼できる環境からの復旧、認証情報の見直しを、担当者と順番に進めます。

認証情報を変更する場合も、侵入が続く環境で変更して再び読まれることがないよう、封じ込めと合わせて計画します。個人情報への影響が疑われるなら、何が外部からアクセスできたかを調べ、社内の事故対応体制で報告・相談の要否を判断します。カナダ当局の監視・調査に関する推奨事項

まず「修正を確認できたか」を明確にする

今回の注意喚起で、サイト担当者が最初に必要なのは、不安をあおる見出しを読み続けることより、利用中のPHPと対応担当を特定することです。

• 対象ドメインと、実際にWeb処理をしているPHPを確認する
• 修正版または提供元の修正済みパッケージへの適用状況を確認する
• 更新後のプロセス入れ替えと、重要機能の動作を確かめる
• 更新できない間の公開方法を管理者と決める
• 不審な動きがあれば、更新とは別に侵害の調査を進める

PHP本体の保守とWordPressの保守を、どちらか一方で済ませないことが大切です。制作会社とサーバー会社で担当が分かれている場合も、誰が修正状況を確認し、誰がサイトの機能を点検するかを決め、記録を残しましょう。

本記事は2026年10月22日時点の情報です。脆弱性の評価、攻撃の確認状況、各サーバー会社の対応は更新されるため、作業時にはPHP公式と契約先の最新案内を確認してください。本記事に、特定の契約サーバーが修正済みであることの確認結果は含みません。