php2shell｜PHP本体の重大脆弱性。WordPressの更新では直らない。PHPバージョンの確認方法とレンタルサーバー各社の状況
2026年10月21日の夜、国内のレンタルサーバー各社が相次いで緊急メンテナンスに入り、ショッピングサイトや業務サービスが一時停止しました。原因は、WordPressではなく、その土台であるPHP本体に見つかった2件の重大な脆弱性「php2shell」です。この記事では、何が起きたのか、自分のサイトが対象かを確認する方法、レンタルサーバー各社の状況、そして「PHPを上げると壊れる」サイトが取るべき手順を、サイトを運営している方の目線で順に説明します。
10月23日 追記（1日後の状況）
- エックスサーバーは旧版（7.4〜8.1、5.6〜7.3）にも独自修正の適用を完了したと公式に発表しました（22日12時と14時）。当社の保守サーバーでも、旧版の修正済みビルドが22日午前に配備されていることを確認しました。5.5 以下はまだ「作成・検証中」です。
- 公式サイト・管理画面・API は再開しています（管理画面は22日9時30分以降、サービスサイトは22日20時10分以降）。サーバーパネルと支払い関連の一部機能はメンテナンス中です。
- ただし、修正が入っても管理画面に表示されるバージョン番号は変わりません（7.4.33 のまま）。「数字が古いから未修正」とも「数字が新しいから安全」とも言い切れないので、判断はサーバー会社の告知で行ってください。
3行で要点
- WordPressやプラグインを更新しても直りません。PHPそのものを修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上）に切り替える必要があります。
- PHP 8.1 以前には公式の修正版が出ません。7.4 や 8.0、8.1 のままのサイトは、サポート中の系列へ移るか、サーバー会社の独自修正を待つしかありません。
- まず、自分のサイトのPHPバージョンを確認してください。WordPressの管理画面で1分で分かります（確認方法はこちら）。
何が起きたのか
PHPは、WordPressをはじめ世界のウェブサイトの約7割を動かしているプログラミング言語です。その本体（インタプリタ）に、ログインしていない第三者がサーバー上で任意のコードを実行できてしまう脆弱性が2件見つかりました。2件をまとめて「php2shell」と呼ばれています（発見した Wiz の解説記事でもこの名称が使われています）。
深刻なのは、特定のプラグインやテーマの問題ではなく、PHPでウェブリクエストを処理しているサーバーすべてが対象という点です。PHP-FPM、Apache の mod_php、php-cgi、LiteSpeed など、動かし方を問いません。だからこそ、WordPress側の更新では直らず、サーバー会社が一斉にメンテナンスに入ることになりました。
| CVE番号 | CVE-2026-109618（メモリ不足時の処理の不備）／CVE-2026-109619（前のリクエストの状態が残る不備） |
|---|---|
| 深刻度 | どちらも CVSS 4.0 で 9.2（Critical） |
| できること | 認証なしで、ウェブサーバーの権限で任意のコードを実行 |
| 対象 | 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 より前のすべてのPHP。Wiz によれば、過去10年に出たバージョンはいずれかの影響を受ける（5.4 まで遡る） |
| 修正版 | 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12（2026年10月21日・日本時間23時頃） |
| 8.1 以前 | 公式の修正版なし。7.4 / 8.0 / 8.1 向けにソースコードのパッチのみ提供（自分でビルドする人向け） |
| 報告者 | Wiz の研究者ほか（公式アドバイザリの Credits: sagitzadik-wiz、tomash-areion、lcfr-hax、amyb-oai） |
日本時間で見た経緯
- 8月19日: Wiz の研究者がAIを使った解析で脆弱性を発見し、8月24日にPHPのセキュリティチームへ報告（公式アドバイザリには Wiz 以外の研究者も報告者として並んでおり、同じ根本原因を先に報告していたとする整理もあります）
- 10月17日: Amazon のハニーポット網が攻撃の試行を観測（公開の4日前。Tenable の FAQ より）
- 10月21日 早朝: PHP公式が「同日に重大な修正版を出す」と事前告知（日本時間5時32分）。IPA も同日付で事前準備を呼びかけ
- 10月21日 12時頃: 脆弱性の詳細が事前に漏れていたため、Cloudflare が公開前に防御ルールを展開（UTC 3:02）
- 10月21日 16時: エックスサーバーが予防措置として公式サイト・管理画面・API を停止
- 10月21日 午後: コドモン（14時頃）、BASE（15時50分）など国内サービスの一時停止が始まる
- 10月21日 19時: ConoHa WING が緊急メンテナンス開始
- 10月21日 23時頃: 修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が公開（23時前にアドバイザリと CVE の情報が先に出て、GitHub 上のリリースは 23時07分）
- 10月21日 23時〜22日 6時30分: さくらインターネットがPHPバージョンアップのメンテナンス
- 10月22日 1時10分〜6時45分: エックスサーバーが 8.2〜8.5 系の全サーバーに修正を適用
- 10月22日 9時30分: エックスサーバーがアカウント管理画面と各種機能を順次再開
- 10月22日 12時: エックスサーバーが PHP 7.4〜8.1 への独自修正の適用を完了
- 10月22日 14時: エックスサーバーが PHP 5.6〜7.3 への独自修正の適用を完了（5.5 以下は作成・検証中）
- 10月22日: IPA と JPCERT/CC が注意喚起を公開
- 10月22日 20時10分: エックスサーバーが各種サービスサイトを順次再開
技術的には何が壊れていたのか（ざっくり）
PHPは1つのプロセス（ワーカー）で、たくさんのリクエストを順番に処理します。今回の2件はどちらも、あるリクエストの処理が途中で異常終了したときに、片付けが不完全なまま次のリクエストに移ってしまう問題です。
- CVE-2026-109618: メモリ不足（OOM）でリクエストが中断されると、まだ初期化が終わっていないデータを、後始末の処理が「正しいデータ」として扱ってしまう。攻撃者は、細工したフォーム送信（multipart リクエスト）でわざとメモリ不足を起こせます。
- CVE-2026-109619: リクエストに紐づく内部の状態が、メモリを解放した後も残り、同じワーカーが処理する次のリクエストが、初期化される前にその古い状態を使ってしまう。
どちらも「ログイン不要」「アプリケーションのコードが動く前の段階」で成立します。なお、公式の評価では攻撃の複雑さは「高」、前提条件「あり」とされており、誰でも簡単に、というものではありません。ただ、動作する攻撃コードの存在は PHP 側も認めており、実際の攻撃の試行は複数の事業者が観測しています。
自分のサイトは対象か — 対象バージョンと修正版
| お使いの系列 | 対象 | 修正版 | 備考 |
|---|---|---|---|
| PHP 8.5 | 8.5.11 以前 | 8.5.12 | |
| PHP 8.4 | 8.4.26 以前 | 8.4.27 | |
| PHP 8.3 | 8.3.35 以前 | 8.3.36 | レンタルサーバーで最も多い系列 |
| PHP 8.2 | 8.2.34 以前 | 8.2.35 | |
| PHP 8.1 / 8.0 / 7.4 | すべて | 公式の修正版なし | ソースコードのパッチのみ。レンタルサーバーが独自に修正を当てるかどうかは各社次第 |
| PHP 7.3 以前 | すべて | なし | サポート終了から長く、今回以外の既知の脆弱性も多数残っています |
ポイントは、「8.3 を使っているから大丈夫」ではなく「8.3.36 以上かどうか」です。同じ8.3系でも、8.3.35 以前は対象です。
自分のサイトのPHPバージョンを確認する方法
「WordPressのバージョン」と「PHPのバージョン」は別物です。WordPressの管理画面で両方見られます。
方法1: WordPressの管理画面で確認する（1分）
- WordPressの管理画面にログインします
- 左メニューの「ツール」→「サイトヘルス」を開きます
- 上のタブで「情報」を選びます
- 「サーバー」の項目を開くと、「PHPバージョン」が表示されます
ここに出た数字を、上の表と見比べてください。8.3.36、8.2.35、8.4.27、8.5.12 以上であれば修正版です。
方法2: レンタルサーバーの管理画面で確認・切り替える
切り替えもここで行います。画面の名称は2026年10月時点のものです。
| サーバー | 確認・切り替えの場所 |
|---|---|
| エックスサーバー | サーバーパネル →「PHP Ver.切替」→ ドメインを選ぶと現在のバージョンが表示されます。※10月22日14時20分時点ではログイン画面が停止ページになっていましたが、23日時点で管理画面は再開しています（サーバーパネルの一部機能はメンテナンス中） |
| さくらのレンタルサーバ | コントロールパネル →「スクリプト設定」→「言語バージョン設定」。PHPの設定はドメイン単位ではなく、契約（アカウント）単位です |
| ロリポップ！ | ユーザー専用ページ →「PHP設定」。反映に5〜10分かかることがあります |
| ConoHa WING | コントロールパネル →「サイト管理」→「サイト設定」→「応用設定」タブ →「PHP設定」 |
レンタルサーバーでは、「PHP 8.3」のように系列を選ぶ方式が多く、細かい修正版（8.3.36 など）はサーバー会社が裏で差し替えます。この場合、利用者が操作しなくても修正版に切り替わりますが、本当に切り替わったかは方法1で確認するのが確実です。
方法3: WPドックの無料診断で分かること・分からないこと
WPドックの無料診断は、URLを入れるだけで外部からサイトの状態を確認するツールです。今回の件に合わせて、PHPのバージョンが外部に見えているサイト（レスポンスヘッダに PHP のバージョンを出す設定のサーバー）については、修正版かどうかを判定するようにしました。
正直にお伝えすると、PHPのバージョンは外部から見えないのが普通です（見えている方がセキュリティ上は良くない）。エックスサーバーをはじめ多くのレンタルサーバーは隠しています。その場合、無料診断では「外部からは判定できません」とお知らせし、上の確認方法へご案内します。外部から確実に分かるのは WordPress 本体のバージョンまでで、PHP は管理画面で確認する必要があります。
国内レンタルサーバー各社の状況（10月23日 更新）
各社の公式告知をもとにまとめました。告知に書かれていないことは「不明」としています。状況は刻々と変わるので、最終的には各社の公式ページでご確認ください。
| サーバー | 公式告知の内容 | 利用者がやること |
|---|---|---|
| エックスサーバー | 21日16時から予防措置として公式サイト・管理画面・API を停止（不正アクセスが起きたからではない、と明記）。22日1時10分に 8.2〜8.5 系への修正適用を開始し、6時45分に対象全サーバーへの適用完了。旧版も独自修正を適用し、7.4〜8.1 は22日12時、5.6〜7.3 は22日14時に完了と公式に発表（23日に公式告知で確認）。5.5 以下は「修正パッチの作成・検証中」。管理画面は22日9時30分以降、各種サービスサイトは22日20時10分以降に順次再開。サーバーパネルと支払い関連の一部機能はメンテナンス中（23日時点） | 原則として操作不要（旧版も含めて同社側で修正済み）。「ご利用状況によっては追加の対策をお願いする場合がある」との案内があるので、公式告知を引き続き確認する。旧版の人は、これを機に 8.3 への切り替えを検討する |
| さくらのレンタルサーバ | 21日23時から「PHPバージョンアップ」の緊急メンテナンスを実施し、22日6時30分に完了。対象はレンタルサーバ、メールボックス、マネージドサーバなど。「古いPHPをお使いの方は PHP 8.3 をご利用ください」と案内 | 8.2 以降なら操作不要。古い系列の人は PHP 8.3 へ切り替える |
| ロリポップ！ | 21日に「PHPの脆弱性への予防措置」として緊急メンテナンス。サービスサイト、ユーザー専用ページ、API などを順次停止。修正版の適用完了は告知に記載なし（14時時点）。23日時点では告知ページ自体がエラーで開けず、メンテナンス情報の一覧にも PHP に関する件名はないため、続報は確認できていません | ユーザー専用ページが再開したら、PHP設定で現在のバージョンを確認する |
| ConoHa WING | 21日19時〜22日10時に「システムの保守作業」（この告知には PHP への言及なし）。22日に「PHPの脆弱性への弊社対応について」を公開し、利用中のPHPバージョンを維持したまま、同社がセキュリティパッチを適用すると案内。あわせてファイルマネージャー・Webメールの一時停止と、22日12時〜21時の追加メンテナンス（収容ホストの再起動）を告知。23日時点の告知では「パッチの適用を順次進めております」と、完了ではなく進行中の表現 | 原則として操作不要。適用後に方法1でPHPバージョンを確認する |
このほか、KAGOYA（8.2〜8.5 を順次更新）、IDCフロンティア（21日22時からパッチ適用）、mixhost、カラフルボックス、バリューサーバーなども緊急メンテナンスを実施しています。お使いのサーバーが表にない場合は、各社のお知らせページで「PHP」「脆弱性」「メンテナンス」の告知を探してください。
当社が確認したこと（エックスサーバー）
当社はエックスサーバー上で約70サイトのWordPressを保守しています。10月22日の午後と23日の午前に確認した範囲では、次のとおりでした。
- サーバー上には修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）が配備され、「8.3」「8.4」といった系列の指定は修正版を指すようになっていました。10月22日にWordPressが自動で記録したPHPバージョンは、確認できたサイトすべてで 8.3.36 でした。つまり、8.2 以降の系列を使っていれば、利用者が何もしなくても修正版に切り替わっています。
- 一方で、7.4 のまま動いているサイトが1件ありました。古いテーマが原因で PHP 8 に上げられず、そのままになっていたサイトです。この世代には公式の修正版が出ません。23日に再確認したところ、サーバー上の 7.4 / 8.0 / 8.1 は22日午前にビルドし直された修正済みのものに差し替わっていました（エックスサーバーの告知どおり）。ただし、WordPressの管理画面に表示されるバージョンは 7.4.33 のままで、数字からは修正の有無を区別できません。
- 独自修正はあくまで「今回の2件の穴をふさぐ」ものです。7.4 / 8.0 / 8.1 はPHP公式のサポートが終わっており、次に脆弱性が出たときも同じことが起きます。いま旧版を使っている方は、これを機に 8.3 への切り替えを計画してください。
- 10月22日から23日にかけて、「php2shell-scan」を名乗るスキャナが当社の保守先に合計で100回以上届いていました。PHPのバージョンを外部から割り出そうとする古典的な手口（特定のクエリ文字列で反応を見る）を使っていました。
「PHPを上げると壊れる」サイトが、いちばん危ない
今回の件で本当に困るのは、「PHPを切り替えれば済む」サイトではありません。切り替えたくても切り替えられないサイトです。
数年前に作ったまま更新が止まっているWordPressでは、古いテーマやプラグインが PHP 8 に対応しておらず、バージョンを上げた瞬間に画面が真っ白になる、問い合わせフォームが動かなくなる、といったことが起きます。だから、7.4 や 8.0、8.1 のまま止めている。そういうサイトが、今回は修正版の届かない世代に取り残されました。
この状態から抜け出すには、順番があります。
- まずバックアップ。ファイルとデータベースの両方を、戻せる形で取ります。
- 複製環境で PHP 8.3 に切り替えて、何が壊れるかを洗い出す。本番には触りません。テーマ、プラグイン、functions.php の独自コードのどこで止まるかを特定します。
- 壊れる箇所を直す。更新で済むプラグインは更新し、更新が止まっているものは代替に置き換え、独自コードは PHP 8 で動くように書き換えます。
- 本番を切り替えて、動作を確認する。表示、フォーム、決済、会員機能など、主要な導線を一通り通します。
「制作会社と連絡が取れない」「誰が作ったか分からないコードが入っている」という場合は、2の調査から手を付ける必要があります。当社ではこうした案件を焦げついた案件として日常的にお引き受けしています。
いま、やること（チェックリスト）
- PHPバージョンを確認する（方法1）。8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上なら、ひとまず対処済みです。
- 対象だったら、サーバー会社の告知を確認する（各社の状況）。系列を選ぶ方式のサーバーで修正適用が完了していれば、少し待ってから方法1で再確認します。
- 8.1 以前だったら、サポート中の系列（8.3 推奨）へ切り替える。切り替えると壊れる心当たりがある場合は、先に複製環境で確認します。
- 切り替えられない間の暫定策。PHP公式は、管理者が強制する形での
memory_limit=-1や、session.upload_progress.enabled=0などの設定を挙げていますが、いずれも特定の攻撃経路を減らすだけで更新の代わりにはならない、という位置づけです。Cloudflare を経由しているサイトは、無料プランでも防御ルールが自動で有効です。 - 更新が遅れていたサイトは、攻撃の痕跡も確認する（次の項目）。
攻撃を受けていないかの確認
発見者が推奨する確認事項として、JPCERT/CC の注意喚起で紹介されているポイントです。外部からは分からないので、サーバーのログや管理画面で確認します。
- レスポンスに、異常に長い、または形式のおかしい
PHPSESSIDクッキーが設定されていないか - 不審な
multipart/form-dataリクエストの直後に、メモリ上限のエラーや HTTP 500 が繰り返し出ていないか - PHPのワーカープロセスが、説明のつかない異常終了や再起動をしていないか
痕跡が見つからなくても「攻撃を受けていない」とは断定できない、と JPCERT/CC も注意しています。心当たりがある場合は、更新に加えて、保存している認証情報（データベースのパスワード、APIキーなど）の変更も検討してください。
WPドックでできること
「自分で確認するのが不安」「切り替えたら壊れた」「古いテーマのせいで上げられない」という方のために、段階的なメニューを用意しています。
| 段階 | 内容 | 費用 |
|---|---|---|
| 無料診断 | URLを入れるだけ。WordPressのバージョンと、外部から見える範囲のセキュリティ状態をその場で確認 | 無料 |
| くわしい診断 | 管理画面とサーバー設定からPHPの正確なバージョンを確認。切り替えた場合に壊れるテーマ・プラグインを洗い出し、必要な作業のお見積もりをお渡し | 9,800円（作業依頼時は全額値引き） |
| 安全更新パック | バックアップ → 複製環境で検証 → PHPの切り替えと WordPress・プラグインの更新 → 動作確認まで代行 | 39,800円 |
| 互換性の修正を伴う移行 | 古いテーマや独自コードの書き換えを含めて PHP 8.3 へ。調査後に個別見積もり | 10万円〜 |
価格はすべて税込です。どの段階からでも始められますし、診断だけで終わっても構いません。他社に断られた案件、制作会社と連絡が取れない案件も、まずはご相談ください。ご相談は無料で、1営業日以内にお返事します。
制作会社・フリーランスの方で、「クライアントのサイトが古いPHPのまま、何件もある」という場合は、制作会社・フリーランスの方へをご覧ください。白ラベルでの納品にも対応しています。
当サイト自身の状況
WPドック（wp-dock.com）はエックスサーバー上で動いており、10月22日の確認時点で PHP 8.3.36（修正版）で稼働しています。9月の WordPress 本体の脆弱性（CVE-2026-87902）、7月の wp2shell と同様、自社のサイトを先に点検したうえで、この記事を書いています。
参考・出典
- PHP公式のセキュリティ告知（2026年10月21日）: php.net
- 公式アドバイザリ CVE-2026-109618（GHSA-w8hw-w9fx-j79w）: GitHub php/php-src
- 公式アドバイザリ CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）: GitHub php/php-src
- JPCERT/CC 注意喚起 JPCERT-AT-2026-0033: https://www.jpcert.or.jp/at/2026/at260033.html
- IPA 注意喚起: https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
- Wiz による技術解説（発見者）: PHP2Shell: AI uncovers critical RCE vulnerabilities
- Cloudflare の防御展開と攻撃観測: Cloudflare deploys protections against php2shell vulnerability
- Tenable の FAQ（悪用状況・規模の数字の出典）: php2shell FAQ
- Patchstack の WordPress 向け解説: Major security alert: PHP vulnerable to critical RCE
- さくらインターネットの告知: [緊急]さくらのレンタルサーバ・さくらのマネージドサーバ
- ロリポップ！の告知: 【重要】PHPの脆弱性への予防措置に伴うメンテナンス実施のお知らせ
- ConoHa WING の告知: 【緊急メンテナンス】[ConoHa] サーバーメンテナンス／【重要】PHPの脆弱性への弊社対応について
- エックスサーバーの告知: PHPの脆弱性への対応について（10月23日に閲覧。22日14時時点は公式サイトが停止中だったため、初版の時系列は同社のメンテナンス表示と各社のまとめ記事に基づいていました）
※本記事は2026年10月22日14時に公開し、10月23日に各社の続報と当社の再確認結果を追記しました。各社の対応状況は変わっていきますので、新しい情報が出た場合はさらに追記します。