PHP2shell（CVE-2026-109618）とは？対象の確かめ方と今すぐやること、各サーバーの対応

01この記事でわかること

• PHPとは何か、PHP2shellとはどんな脆弱性か
• いつ、誰が、何を発表したのか（10月20日〜27日の流れ）
• なぜ「急いで」と言われているのか。CVSS 9.2という数字の意味
• 自分のサイトが対象かどうかの見分け方と、その場で使える確認ツール
• 主なレンタルサーバー17社の対応状況と、注意したい「番号が変わらない修正」
• レンタルサーバー利用者・自社サーバー・制作会社に任せている人、それぞれの「今すぐやること」
• すぐ更新できないときの応急処置と、攻撃を受けたかの確かめ方
• PHP 8.2のサポートが2026年12月31日で終わることと、これからの備え

3行でまとめると：

1. PHPの中心部分に、ログイン不要で外からプログラムを動かされるおそれのある弱点が2件見つかり、10月21日に修正版（8.5.12・8.4.27・8.3.36・8.2.35）が出ました。WordPressやEC-CUBEなど、PHPで動くサイトはすべて関係します。
2. 実証用のプログラムが多数公開され、攻撃を試みる通信も観測されています。米CISAは10月26日に「悪用が確認された脆弱性」として登録しました。
3. レンタルサーバーの多くは、会社側で修正を済ませています。自社で管理するサーバー（VPS・クラウド）は、自分で更新しないと直りません。PHP 8.1以前を使っているなら、8.2以上（できれば8.3以上）への切り替えを進めてください。

自社サイトが対象かどうかは、この記事の途中にある確認ツールで、URLを入れるだけで確かめられます。ツールのページ（PHPバージョン・脆弱性チェック）から直接使うこともできます。

02最新の動き：PHPを組み込んだ機器も狙われ始めた

2026年10月29日、JPCERT/CCは注意喚起を更新し、PHP2shellを使った攻撃がWebサイトだけでなく、PHPを中に組み込んだ機器にも広がっていることを伝えました。追記された内容は次のとおりです。

• 攻撃活動の調査で、あるファイアウォール製品の特定のバージョンが侵害されたことを示す痕跡が見つかったと報告されています。
• 攻撃者はその製品を解析し、バージョンごとに、PHP2shellとLinuxの権限昇格（一般の権限から管理者の権限を奪うこと）の脆弱性を組み合わせた攻撃コードを作っていたとされています。
• 侵害された機器を足がかりに、会社の中のネットワークへ広がろうとした痕跡も見つかったとしています。
• 一部の製品メーカーも、この脆弱性を悪用した攻撃を観測したとして、セキュリティのお知らせを更新しています。

ファイアウォールやVPN装置、NAS（ファイルを保存する機器）、ルーターなどの中には、管理画面をPHPで動かしているものがあります。自社でWebサイトを持っていない会社でも、こうした機器を使っていれば関係する可能性があります。JPCERT/CCは、PHPを組み込んだ製品を狙う攻撃がさらに広がるおそれがあるとして、製品の管理者に、影響の確認と侵害の調査を急ぐよう求めています。

どの製品が影響を受けうるかは、オランダの国家サイバーセキュリティセンター（NCSC-NL）がGitHubで一覧にまとめていて、JPCERT/CCも参考情報として紹介しています。会社で使っているファイアウォールやVPN装置のメーカー名で、メーカーのお知らせとこの一覧を確かめてください。分からなければ、機器を入れた業者に「PHP2shellの影響はあるか」と問い合わせるのが早道です。

03PHP2shellとは何か（PHPとは、から）

PHPは「サイトの裏で動く料理人」

PHPは、Webサイトを動かすためのプログラム言語です。お客さんがページを開くたびに、サーバー（サイトを置いておくコンピューター）の中でPHPが動き、その場でページを組み立てて返します。飲食店にたとえると、お客さんの注文を受けて、その都度料理を作る厨房の料理人のような役割です。

WordPress（ワードプレス）でつくった会社のホームページ、EC-CUBE（イーシーキューブ）などでつくったネットショップ、予約フォームやお問い合わせフォームの多くは、PHPで動いています。サイトを見る人のパソコンやスマホにPHPが入っている必要はなく、PHPが動いているのはサイトを置いているサーバーの側です。ですから、今回の問題で対応が必要なのは、サイトを運営している会社の側です。

