PHPの重大脆弱性 (通称「php2shell」)、結局なにが怖い？ うちのサイトは関係ある？——WordPress運用者のための判定と根本対策

本稿は2026年10月21日18時（日本時間）時点の情報をもとにしています。PHPの修正版は同日23:00（日本時間）に公開予定で、影響バージョンなどはその時点で公式に発表されます。公開前に最新情報へ差し替えます。

2026年10月21日未明（日本時間）、PHPのセキュリティチームが「重大な脆弱性2件を修正するセキュリティリリースを予定している」と事前に告知しました。深刻度はどちらもCVSS v4.0で9.2（Critical）です（出典：PHP公式アナウンス）。

X（旧Twitter）では「ヤバい」「HPがワードプレスだとアウト？」といった声が一気に増えました。この記事では、WordPressでサイトを運用している方に向けて、次の3点を順に整理します。

• いまわかっていること、まだわかっていないこと
• 何が怖いのか、自分たちのサイトは関係あるのか
• 今回をしのいだあとにどうするか（脱WordPressという選択肢と、移行で変わること）

今回のPHP脆弱性、わかっていること・わかっていないこと

公式に発表されていること

PHP公式が発表している内容は、いまのところ次のとおりです（出典：php.announce、php.net 2026年ニュース）。

• 重大な脆弱性が2件あり、深刻度はいずれもCVSS v4.0で9.2（Critical）
• 修正版のリリースは2026年10月21日14:00 UTC、日本時間では10月21日23:00の予定
• 詳細が先に漏れた場合や悪用が確認された場合は、前倒しになることがある

IPA（情報処理推進機構）も、リリースに備えて準備をするよう呼びかけています（出典：IPA）。IPAは10月21日時点で「攻撃は確認していない」としています。

なお、10月21日17:40時点で php.net に掲載されている最新版は 8.5.11 / 8.4.26 / 8.3.35 / 8.2.34 です（出典：php.net）。今夜の修正版は、これより新しいバージョンになるはずです。

報道やリーク情報

公式発表のほかに、さまざまな情報が出回っています。まだどれもPHP公式は確認していません。

• 欧州のCERT-EUは、認証なしで遠隔からコードを実行される（RCE）可能性があること、影響が「PHP 5以降」に及ぶことを記載しています。ただしリーク情報をもとにした記述です（出典：CERT-EU）。
• 修正版のバージョン番号や原因について報じている海外メディアもありますが、公式発表ではありません。
• 研究者のX投稿で「php2shell」という呼び名が使われ（投稿）、国内でも広がっています。ただ、この呼び名が今回の2件を指すとPHP公式が認めたわけではありません。
• 海外では「PoC（攻撃を再現するコード）が公開された」「すでに悪用されている」という主張もありますが、裏付けはとれていません。

本稿ではこうした情報を前提にせず、公式発表を待つ立場で書いています。

9月・7月のWordPressの脆弱性とは別の話

ここ数か月、WordPress関連の脆弱性が続いたため、話が混ざりやすくなっています。

• 7月の「wp2shell」：WordPress本体（6.9.0〜6.9.4、7.0.0〜7.0.1）の脆弱性で、認証なしのRCEにつながるものでした。修正版は 7.0.2 / 6.9.5 です（出典：発見者Searchlight Cyberの記事、CIS）。
• 9月のCVE-2026-87902：WordPress本体のページテンプレート処理の脆弱性で、悪用も確認されています（出典：JPCERT/CC Weekly Report）。

これらはWordPressの更新で直すものでした。今回はWordPressを動かしているPHPそのものの問題です。WordPressを最新にしていても、PHP側が影響を受けるバージョンなら関係してきます。

結局、なにが怖いのか

「認証なしの遠隔コード実行」をかみくだくと

報道どおりの内容だった場合、いちばん怖いのは「ログインしなくても、外からサーバーにプログラムを実行させられる」可能性です。サーバーの鍵を持っていない人が、ドアを開けずに中で好きな作業をできる、というイメージに近いかもしれません。

繰り返しますが、内容はまだ公式に確認されていません。ただ、PHP公式がわざわざリリースを予告していることや、深刻度が9.2とされていることから、各所が警戒を強めているのは確かです。

もうひとつ知っておきたいのは、修正版が出た直後の数日です。修正内容が公開されると、攻撃する側も差分を見て「どこが弱かったのか」を探しにきます。一般に、パッチ公開から攻撃が始まるまでの時間は短くなる傾向があると言われます。修正版が出たら早めに適用する、というのが基本の対応です。

起こりうる被害

