PHPの脆弱性「php2shell」とWordPressへの影響｜発見の経緯とサイトヘルスでの確認手順【2026年10月】
2026年10月21日、PHPの開発プロジェクトが2件の重大な脆弱性を修正した緊急アップデートを公開しました。発見者が付けた「php2shell」という通称でニュースにもなっているので、目にした方も多いと思います。高市総理大臣まで対策を呼びかけるほどのことだったので例のない出来事だったと思います。
私はウェブサイト作成やワードプレスのトラブル解決、SEO対策など、日々ワードプレスのサイトに関わるような立場なので日々ワードプレスのサイトに関わる立場なので、クライアント様や関わりのある方などから昨日から今日にかけてで色々なご相談や心配事などのご連絡を受けました。
結論から書くと、これはWordPress側では防げない種類の問題で、対処はレンタルサーバー会社が行います。ただし自分のサイトが今どの状態にあるかは管理画面から確認できますし、使っているPHPのバージョンによっては、サーバー会社が対応しても安全にならないケースがあります。
この記事では、WordPressサイトを運営・ご支援している立場から、確認すべきことと今やれることを整理します。
PHPの脆弱性「php2shell」の概要と修正版バージョン
PHPプロジェクトは10月21日、認証なしでリモートからコードを実行される（RCE）おそれのある脆弱性2件を修正したセキュリティリリースを公開しました。CVE-2026-109618とCVE-2026-109619で、深刻度はCVSS v4.0でいずれも9.2です。
修正版は次のとおりです。
| 使用中のPHP | 修正版 |
|---|---|
| 8.5系 | 8.5.12 |
| 8.4系 | 8.4.27 |
| 8.3系 | 8.3.36 |
| 8.2系 | 8.2.35 |
| 8.1系以下 | 修正版なし（サポート終了のため） |
修正版というのは、脆弱性という弱点の穴がふさがれたバージョンということです。つまり、このバージョンが適用されている場合であれば本件については対応済みになっているという認識で差し支えないかと思います。
PHPの公式アドバイザリは、完全な緩和策は存在せず、更新することだけが安全な選択だと明言しています。
WordPressのアップデートでphp2shellを防げない理由
今回いちばん押さえておきたいのは、2件の脆弱性がPHPのリクエストを解析するC言語の層にあるという点です。WordPressのPHPコードが動き出すより前の段階にあたります。
そのため、WordPress本体を最新にしても、プラグインをすべて更新しても、セキュリティプラグインを入れても、この部分には手が届きません。サーバー上で動いているPHPそのものが差し替わらないかぎり、状況は変わりません。
GMO Flatt Securityの解説によると、攻撃にはPHPのSession Upload Progress機能（ext/session）が既知の経路のひとつとして使われます。この機能はデフォルトで有効です。
php2shellの影響範囲とPHP 5.x・7.x系の扱い
GitHubのアドバイザリが明示的に「脆弱」としているのは8.2から8.5の各ブランチです。それより古いバージョンについて、PHPは影響を受けるバージョンの一覧を公表していません。
一方で、脆弱性の起源はPHP 5.2系または5.4系までさかのぼると見られており、GMO Flatt SecurityはPHP 5.x、7.x、8.x（修正版を除く）に広く影響すると考えておくべきとしています。古いから対象外なのではなく、古いから修正版が来ないというのが実態です。
php2shellが緊急アップデートになった経緯とAIによる発見
今回は、脆弱性の内容そのものより、公開に至るまでの経緯に特徴があります。背景を知っておくと、なぜこれほど急いで対応が呼びかけられたのかが分かります。
php2shellを発見したのはAIを使った研究者チーム
最初に遠隔コード実行につながる経路を見つけたのは、Califの研究者ライアン・オースティン氏らです。2004年にステファン・エッサー氏が報告したメモリ上限に関する脆弱性がまだ残っているのではないかと仮定し、AIへの問いを重ねて数日で経路にたどり着いたとされています。一般には使えない特別なモデルを使ったわけではないと説明されています。
同じ8月11日に、OpenAIも独立して同じ問題をPHPに報告しました。さらにWizが8月下旬に2件目を独立して報告しています。修正後には、Chainguardが自社のツールとAIモデルで同じ欠陥を再現したと公表しました。
AIを使った脆弱性調査が、広く使われている基盤ソフトウェアの深刻な穴を実際に掘り当てた事例になります。
php2shell発見から修正版公開までの時系列
| 時期 | 出来事 |
|---|---|
| 2004年 | エッサー氏が、メモリ上限に関わる初期のPHP脆弱性を報告 |
| 2026年8月1日 | Califが遠隔コード実行につながる経路を発見 |
| 8月11日 | CalifとOpenAIがそれぞれPHPに報告。PHPのメンテナーはこの日から修正を最優先に据える |
| 8月下旬 | Wizが2件目を独立して報告 |
| 10月20日15時ごろ | CVE番号がSNSなどに流出 |
| 10月20日19時30分 | PHPが、公開日を10月22日から21日に繰り上げると告知 |
| 10月20日20時ごろ | Califが攻撃の実演動画を誤って公開。削除されたが複製が拡散 |
| 10月21日3時02分 | Cloudflareが、修正版の公開前にWAFのルールを稼働 |
| 10月21日14時ごろ | 修正版（8.5.12など）を公開 |
時刻はいずれも協定世界時（UTC）です。日本時間では9時間後にあたります。
CVE番号の流出でphp2shellの公開が1日前倒しに
報告から修正、公開までは、関係者の内側で進める協調開示の形が取られていました。PHP Foundationは8月11日から修正を最優先に据え、財団の資金で複数の人が専任で取り組める体制を作ったと説明しています。
ところが10月20日、CVE番号が掲示板やSNSに出回りました。技術的な詳細は含まれていませんでしたが、誤った深刻度と誤った公開時刻が添えられていました。最初の流出元は公表されていません。
これを受けて、PHPは当初10月22日としていた公開日を1日繰り上げました。攻撃者による悪用が見つかったからではなく、番号が先に出回ったことが理由です。
修正版の公開は、穴の場所を教えることでもある
修正版を公開するということは、修正前と修正後のコードの差分を誰でも見られるようになるということでもあります。攻撃する側は、その差分からどこにどんな穴があったのかを逆算できます。
つまり、修正版が出た瞬間から、更新していないサーバーは穴の場所が公開されたまま放置されている状態になります。PHPが「全員いますぐ更新してください」と強い調子で呼びかけたのは、このためです。全員が同時に切り替えてはじめて、この構図が解消されます。
実際、Cloudflareは修正版の公開前にWAFのルールを稼働させ、Chainguardは修正入りのイメージを予定より6時間以上早く公開しました。防御する側も、公開の瞬間に備えて動いていたことになります。
私がメインで使っている エックスサーバー様も、公開より前の早い段階から独自のセキュリティ対策を考えたり動いてくれていましたので、見えないところで頑張ってくださっているエンジニア様企業様には頭が下がります。
エックスサーバー様 2026年10月22日 9時20分時点
サイトヘルスでPHPバージョンを確認する手順
WordPressの管理画面から、いま動いているPHPのバージョンを確認できます。サーバーパネルのPHP切替画面は系統（8.2系など）の表示にとどまることがあるのに対し、サイトヘルスは実際に動いているバージョンを数字で出してくれるので、確認にはこちらが向いています。
PHPバージョンごとの判定基準
表示された数字で、次のように判断できます。
| 表示された数字 | 状態 |
|---|---|
| 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 と同じか、それより新しい | 今回の脆弱性がふさがれたバージョンです |
| 8.2系〜8.5系だが上記より古い | サーバー会社の対応がまだ届いていない状態です |
| 8.1以下 | 修正版そのものが提供されません（次の項目へ） |
PHP 8.1以下の場合の対応とバージョン切り替えの注意点
PHP 8.1はすでにサポートが終了しており、今回の修正版は出ていません。サーバー会社がいくら対応しても、その系統を使い続けるかぎり穴はふさがりません。
この場合は、サポートが継続している8.2系以降への切り替えが必要です。エックスサーバーをはじめ主要なレンタルサーバーでは、管理画面からPHPのバージョンを変更できます。
ただし、PHPのバージョンを上げると、古いテーマやプラグインが動かなくなることがあります。切り替えの前に必ずバックアップを取り、できればステージング環境で確認してから本番に反映してください。いきなり本番で切り替えた結果、画面が真っ白になるケースはよくあります。
レンタルサーバー各社のphp2shell対応状況
以下は2026年10月22日時点で確認できた範囲です。各社の告知は停止の理由にPHPを名指ししていないものも多く、状況は時間単位で変わります。最新の情報は必ず各社の公式のお知らせを確認してください。
| サーバー | 確認できた動き |
|---|---|
| エックスサーバー | 10月21日16時ごろから、サービスサイトとアカウント管理画面、新規申し込みや契約更新、支払いを一時停止。利用者のサーバーでのサイト表示とメール送受信は継続。その後、対応済みの案内が出ています |
| さくらのレンタルサーバ | 10月21日22時30分に一部ホストで完了。残りは順次 |
| バリューサーバー | 10月22日0時50分に全サーバーの更新が完了 |
| mixhost | 10月21日18時ごろにikサーバー全台で完了 |
| カラフルボックス | 10月22日1時55分時点で一部完了 |
| ConoHa WING | 10月22日10時まで保守作業 |
| ロリポップ、ヘテムル | 予防措置として緊急メンテナンスを実施 |
| KAGOYA | PHP 8.2〜8.5は順次更新。他プランは方針を調整中 |
| Zenlogic（IDCフロンティア） | PHPの更新とパッチ適用を実施 |
完了を明示していない会社も多く、告知にPHPと書いていない会社もあります。そのため、この表は「動きがあったかどうか」の目安として見てください。自分のサイトが実際にどうなっているかは、サイトヘルスの数字で確かめるのが確実です。
なお、管理画面が停止している間はPHPのバージョン切り替え操作もできません。8.1以下を使っている方は、管理画面が復旧してからの作業になります。
レンタルサーバーではありませんが、KUSANAGI（GMOプライム・ストラテジー）も10月22日未明に8.2系から8.5系の修正パッケージを公開し、緊急アップデートの実施を告知しています。PHP 8.1以前の修正版は出ていません。
php2shellの悪用状況とCISA・NSAの注意喚起
GMO Flatt Securityは、悪用できると主張するコードがすでにインターネット上に出回り始めていると指摘しています。前述のとおり、実演動画が誤って公開され、削除後も複製が拡散した経緯もありました。
米国のCISAは「Critical Vulnerabilities in PHP Require Immediate Patching」として即時のパッチ適用を強く促しており、公開時点では悪用を観測していないとしていました。NSAも、即時の更新が難しい場合はシステムをオフラインにすることを推奨しています。
レンタルサーバーを使っているWordPressサイトの場合、自分で止めたり更新したりする選択肢はありません。だからこそ、サーバー会社の対応が自分のサイトに届いているかを数字で確認する意味があります。
メモリ漏えいへの備えとパスワード・APIキーの見直し
2件のうちCVE-2026-109619には、リモートコード実行に至らなくても、他のリクエストが使っていたメモリの内容を読み出せてしまうという影響があります。パスワード、認証トークン、APIキー、証明書などが対象です。PHPの公式アドバイザリも、メモリの開示を確定した影響として挙げています。
会員情報や決済情報を扱っているサイト、外部サービスのAPIキーをサイト内に保存しているサイトでは、修正版への切り替えを確認したあとで、次のような対応を検討しておくと安心です。
一般的なブログやコーポレートサイトであれば、ここまで神経質になる必要はありません。扱っている情報の重さで判断してください。
WordPressサイトの日頃のセキュリティ対策
PHP本体の問題は、どうしてもサーバー会社の対応を待つほかありません。それでも、日頃の運用でできることはあります。
- PHPのバージョンをサポート期間内に保つ。今回のように、修正版が来るかどうかはここで決まります
- WordPress本体、テーマ、プラグインを最新に保つ。今回は無関係でしたが、WordPress側の脆弱性には有効です
- 定期的にバックアップを取る。何かあったときに元に戻せる状態を作っておくことが、結局いちばん効きます
- 契約しているサーバー会社の公式X（旧Twitter）をフォローしておく。今回、エックスサーバーの第一報はニュース欄ではなく公式Xでした
まとめ
今回のphp2shellは、WordPressユーザーにとって、自分では直せないが放置もできないタイプの問題です。やることは多くありません。
サーバー会社の対応は進んでいますが、完了の告知が出ていない会社もあります。数字を自分の目で見るところまでやっておくと、余計な心配をせずに済みます。
AIが色々なことをできるようなレベルに進化しており、今の時代どんなことが起きるか想像もできないような状況です。PHPの脆弱性についても、おそらく AI がなければ発見されなかったようなものだと思います。
今回はこのように開発元がセキュリティ対策をしたバージョンを公開し、それをサーバー会社が早急に適用するという形でなんとか今のところ大きなトラブルが発生することなく経過しているように見えますが、悪いことを考えている人がAIを駆使して先に弱いところを見つけてしまうことも今後十分あり得ます。
私は今後もコンテンツを更新していくサイトについてはワードプレスを使っていく予定ですが、あまり更新をせず静的なサイトで特に問題ないサイトについては、サイトの作り方自体を最適な形にしていきたいと考えています。一昔前であれば HTML で1から作っていましたので、複雑なシステムを使うよりもシンプルに戻っていくようなイメージです。このようなご相談も受け付けておりますので、気になった方はお問い合わせくださいね。
アドセンスの審査が心配な方、落ちてしまう方へ。30サイト以上アドセンス審査で合格している筆者が、Googleアドセンスの審査について、公式ポリシーをベースにした対策とチェックリスト33項目をnoteにまとめています。
→ Googleアドセンス審査に通るための本当のことを話します（note）
WordPressの設定・サイト診断のご相談はこちらから。
→ ワードプレスプラクティス（coconala）
WordPressのトラブル対応について、原因別の対処手順をまとめたマニュアルをnoteにまとめています。
→ WordPressが突然表示されなくなった…原因別・完全対処マニュアル（note）
自分での対応が難しい場合は、ココナラのサポートサービスもご利用いただけます。
→ ワードプレスプラクティス（coconala）