脆弱性とは「建物の設計ミス」

脆弱性とは、ソフトウェアの設計や作りの弱点のことです（用語集：脆弱性）。建物にたとえると、鍵をかけていても開いてしまう窓のようなものです。持ち主が気をつけていても、作り自体に問題があるため、直すには作った側が出す修正（パッチ）を当てる必要があります（用語集：パッチ）。

今回の2件は、WordPressのプラグインのような「上に乗っているソフト」ではなく、PHPそのもの、つまり厨房の設備そのものにある弱点です。そのため、WordPressやEC-CUBEをいくら最新にしていても、下で動いているPHPが古いままなら対象になります。

2件の中身をやさしく言うと

PHPの開発元（PHP Group）の説明を、専門用語を外して言い直すと、次のとおりです。

どちらも、PHPがエラー、とくに「メモリ不足」のエラーを処理するときの、後片付けの不備が原因です。発見したWiz社は、この2つの番号に、細かく分けると4つの不具合がまとめられているとし、似た仕組みの別の不具合もこの2つの番号の中で扱われる見込みだとしています。

「PHP2shell」という名前の意味

「shell（シェル）」は、コンピューターに命令を打ち込む窓口のことです。「PHPからシェルへ」、つまりPHPの弱点を入口に、サーバーに命令を出せる状態にまで至るおそれがある、という意味の名前です。名付けたのは発見者側で、IPAも「この2つの脆弱性の組み合わせはPHP2shellと呼ばれています」と紹介しています。

誰が見つけたのか

見つけたのは、米国のセキュリティ会社Wiz（ウィズ）の研究チームです。Wiz社のブログによると、AIを使った調査の中で2026年8月19日に最初の不具合を見つけ、8月24日にPHPの開発元へ報告しました。開発元が修正の調整を始めたのは9月21日で、修正版の公開と情報の公表は10月21日です。開発元の説明ページ（GitHubのアドバイザリ）にも、Wiz社などの報告者の名前が載っています。報告から公開までの約2か月、情報は伏せられたまま修正が準備されていました。

このように、見つけた人が先に開発元へこっそり知らせ、修正の準備ができてから一斉に公表するやり方を「協調した公開」と呼びます。公表の日に修正版がそろっているのはこのためです。裏を返すと、公表された瞬間から、攻撃者も弱点の場所を知ることになります。修正版が出た日から「更新するまでの日数」が、そのまま危ない期間になります。

04発表の時系列

公式発表に書かれた日付を、古い順に並べます。時刻は、とくに断りがなければ日本時間です。

1. 8月19日
   Wiz社

   最初の不具合を発見（同社ブログ）

2. 8月24日
   Wiz社

   PHPの開発元のセキュリティチームに報告

3. 9月21日
   Wiz社

   開発元が報告を受け止め、協調して修正を始める

4. 10月20日
   PHP Group

   緊急のセキュリティリリースを予告。「2件の重大な脆弱性で、どちらもCVSS v4.0で9.2」。公開は10月21日14:00（協定世界時。日本時間23:00）と案内

5. 10月21日
   IPA

   「事前準備のお願い」を公表

6. 10月21日
   PHP Group

   PHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、「ただちに更新を」と呼びかけ。同日、Wiz社がブログで詳細を公表

7. 10月21日
   WordPress.org

   「Critical PHP Security Release」を掲載。WordPress本体の更新は不要で、PHPの更新を求める

8. 10月22日
   JPCERT/CC・IPA

   それぞれ注意喚起を公表

9. 10月23日
   PHP Group

   条件がそろったときだけ起きる関連の問題（CVE-2026-115560）を公表。次の通常リリースで修正予定

10. 10月26日
    JPCERT/CC

    「悪用可能と主張する実証コードが多数公開」「悪用を試みる通信を観測したとの報告が相次いでいる」と追記

11. 10月26日（米国時間）
    米CISA

    2件を「悪用が確認された脆弱性」の一覧（KEV）に登録

12. 10月26日
    PHP Group

    Windows版のPHPを作り直し（別の部品の脆弱性への対応。PHPのバージョンは同じ）