ここからは一般論です。今回これらの被害が確認されたという話ではありません。サーバー上でプログラムを実行されると、次のようなことが起こり得ます。

• 改ざん：トップページが書き換えられる、知らないページが追加される
• 不正リダイレクト：訪問者が詐欺サイトやマルウェア配布サイトへ飛ばされる
• 情報漏えい：問い合わせフォームの内容や会員情報、データベースの中身が抜き取られる
• 乗っ取り・踏み台化：サーバーが迷惑メールの送信や、ほかのサイトへの攻撃に使われる

被害はサイトの中だけでは終わりません。検索結果やブラウザに警告が出て訪問者が減る、取引先や顧客へ説明しなければならなくなる、復旧に時間と費用がかかる、といった二次被害も考えておく必要があります。

自分たちは関係あるのか：5つの質問で確認

チェックリスト

次の5つの質問に答えると、自分たちの立ち位置が見えてきます。

1. PHPを使っていますか？ WordPressはPHPで動いています。WordPress以外にも、EC-CUBE、自社開発のシステム、PHPで書かれた問い合わせフォームなども対象です。社内の管理画面やツールも見落とさないようにしてください。
2. PHPのバージョンはいくつですか？ WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。どのバージョンが影響を受けるかは【要確認：PHP公式の影響バージョン】です。今のうちに数字だけ控えておきましょう。
3. PHP 8.1以前を使っていませんか？ 8.1以前はすでにサポートが終わっています。今回修正版が出るかどうかは【要確認：EOLバージョンの扱い】ですが、出ない場合は8.2以降への更新が必要です。プラグインやテーマが新しいPHPで動くかの確認も要ります。
4. サーバーはレンタルサーバーですか、自社で管理していますか？ レンタルサーバーならPHP本体の更新は基本的に事業者が行います。自社管理（VPSやクラウド）なら自分たちで更新します。
5. すぐに動ける担当者や保守契約はありますか？ 「誰が、いつ対応するか」が決まっていなければ、今日のうちに決めておくのがいちばん効く準備です。

判定の目安は次のとおりです。

• PHPを使っていない → 今回は関係ありません
• レンタルサーバーで、PHP 8.2以降 → 事業者の告知を確認し、案内に従う
• 自社管理のサーバー → 修正版が出たら速やかに更新する手順と担当を決めておく
• PHP 8.1以前 → 今回の修正版で対応できない可能性があるので、バージョンアップの計画を立てる

具体的な更新手順は、各レンタルサーバー事業者や、PHP・IPAの公式情報を参照してください。

レンタルサーバーを使っている場合

Xで多かったのが「レンタルサーバーだから会社次第」「今は何もできない」という声でした。実際、PHP本体の更新は事業者の作業になるので、利用者側でできることは限られます。そのうえで、次のように整理しておくと落ち着いて動けます。

やること

• 契約している事業者のお知らせやメンテナンス情報を確認する
• サーバーの管理画面（サーバーパネル）にログインできるか確かめておく。ID・パスワードの所在がわからなければ今のうちに探す
• サイトとデータベースのバックアップを取っておく

やらなくていいこと

• 慌ててWAFやphp.iniなどの設定を変えること。設定を変えた結果、サイトが表示されなくなったという報告も出ています。

一部の設定変更で防げるという情報も出回っていますが、それだけでは十分ではないという指摘もあり（出典：GMO Flatt Security Blog）、確実な対策とは言えません。よくわからないまま触るより、公式の修正版と事業者の対応を待つほうが安全です。

参考までに、エックスサーバーは10月19日にPHP 8.2〜8.5を当時の最新版へ更新したと告知しています（出典：エックスサーバー）。

今回をしのいでも、構造は変わらない

今夜の修正版を適用すれば、今回の件はひとまず落ち着くはずです。ただ、ここで一度立ち止まって考えたいことがあります。

WordPressは公開サーバーでPHPが動き続ける仕組み

WordPressは、訪問者がページを開くたびにサーバー上でPHPが動き、データベースから内容を取り出してページを組み立てます。つまり、インターネットに公開されたサーバーで、常にプログラムが動いている状態です。

そのため、攻撃を受けうる場所が何層にも重なっています。

• PHP本体（今回の件）
• WordPress本体（7月のwp2shell、9月のCVE-2026-87902）
• プラグイン
• テーマ

脆弱性は繰り返し見つかっている

