PHPの緊急脆弱性「php2shell」｜サイト運営者が今日やること

結論からお伝えします。WordPress などでサイトを運営している会社が今日やることは、自社サイトの PHP に修正が当たっているかを確認する、この 1 点です。レンタルサーバーを使っていて PHP 8.2 以上なら、多くの場合はサーバー会社がすでに修正を当てています。8.1 以下なら、サーバーの管理画面から 8.3 以上に切り替えるのが根本的な対策です。

この記事は 2026 年 10 月 22 日 12 時 30 分時点の情報で書いています。状況は時間とともに変わるため、最終的な判断はご利用のサーバー会社の最新のお知らせで行ってください。

何が起きたのか

2026 年 10 月 21 日の夜（日本時間 22 時 30 分ごろ）、Web サイトの多くを動かしているプログラム言語「PHP」の本体に、非常に重大な欠陥 2 件の修正版が公開されました。通称「php2shell」と呼ばれ、識別番号は CVE-2026-109618 と CVE-2026-109619 です。深刻度は 10 点満点中 9.2 で、最も重い「緊急」に分類されています（出典）。

欠陥の内容を一言でいうと、ログインしていない外部の人が、サーバー上でプログラムを動かせてしまうというものです。攻撃が簡単で自動化もできるため、PHP 公式も「完全な回避策はなく、更新だけが完全な解決策」と明言しています。公表予定日より前の 10 月 20 日に情報が漏れ、修正版が出る前から攻撃の試行が観測されていました。

影響の大きさは、首相が公式 X で「大至急」の対応を呼びかけ、BASE・pixiv・ニコニコ、銀行や鉄道会社のサイトまで予防的に一時停止したことからも分かります（出典）。

まず押さえておきたい 3 つのこと

1. WordPress やプラグインを更新しても直りません。 欠陥は WordPress ではなく、その土台の PHP 本体にあります。WordPress 公式も、今回の件で WordPress 本体の更新は不要で予定もないと説明しています（出典）。

2. レンタルサーバーでは、修正はサーバー会社が行います。 利用者が PHP 本体を書き換えることはできません。一方、VPS やクラウド、自社サーバーは自動では更新されないため、管理者が自分で修正版を当てる必要があります。

3. 見た目が正常でも、修正済みとは限りません。 今回の欠陥は画面に出ません。サイトが普段どおり表示されていても、修正が当たっているかは別に確認する必要があります。

レンタルサーバー各社の対応状況

10 月 22 日 12 時 30 分時点で確認できた各社の状況です。

• エックスサーバー（シン・レンタルサーバー含む）: PHP 8.2〜8.5 は 22 日 6 時 45 分に対象の全サーバーへ適用完了。8.1 以下は独自修正を検証が済んだものから順次適用中で、完了時期は未定（出典）。
• さくらのレンタルサーバ: 21 日 23 時から 22 日 6 時 30 分の緊急メンテナンスで「PHP のバージョンアップ」を実施し完了。古い PHP の利用者には 8.3 の利用を案内（出典）。
• お名前.com レンタルサーバー: 利用中の PHP バージョンを変えずに、お名前.com 側でセキュリティパッチを順次適用。PHP 5 系・7 系はバージョン変更が必要になる場合あり（出典）。
• ロリポップ！: 修正版の適用が完了するまで、一部サーバーのサイトを一時停止中（22 日 3 時 5 分発表）。完了の発表は執筆時点で未確認（出典）。
• ConoHa WING: 21 日 19 時から 22 日 10 時の緊急メンテナンスを実施。公式告知には PHP への言及がなく、適用状況は執筆時点で確認できていません。

修正版の番号は 8.2.35 ／ 8.3.36 ／ 8.4.27 ／ 8.5.12 です。管理画面で表示される番号がこれ以上であれば修正済みです。

今日やること 3 ステップ

ステップ 1: PHP のバージョンを確認する

確認場所は 2 つあります。サーバーの管理画面の PHP 設定（エックスサーバーは「PHP Ver.切替」、さくら・ロリポップ・お名前.com は「PHP設定」、ConoHa は「サイト設定」の応用設定）と、WordPress の管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」です。