13. 10月27日
    IPA

    CISAの登録を受けて注意喚起を更新。国内の被害事例は把握していないとする

14. 10月29日
    JPCERT/CC

    注意喚起を更新。あるファイアウォール製品の侵害を示す痕跡と、内部ネットワークへの横展開の痕跡が報告されたと追記。NCSC-NLの影響製品の一覧を参考情報に追加

JPCERT/CC（ジェイピーサート・コーディネーションセンター）は、国内のサイバー攻撃の情報を集めて注意を呼びかける組織です（用語集：JPCERT/CC）。IPA（情報処理推進機構）は、経済産業省所管の機関で、脆弱性の情報を国内に知らせる役割を持っています（用語集：IPA）。どちらも日本語で注意喚起を出しているので、社内で説明するときの根拠として使えます。

05何がそんなに危ないのか

脆弱性のニュースは毎週のように出ます。その中で今回がとくに急ぎとされる理由は、次の4つです。

1. ログインしなくても狙える

多くの攻撃は、管理画面のパスワードを盗むなど「中に入る」手間がかかります。PHP2shellは、開発元の説明で「認証なし（unauthenticated）」とされています。つまり、サイトの管理者でも会員でもない、外の誰かが送った通信だけで起きるおそれがあります。パスワードを強くしても、二段階認証を入れても、この弱点そのものは防げません。

2. 外から好きなプログラムを動かされるおそれがある

開発元は2件とも「遠隔からのコード実行（RCE）」につながるとしています。これは、攻撃者が自分で用意した命令を、あなたのサーバーの上で動かせる状態のことです。JPCERT/CCは「PHPの実行プロセスの権限で任意のコードを実行される可能性」があると説明しています。一般に、この状態になると、ページの書き換え（改ざん）、データベースに入っている顧客情報の持ち出し、不正なプログラム（マルウェア）の設置などにつながるおそれがあります。厨房の例でいえば、外の人が勝手に厨房に指示を出し、料理に何かを混ぜたり、帳簿を持ち出したりできてしまう状態です。

開発元は、ApacheというWebサーバーにPHPを組み込む使い方（mod_php）で危険がいちばん高いとし、「ログインしていない人の通信1回で、サイトのプログラムが動き出す前に攻撃を起こせる」実証があったと書いています。Wiz社は、実験環境でWordPress、Drupal、Joomlaの3つのサイト作成ソフトに対して、ログインなしでのコード実行を確かめたとしています。

3. 実際に攻撃が始まっている

JPCERT/CCは10月26日、「悪用可能と主張する実証コードが多数公開」され、「悪用を試みる通信を観測したとの報告が相次いでいる」と追記しました。実証コードとは、脆弱性が本当にあることを示すための見本のプログラムです。見本が出回ると、技術に詳しくない攻撃者でも試せるようになります。

同じ日、米国のCISAは2件を「KEV（Known Exploited Vulnerabilities：悪用が確認された既知の脆弱性）」の一覧に載せました。この一覧は、実際に悪用された証拠がある脆弱性だけを載せるものです。CISAは米国の連邦政府機関に対し、10月29日までに対応するよう求めています。日本の会社に直接の義務はありませんが、「様子見してよい段階は過ぎた」という目安になります。

一方でJPCERT/CCは、実証コードで本当にコードを実行できるかどうかは、PHPのバージョン、実行環境、メモリの配置などに左右されるとも書いています。「どのサイトでも必ず乗っ取られる」わけではありません。ただ、自分のサイトが「たまたま大丈夫な条件」かどうかを確かめるのは専門家でも難しいため、更新するのがいちばん確実です。

4. CVSS 9.2という数字の意味

CVSS（シーブイエスエス）は、脆弱性の深刻さを0〜10の数字で表す世界共通の物差しです。9.0以上は最も重い「緊急（Critical）」に分類されます。2件とも、最新の版（v4.0）で9.2です。開発元の公開した内訳をやさしく読むと、次のようになります。

「難しさが高い」のに9.2になっているのは、ログイン不要・操作不要で、成功したときの被害が大きいからです。しかも、PHPは世界中の非常に多くのサイトで使われています。狙える範囲の広さも、各機関が急ぎ対応を求める理由です。

06影響を受けるもの・受けないもの