セキュリティ企業Patchstackの調査では、2025年にWordPressの周辺（本体・プラグイン・テーマ）で新たに見つかった脆弱性は11,334件で、前年より42%増えました。そのうち91%がプラグイン、9%がテーマで、本体は6件でした（出典：Patchstack「State of WordPress Security in 2026」）。公的な統計ではなく一企業の調査ですが、傾向をつかむ参考にはなります。

今年だけでも、7月にWordPress本体のwp2shell、9月にCVE-2026-87902、そして今回のPHPと続きました。どれか一つが特別だったというより、こうしたことが今後も起こる前提で考えたほうが現実的です。

更新の負担と「待つしかない」不安

脆弱性が出るたびに、更新して、表示崩れがないか確かめて、プラグインの相性を見る。この作業を誰かが担い続ける必要があります。

レンタルサーバーなら、今回のように事業者の対応を待つしかない場面もあります。「自分たちではどうにもできない時間」があること自体が、運用上の不安になっています。

根本解決の選択肢：ヘッドレスCMS（Jamstack）

こうした構造そのものを変える選択肢のひとつが、ヘッドレスCMSです。国内ではmicroCMSなどのサービスがあります。

仕組み：編集はCMS、公開サイトは静的に配信

ヘッドレスCMSでは、「記事を書いて管理する場所」と「訪問者が見るサイト」を分けます。

• 記事の編集や管理は、CMS（microCMSなどのクラウドサービス）の管理画面で行う
• 公開サイトは、記事データをもとにあらかじめHTMLを生成しておき、配信サービスから届ける

この構成なら、訪問者がアクセスするサーバーでPHPやデータベースが動きません。今回のようなPHP本体の脆弱性や、WordPressのプラグインの脆弱性を、公開サイトが直接受けることはなくなります。

WordPressとの比較

表示速度の目安として、GoogleはCore Web Vitalsの「良好」の基準を、LCP 2.5秒以内、INP 200ミリ秒以下、CLS 0.1以下（いずれも75パーセンタイルで評価）としています（出典：web.dev）。ヘッドレス化すれば必ずこの基準を満たせるわけではなく、実際に測って確かめる必要があります。

なお、移行にあたっては、サイトの作り直しにともなう初期費用と移行の手間がかかります。また、公開サイト側のフロントエンドを実装し、移行後も保守・運用していく体制が新たに必要になります。

脱WordPressを決める判断基準と移行の進め方

判断チェックリスト

次の項目に多く当てはまるほど、ヘッドレスCMSへ移行したときの効果を得やすくなります。

• サイトの中心が、記事・お知らせ・事例紹介などの情報発信である
• 会員、EC、予約などのサーバー側の機能が少ない、または外部サービスで代替できる
• プラグインの更新や動作確認が負担になっている
• 表示速度に課題があり、改善したい
• 移行の費用と期間を確保できる
• 移行後にフロントエンドを保守する人（社内または外部）を決められる (弊社でも対応可能です)

移行の進め方（概要）

おおまかな流れは次のとおりです。

1. 現状調査：ページ数、記事数、使っているプラグインと機能、アクセスの多いページを洗い出す
2. CMSの選定：編集画面の使い勝手、料金、権限管理、サポートを比べる
3. URL設計とリダイレクト：今のURLをできるだけ保ち、変わるものはリダイレクトを設定する
4. 構築：デザインと機能を作り、フォームや検索などの代替手段を用意する
5. データ移行と検証：記事や画像を移し、表示崩れやリンク切れを確認する
6. 公開と監視：切り替え後、検索エンジンへの反映やエラーを見守る

もし移行に関する調査や判断でお困りでしたら、ぜひお気軽にご相談ください。

まとめ：今やることと、その先の判断

取り急ぎ対応すること

• PHPを使っているサイトやツールを洗い出し、PHPのバージョンを控える
• レンタルサーバーなら、事業者のお知らせを確認し、管理画面に入れるか確かめる
• バックアップを取り、対応する担当者を決める
• よくわからない設定変更はしない
• 影響バージョン (PHP公式の影響バージョンを要確認) に当てはまるか確認する
• 修正版 (PHP公式の影響バージョンを要確認) への更新を、事業者の告知や自社の手順に沿って進める

落ち着いたら考えること

今回をしのいでも、公開サーバーでPHPが動き続ける構造は変わりません。「いつかは」と思っていた脱WordPressを検討する時期かどうか、この機会に判断材料を並べてみてください。すぐに移行しない場合も、WordPressのまま更新の担当や手順を決めておくだけで、次の脆弱性への備えになります。

TamaTでは、WordPressからmicroCMSなどのヘッドレスCMSへの移行をお手伝いしています。判断に迷ったときは、お気軽にご相談ください。