2 つの数字が違う場合、実際に動いているのは WordPress 側に表示された数字です。食い違いは「確認未完了」として、対象ドメインと設定の反映状況を確かめてください。

ステップ 2: 8.2 以上なら、番号が修正版以上かを確かめる

番号が 8.2.35 ／ 8.3.36 ／ 8.4.27 ／ 8.5.12 以上なら作業は不要です。念のため、トップページ・下層ページ・問い合わせフォームの送信・管理画面へのログインが普段どおり動くことだけ確認してください。

番号がこれより古い場合は、見ているドメインの違いか、まだ反映されていない可能性があります。待たずにサーバー会社のお知らせを確認し、サポートに適用状況を照会してください。

ステップ 3: 8.1 以下なら、8.3 以上に切り替える

PHP 8.1 以前は公式サポートがすでに終了しています。開発元は今回の深刻さを踏まえて 7.4・8.0・8.1 向けにも最小限の修正コードを公開しましたが、正式な修正版ではなく、それを当てるかはサーバー会社次第です（出典）。確実なのは 8.3 以上への切り替えです。

手順は次のとおりです。

1. サーバーの自動バックアップに、ファイルとデータベースの両方の直近分があることを確認する
2. PHP 設定の画面で対象ドメインを選び、8.3 以上を選んで保存する（使っているテーマ・プラグイン・カートシステムの対応範囲内で選ぶ）
3. 反映後、トップページ・下層ページ・フォーム送信・管理画面ログインを確認する。EC サイトはカートと決済も確認する
4. 不具合が出たら、いったん元のバージョンに戻す。ただし戻した状態は未修正のままなので、当日中に制作会社へ連絡する

WordPress で不具合が出た場合、原因はプラグインであることが多く、プラグインを 1 つずつ停止して切り分けると直ることがあります。

やらない方がよいこと

焦って手を打つほど、サイトを壊してしまいます。次の対応は避けてください。

• 「対策プラグイン」や出どころ不明のコードを入れる。 欠陥は PHP 本体にあり、プラグインでは防げません。偽物にウイルスが仕込まれている例もあります。
• 「メンテナンスモードにすれば安全」と考える。 画面を隠しても PHP は動いたままで、防御にはなりません。
• 「バックアップがあれば大丈夫」と考える。 バックアップは被害のあとに戻すためのもので、防御にはなりません。修正版の適用が本命です。
• 対応範囲を確認せずに最新版へ上げる。 テーマ・プラグイン・カートシステムが対応する PHP の範囲を先に確認してください。

なお「スマホや Wi-Fi の電源を切れば防げる」という投稿が出回っていますが、誤りです。狙われるのは企業のサーバー側で、閲覧者側の操作は関係ありません。

制作会社に任せている場合に聞くこと

自社でサーバーを触らない会社は、制作会社や保守担当に次の 3 つを今日中に聞いてください。

1. うちのサイトの PHP バージョンはいくつか
2. 修正は誰が、いつ当てるのか
3. 終わったら連絡をもらえるか

修正が当たっておらず、切り替えもできない場合は、修正と確認が終わるまでサイトを一時的に公開停止することも選択肢です。欧州の CERT-EU と WordPress 公式が、直ちに修正できない場合の対応として挙げています（出典）。

明日以降に行うこと

今日の確認が終わったら、落ち着いて次の点検をおすすめします。

• 10 月 20 日から 22 日のアクセスログ・エラーログを、できれば今日のうちにダウンロードして保全する
• 見覚えのないファイルや、知らない管理者アカウントがないかを確認する
• WordPress の管理者パスワードを変更する。不審な痕跡があれば、除去したあとにもう一度変更する
• 公開中の別ドメイン・サブドメイン・テスト環境があれば同じ確認をする。使っていないサイトは止める
• PHP は常にサポート中のバージョンを使う。8.2 は 2026 年 12 月末でサポートが終わるため、8.3 以上が目安

今回の件は、サイトの「土台」を誰が管理しているのかを会社として把握する機会でもあります。サーバー会社・制作会社・自社の役割分担を一度書き出しておくと、次に同じことが起きたときに迷わず動けます。

この記事の内容は、A4 横 11 ページの配布用資料にもまとめています。社内や取引先への共有にお使いください（PDF を開く）。