PHPのバージョン別

PHPのバージョンは「8.3.36」のように3つの数字で表します。最初の2つ（8.3）が「系列」、最後の数字が「その系列の中での修正回数」です。今回は、各系列の次の番号以上が修正版です。

Wiz社は「この10年に出たすべてのPHPのバージョンが、少なくとも1つの影響を受ける」としています。IPAも、Wiz社の情報として「PHP 5.4以降のバージョンは、これらの脆弱性のいずれかの影響を少なくとも受ける」と紹介しています。古いPHPほど安全、ということはありません。むしろ、公式の修正がない分だけ危険です。

なお、開発中の次の版（PHP 8.6のテスト版）にも修正が入っていますが、開発元は「本番では使わないで」と明記しています。

PHPの動かし方（SAPI）別

PHPは、Webサーバーとのつなぎ方にいくつか種類があります。開発元は、Webのリクエストを処理するすべてのPHPが対象だとし、次のものを挙げています。

「うちはこの方式だから大丈夫」と言える方式はありません。自分のサイトがどの方式かは、レンタルサーバーなら気にしなくてかまいません。自社サーバーの場合は、管理している人に聞いてください。

サイトの種類別

注意したいのは、「メインのサイトはPHPを使っていないが、お問い合わせフォームだけ別のレンタルサーバーのPHPで動いている」という構成です。昔つくったキャンペーンページや、使っていない旧サイトがサーバーに残っている場合も同じです。会社として持っているドメインとサーバーを、一度すべて洗い出しておくと安心です。

07自分のサイトが対象か確かめる方法

確かめ方は、使っている環境によって違います。いちばん手軽な方法から順に紹介します。

方法1：このページの確認ツールを使う（約10秒）

このすぐ下にある確認ツールに、自社サイトのURLを入れてください。ツールはトップページを1回だけ読み、サーバーが外に出しているPHPのバージョンを確かめます。あわせて、どのレンタルサーバー会社を使っているかを見分け、その会社の公式発表に書かれた対応状況（修正済みかどうか、利用者がやることがあるか）を表示します。サイトに負担をかけたり、攻撃を試したりするものではありません。

PHPのバージョンを外に見せない設定にしているサイトも多くあります。その場合は、次の方法2や方法3で調べたバージョンを手で入れると、修正版かどうかを判定できます。また、後で説明するとおり、レンタルサーバーには「番号を変えずに修正した会社」が多いため、番号だけでなく会社の発表とあわせて判断してください。

方法2：WordPressの管理画面で見る

1. WordPressの管理画面にログインします。
2. 左のメニューから［ツール］→［サイトヘルス］を開きます。
3. 上のタブの［情報］を押します。
4. ［サーバー］の欄を開くと、「PHPバージョン」が表示されます。

この手順は、WordPress.orgが今回の告知の中で案内しているものです。管理者の権限がないと表示されないことがあります。

方法3：レンタルサーバーの管理画面で見る

多くのレンタルサーバーでは、管理画面にドメインごとのPHPのバージョンが表示され、そこで切り替えもできます。たとえばロリポップ！は「ユーザー専用ページ」の［サーバーの管理・設定］→［PHP設定］、KAGOYAはコントロールパネルの［Webサイト］→［PHP］→［PHPバージョン変更］で確認できると案内しています。ほかの会社でも、「PHP設定」「PHP Ver.切替」といった名前のメニューを探してください。

方法4：自社サーバー（VPS・クラウド）の場合

サーバーにログインできる担当者に、Webで実際に動いているPHPのバージョンを確かめてもらいます。コマンドで表示される番号と、Webサイトを動かしている番号が違うことがあるので、「Webで動いているほう」を確かめてもらうのがポイントです。LinuxのOSに付いてくるPHPを使っている場合は、配布元（Ubuntu、Debian、Red Hatなど）がPHPの番号を変えずに修正を入れることがあります。PHPの開発元によると、Linuxの配布元などには事前に修正が渡されています。その場合は、配布元の更新情報で、CVE-2026-109618とCVE-2026-109619が直っているかを確かめてもらいます。

なお、ネット上には「phpinfo()を表示するファイルを置いて確かめる」という方法もよく載っています。この方法は、サーバーの詳しい設定を誰でも見られる状態にしてしまうので、使う場合は確認後すぐに消してください。

判断の目安

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

レンタルサーバー（1台のサーバーを複数の利用者で分け合うサービス）では、PHPの本体はサーバー会社が管理しています。利用者が自分でPHPを直すことはできませんが、そのかわり、会社が一斉に修正を当てることができます。主な17社の公式発表を開いて確かめた結果は、次のとおりです（2026年10月28日時点）。

17社のうち16社が、提供中のPHPに修正を当て終えたと発表しています。KAGOYAは、プランによっては脆弱性が残っていると自ら案内しています。KAGOYAの古いプランを使っている場合は、同社の案内に沿ってプランの変更を急いでください。同社は、すぐに対応できない場合に、サイトを一時的に非公開にする方法も案内しています。

注意：「番号を変えずに修正した会社」がある

表のとおり、多くの会社は、利用者のサイトが動かなくなるのを避けるため、PHPのバージョンの番号を変えずに修正を当てました。ConoHa WINGは「8.3.35などの表示のままで修正済み」と説明しています。この場合、管理画面や確認ツールで「8.3.35」と表示されていても、実際には修正されています。

逆に言うと、番号だけを見て「まだ古いから危ない」と慌てる必要はありませんし、「番号が新しくなったから大丈夫」と決めつけることもできません。レンタルサーバーを使っている場合は、番号よりも、契約している会社の公式発表を正としてください。この記事の確認ツールは、会社を見分けたうえで、その会社の発表内容を表示します。

「独自の修正」と「公式の修正版」は違う

PHP 8.1以前には、開発元からの正式な修正版が出ていません。開発元が用意したのは、7.4・8.0・8.1向けの最小限の修正コードだけです。それより古い版は、各社が自分たちで修正を作って当てています。ロリポップ！は8.1以前への対策を「応急的なもの」とし、今後見つかる脆弱性には公式の修正がなく、対応できない可能性があると書いています。「今回は会社が直してくれた」からといって、古いPHPを使い続けてよいわけではありません。

クラウド（AWS・Google Cloudなど）やVPSは自分で

AWSやGoogle Cloudなどのクラウド、各社のVPS（仮想専用サーバー）は、PHPを含むソフトの管理が利用者の責任です。エックスサーバーもKAGOYAも、VPSについては利用者が自分で更新する必要があると明記しています。制作会社やシステム会社に管理を任せている場合は、その会社が対応済みかを確かめてください。

09立場別に今すぐやること

A. レンタルサーバーでサイトを運営している人

1. 契約しているサーバー会社のお知らせを確かめる。上の表に会社名があれば、リンク先を開きます。表にない会社なら、会社名と「PHP 脆弱性」でお知らせを探します。
2. サイトのPHPのバージョンを確かめる。確認ツールか、管理画面で見ます。
3. 8.1以前なら、8.2以上に切り替える計画を立てる。8.2は年末でサポートが終わるため、できれば8.3以上を選びます。切り替える前にサイトのバックアップを取り、切り替えた後は、トップページ、お問い合わせフォーム、画像のアップロード、ネットショップの注文画面など、主な機能が動くかを確かめます。
4. WordPressやプラグインも最新にする。新しいPHPでは、古いプラグインが動かないことがあります。ロリポップ！も、本体・プラグイン・テーマが最新かの確認を求めています。
5. KAGOYAの共用・専用プランなど、会社が「未対応」とする場合は、案内に沿ってプランを変えるか、変えるまでサイトの公開を止めることを考えます。

B. VPS・クラウド・自社のサーバーで運営している人

1. PHPを動かしているサーバーをすべて洗い出す。本番だけでなく、テスト用、古いキャンペーン用のサーバーも含めます。
2. 修正版に更新する。8.5.12・8.4.27・8.3.36・8.2.35以上へ。OSの配布元のパッケージを使っているなら、配布元の更新を当てます。
3. PHPの働き手（ワーカー）とWebサーバーを再起動する。更新しても、古いプログラムが動き続けていては意味がありません。
4. Dockerなどのコンテナを使っている場合は、元になるイメージを作り直す。Wiz社は、公式のコンテナイメージでも検証しています。古いイメージから作ったコンテナは古いPHPのままです。
5. 8.1以前のサーバーは、更新の段取りがつくまで外から見えない状態にすることも考える。WordPress.orgは、各国の機関の助言として、すぐ直せないシステムはいったんオフラインにすることを紹介しています。
6. 次の「攻撃されたかの確かめ方」に沿って、ログを確認する。

C. 制作会社・保守会社にサイトを任せている人

自分で作業する必要はありませんが、「任せているから大丈夫」と思い込まないことが大切です。次の4点を、メールで問い合わせてください。記録が残るので、後で確かめるときにも役立ちます。

1. 当社のサイト（URL）は、PHP2shell（CVE-2026-109618、CVE-2026-109619）の対象ですか。
2. PHPのバージョンはいくつで、修正は済んでいますか。済んでいないなら、いつ済みますか。
3. 攻撃を受けた形跡がないか、ログを確認しましたか。
4. PHP 8.2のサポートが12月31日に終わります。当社のサイトは8.3以上に上げる予定ですか。費用はかかりますか。

返事が来ない、担当者が分からない、という場合は、それ自体が「保守の体制がない」というサインです。後半の「同じことを繰り返さないために」も読んでください。

D. WordPressの記事を書くだけで、サーバーは触らない人

WordPress.orgによると、今回の問題はWordPress専用のものではなく、WordPress本体の更新は不要で、予定もありません。あなたがやることは、サイトの管理担当者に「PHPの対応は済んでいますか」と一言聞くことです。サイトヘルスの画面でPHPのバージョンを見て、伝えてあげるのも助けになります。社内に担当者がいなければ、AかCの手順に進んでください。

10すぐ更新できないときの応急処置

PHPの開発元は、更新だけが完全な解決策だとしたうえで、すぐに更新できない人向けに、特定の攻撃経路を減らす設定を示しています。ただし、開発元自身が「これらの対策でインストールが安全になるわけではない」と書いています。あくまで、更新までの時間を稼ぐためのものです。ここで紹介する設定は、サーバーの設定ファイルを触れる人（自社サーバーの管理者や保守会社）向けです。レンタルサーバーの利用者は、会社の対応を確かめるほうが先です。

開発元が示している主な緩和策

開発元はほかに、エラーの表示を隠す設定（error_reporting、display_errors、@）は役に立たないこと、外から起こせる致命的なエラーや処理の時間切れを直すことを挙げています。また、説明ページ（アドバイザリ）では、性能に余裕があれば、PHPの働き手が1回ごとに入れ替わる設定（pm.max_requests=1）を検討する方法も紹介しています。

10月23日の追加情報（CVE-2026-115560）

開発元は10月23日、別の番号CVE-2026-115560の問題を公表しました。サイトのプログラムが、セッション（ログイン状態などを覚えておく仕組み）の保存形式を、動いている途中で特定の組み合わせに切り替えている場合で、しかも session.upload_progress が有効なときにだけ起きるものです。開発元は「起きる可能性は低い」経路としつつ、次の通常リリースまで 「session.upload_progress.enabled=0」 にしておくよう勧めています。21日にすでにこの設定をした人は、そのままでよく、追加の作業は要りません。保存形式を途中で切り替えないアプリは、この機能を有効のままにしておけるとしています。

WAFで時間を稼ぐ

WAF（ワフ）は、サイトの手前に置いて、怪しい通信を止める「門番」のような仕組みです（用語集：WAF）。WordPress.orgは、サーバー会社がすでにPHPの更新やWAFのルール追加を進めている場合があると書いています。Wiz社は、Cloudflare、Fastly、Google、Vercelなどが、すぐに更新できない利用者向けの案内や対策を出したとしています。ただし、どのWAFがどこまで防げるかは公表されていない部分が多く、WAFは更新の代わりにはなりません。WAFの種類と選び方は、WAFの比較で紹介しています。

それでも難しいときは「止める」判断を

IPAは、修正が難しい場合、まずアクセス制限などの暫定対策をとり、有効な暫定対策が難しければ、外部からのアクセスを遮断することや、サービスを一時的に止めることを、被害と業務への影響を踏まえて判断するよう求めています。たとえば、社内の人しか使わない管理システムなら、会社のネットワークからしか開けないように制限できます。会社案内だけのサイトなら、更新が終わるまでの数日、お知らせページに切り替えるのも1つの方法です。

11攻撃されたかの確かめ方

修正を当てても、当てる前に入り込まれていたら、問題は残ります。JPCERT/CCは、発見者らが公開した情報をもとに、次の点を確認するよう勧めています。Wiz社のブログにも同じ趣旨の手がかりが書かれています。

JPCERT/CCは、攻撃の経路が複数あるため、1つの検知ルールですべての攻撃を見つけられるとは限らないこと、攻撃の方法やログの残し方によっては痕跡が残らない場合があることを注意しています。つまり、「痕跡が見つからない」ことは「攻撃されていない」ことの証明にはなりません。Wiz社も、この問題はアプリより下の層で起きるため、アプリのログには手がかりがほとんど残らないことがあるとしています。継続して監視することも勧められています。

レンタルサーバー利用者が自分で見られること

レンタルサーバーでは、サーバーの奥深くのログは見られないことが多いです。そのかわり、次のような「表に出る変化」に気をつけてください。

• サイトの見た目が変わっている、知らないページやリンクが増えている
• WordPressに覚えのない管理者ユーザーや、入れた覚えのないプラグインがある
• サーバーのファイル一覧に、更新日時が最近で心当たりのないPHPファイルがある
• 管理画面のアクセスログ・エラーログで、500エラーが急に増えた日がある
• Googleの検索結果に、自社サイトの名前で見覚えのないページが出る
• サーバー会社から「不審な動き」「迷惑メールの送信」などの連絡が来た

これらは今回の攻撃に限らず、サイトが乗っ取られたときによく見られる変化です。外から見える設定の弱点は、サイトの安全チェックでも確かめられます。

12被害にあったときの動き方

痕跡が見つかった、あるいはサイトの様子がおかしい場合は、慌てて消したり直したりする前に、次の順番で動きます。ここは今回の脆弱性に限らない、一般的な事故対応（インシデント対応）の基本です。

1. 証拠を残す。JPCERT/CCは、侵害が疑われる場合、ログなどの証拠を保全したうえで、影響範囲の調査や隔離をするよう案内しています。ログやファイルを消すと、何が起きたか分からなくなります。画面の写真、ログのダウンロード、サーバーのバックアップを先に取ります。
2. 広がりを止める。サイトを一時的に非公開にする、サーバーをネットワークから切り離すなど、被害が広がらないようにします。レンタルサーバーなら、サーバー会社に連絡して相談します。
3. 関係する会社に連絡する。サーバー会社、制作会社・保守会社に、いつ何に気づいたかを伝えます。自社だけで調べるのが難しければ、事故対応を専門にする会社に相談します。
4. パスワードを変える。サーバー、WordPressの管理者、データベース、FTP、メールなど、サーバーに関わるパスワードをすべて変えます。サーバーの中にあった設定ファイルのパスワードも、盗まれた前提で変えます。
5. きれいな状態から作り直す。入り込まれたサーバーは、どこに何を仕掛けられたか分かりません。修正済みのPHPの環境に、侵入される前のバックアップから戻すのが確実です。
6. 報告と案内をする。顧客の個人情報が漏れたおそれがある場合は、個人情報保護委員会への報告や本人への通知が必要になることがあります。お客さまへのお知らせも準備します。

被害にあったときの相談先や、費用の目安は被害にあったときのページにまとめています。

13PHPのサポート期限と、8.2のサポート終了

今回の件で、もう1つはっきりしたことがあります。それは、「サポートが終わったPHPには、こういうときに公式の修正が出ない」ということです。

PHPのサポートの仕組み

PHPの各系列は、公開から約2年は「通常のサポート（不具合の修正も含む）」、その後の約2年は「セキュリティの修正だけ」が受けられ、それを過ぎると修正が出なくなります。開発元が公開している期限は、次のとおりです。

8.2はあと2か月ほどで終わる

開発元は8.2.35の公開のお知らせで、「PHP 8.2は2026年12月31日にサポートが終わり、それ以降はセキュリティの修正を受けられない」と明記しています。今回、8.2には修正版が出ましたが、来年以降に同じような問題が見つかっても、8.2には修正が出ません。

今、8.2や8.1以前を使っているなら、今回の対応とあわせて、8.3以上への切り替えを年内に済ませる計画を立てておくのがおすすめです。切り替えには、プラグインやテーマが新しいPHPに対応しているかの確認が必要で、古いサイトでは改修が必要になることもあります。年末は制作会社も混み合うため、早めに相談してください。

レンタルサーバーの「独自修正」に頼り続けない

今回、多くのレンタルサーバーがサポート切れの版にも独自に修正を当てました。これは利用者を守るための大きな努力ですが、各社は同時に、8.2以上への移行を勧めています。ロリポップ！が書いているとおり、サポート切れの版は、今後の脆弱性に対応できない可能性があります。「今回は助かった」を、次も期待しないことが大切です。

14同じことを繰り返さないために

PHP2shellのような問題は、今後も必ず起きます。大切なのは、起きたときに「誰が、何日以内に、何をするか」が決まっていることです。IPAも今回の注意喚起の中で、更新が難しいシステムについて、担当者だけでなく事業の責任者や経営層も含めて、人員・予算・保守の体制を確保できるかを検討し、見通しが立たなければ、保守を受けられるサービスへの移行、機能の縮小、公開の終了まで含めて考えるよう求めています。

1. サイトとサーバーの「台帳」をつくる

会社で持っているドメイン、サイト、サーバー、使っているソフト（WordPress、EC-CUBEなど）、PHPのバージョン、管理している人や会社を、1枚の表にまとめます。今回のように「PHPを使っているサイトはどれか」と聞かれたとき、すぐ答えられるようになります。使っていない古いサイトは、この機会に閉じるのが安全です。

2. 保守の契約を見直す

制作会社にサイトを作ってもらったとき、「作るまで」の契約で、その後の保守が含まれていないことがよくあります。保守契約があるか、PHPやWordPressの更新が含まれるか、今回のような緊急時に何日以内に対応してくれるかを確かめてください。

3. 更新が自動で進む仕組みを選ぶ

PHPの管理を自社で抱えるのが難しいなら、今回のようにサーバー会社が一斉に修正を当ててくれるレンタルサーバーや、マネージド型（管理を任せられる）のサービスを選ぶのも1つの方法です。VPSやクラウドを使い続けるなら、OSの自動更新や、更新の通知を受け取る設定をしておきます。

4. WAFを入れておく

WAFは、更新までの「すき間」を守る門番です。WordPress.orgも、サーバー会社がWAFのルールを入れて対策している場合があると書いています。費用や種類はWAFの比較で確かめられます。

5. 脆弱性診断を定期的に受ける

脆弱性診断とは、専門家やツールが、サイトに弱点が残っていないかを外から調べるサービスです（用語集：脆弱性診断）。古いPHPやプラグインが残っていないかを、年に1回などの頻度で点検できます。診断サービスの比較は脆弱性診断のページにあります。

6. 情報を受け取る口をつくる

今回、PHPの開発元は修正版の前日に予告を出し、IPAも当日に「事前準備のお願い」を出しました。こうした情報を毎週まとめて確かめる習慣があれば、慌てずに済みます。セキュリティ図鑑では、その週に知っておきたい注意喚起を今週のセキュリティにまとめています。少し前に出たWordPress本体の更新（WordPress 7.1.2の脆弱性）もあわせて確かめておいてください。

15よくある質問

16今後の予定と、この記事の更新方針

公式発表に書かれている今後の予定です。

• 次の通常リリース（日付は未定）：PHPの開発元がCVE-2026-115560の修正と詳しい情報を公開
• 11月5日（予定）：開発中のPHP 8.6のテスト版（RC5）を公開
• 2026年12月31日：PHP 8.2のセキュリティサポートが終了。PHP 8.4の通常サポートも終了

この記事は、PHPの開発元、JPCERT/CC、IPA、米CISA、各レンタルサーバー会社の公式発表が更新されたときに書き直します。攻撃の詳しい手順や、確かめられていない被害の話は載せません。最新の状況は、PHPの開発元のニュース（https://www.php.net/archive/2026.php）と、JPCERT/CCの注意喚起（https://www.jpcert.or.jp/at/2026/at260033.html）で確かめてください。自社サイトの状況は、PHPバージョン・脆弱性チェックでいつでも確かめられます。