2026年10月21日、PHPの開発チームが、重大な脆弱性2件を直した版を公開しました。
2件の組み合わせは「PHP2Shell」と呼ばれ、国内でもIPA（情報処理推進機構）とJPCERT/CCが翌22日に注意喚起を出しています。
この記事は、自社のホームページをWordPressなどで動かしている会社の方に向けて書いています。
サーバーを自分で触れない人でも、自社のサイトが対象かどうかを確かめ、誰に何を頼めばよいかが決まるところまでを順に説明します。
出典は、PHPの公式サイトの告知、GitHubに公開された2件のアドバイザリ、IPAとJPCERT/CCの注意喚起、WordPressの公式の動作要件です。
英語の原文を引いたところは、こちらで和訳したものだと明記しています。
PHP2Shellとは 10月21日に公表されたPHPの2つの脆弱性
PHPは、ウェブサイトの裏側でページを組み立てるためのプログラム言語です。
WordPressもPHPで書かれているので、WordPressで作ったサイトは例外なくPHPの上で動いています。
今回見つかったのは、WordPressやプラグインの穴とは別の、PHPそのものの穴です。
そのため、サイトの中身が何で作られていても、PHPで動いていれば対象になり得ます。
何が起きるおそれがあるのか
IPAは注意喚起の概要で、影響を次のように書いています。
「これらの脆弱性を悪用された場合、遠隔の第三者によって、任意のコード実行が実行される可能性があります。」
平たく言えば、外から細工した通信を送られるだけで、サーバーの上で相手の好きなプログラムを動かされるおそれがある、ということです。
ログインのパスワードを知られていなくても起こり得る点が、ふだんの「パスワードを強くしましょう」という対策と違うところです。
動かされたプログラムで、サイトを書き換えられたり、問い合わせフォームに入ったお客様の情報を抜かれたりする事態が考えられます。
2つの脆弱性の中身
PHPの公式サイトの告知によると、2件の番号と原因は次のとおりです。
1つ目はCVE-2026-109618で、メモリが足りなくなったときのエラー処理に原因があります。
2つ目はCVE-2026-109619で、前の通信で使ったメモリの情報が、次の通信まで残ってしまうことに原因があります。
IPAの注意喚起によると、1つ目はメモリ不足のときのエラー処理に、2つ目は通信の受け付けの処理に関わる脆弱性だと整理されています。
サイトの持ち主が仕組みを細かく理解する必要はありません。
押さえておくのは、サイトの作りが丁寧でも、PHPの版が古いままなら穴は残るという1点です。
深刻度9.2が意味すること
GitHubに公開された2件のアドバイザリでは、深刻度はどちらも最も重い「重大」の区分で、点数は共通の評価の物差しであるCVSSの第4版で10点満点の9.2です。
同じアドバイザリでは、攻撃に必要な権限は「なし」、利用者の操作も「なし」とされています。
つまり、管理画面に入られていなくても、誰かがリンクを踏まなくても、攻撃が成り立つ条件がそろっているということです。
一方で、攻撃の難しさは「高い」、攻撃が成り立つ前提条件も「あり」と評価されています。
誰でも簡単に乗っ取れるという話ではありませんが、条件が合えば外から実行される、という読み方が近いと思います。
| 項目 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 原因 | メモリ不足のときのエラー処理 | 前の通信の情報が次の通信に残る |
| 深刻度（CVSS第4版） | 9.2（重大） | 9.2（重大） |
| 攻撃に要る権限 | なし | なし |
| 利用者の操作 | 不要 | 不要 |
| 起こり得ること | サーバー上で任意のプログラムを動かされる | サーバー上で任意のプログラムを動かされる |
| 根本の対策 | 修正済みの版に更新する | 修正済みの版に更新する |
公表から2週間で起きたこと
今回の件は、公表のあとも情報が数日おきに足されています。
古い情報だけを見て判断すると、対応の急ぎ具合を読み違えるので、日付の順に並べておきます。
| 日付（2026年） | 出来事 | サイトの持ち主にとっての意味 |
|---|---|---|
| 10月21日 | PHPの開発チームが修正済みの4つの版を公開し、告知を出す | この日以降に更新していない環境は対象のまま |
| 10月22日 | IPAとJPCERT/CCが注意喚起を公開 | 国内の公的機関が、対策を急ぐよう求めた |
| 10月23日 | PHPの開発チームが、別の条件で起きる3件目（CVE-2026-115560）を公表 | 設定の変更で防ぐよう案内。修正は通常の更新で行う方針 |
| 10月26日（米国時間） | 米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が、悪用が確認された脆弱性の一覧に2件を掲載 | 「穴がある」段階から「実際に使われている」段階に進んだ |
| 10月29日 | JPCERT/CCが注意喚起を更新し、ある製品で侵害の成功を示す痕跡が報告されたと追記 | ウェブサイト以外の、PHPを組み込んだ機器も狙われ始めた |
悪用が確認された脆弱性の一覧に載った
IPAは10月27日に注意喚起を更新し、次のように追記しました。
「IPAでは国内での攻撃被害の事例については把握しておりませんが、改めて本件情報をご確認のうえ、対策済みバージョンへの移行を進めるようお願いいたします。」
国内の被害はまだ把握されていない、という言い方ですが、米国の機関が「悪用された脆弱性」として一覧に載せたことを受けた更新です。
「被害の話を聞かないから様子を見る」という判断は、この時点で取りにくくなったと考えたほうがよいでしょう。
被害は、公表されるまでに時間がかかるのが普通です。
攻撃された側が気づくまでに日数がかかり、気づいてから調べ終えるまでにも日数がかかるからです。
試す人が増えている
JPCERT/CCは、注意喚起の概要で次のように書いています。
「本脆弱性を悪用できると主張する実証コードが多数公開されているほか、本脆弱性の悪用を試みる通信を観測したとの報告も相次いでいます。」
実証コードとは、穴が本当に使えることを示すためのプログラムです。
それが出回っているということは、腕の立つ攻撃者でなくても試せる状態に近づいている、ということです。
同じ注意喚起は、実際にプログラムを動かせるかどうかは、PHPの版や動かしている環境などの条件に左右されるとも書いています。
条件次第で成功しないこともある、という情報は安心材料になりそうに見えますが、自社の環境がどちらに当たるかは外から分かりません。
ウェブサイト以外の機器にも広がった
10月29日に更新されたJPCERT/CCの注意喚起によると、あるファイアウォール製品の特定の版で、侵害の成功を示す痕跡が見つかったという報告が出ています。
報告では、今回の脆弱性と、Linuxの権限を引き上げる別の脆弱性を組み合わせた攻撃の道具が作られていたとされています。
PHPは、ルーターやネットワーク機器の管理画面の中で使われていることもあります。
JPCERT/CCは同じ注意喚起で「なお、PHPを使用する製品やLinuxディストリビューションが提供するPHPも、本脆弱性の影響を受ける可能性があります。」と書いています。
社内のネットワーク機器のメーカーからお知らせが届いていないかも、あわせて確かめておくと安心です。
対象になる版と修正済みの版
PHPには「8.4」「8.3」のような系統があり、それぞれの系統の中で「8.4.27」のように細かい番号が上がっていきます。
今回の修正は、いま開発チームがサポートしている4つの系統に出ています。
| 使っている系統 | 対象になる版 | 修正済みの版 | 次にすること |
|---|---|---|---|
| 8.5系 | 8.5.12より前 | 8.5.12 | 8.5.12以降に更新する |
| 8.4系 | 8.4.27より前 | 8.4.27 | 8.4.27以降に更新する |
| 8.3系 | 8.3.36より前 | 8.3.36 | 8.3.36以降に更新する |
| 8.2系 | 8.2.35より前 | 8.2.35 | 8.2.35以降に更新し、年内に8.3以降へ移る段取りを組む |
| 8.1以前（7.4、8.0、8.1など） | 開発チームの更新が終わっている | 正式な修正版は出ない | サポートされている系統へ移る。移れない間の扱いを決める |
8.1以前は「直る版」が出ない
PHPの公式の告知によると、8.1以前の系統はもう開発チームからの更新を受けられません。
ただ、今回は深刻さを考えて、7.4、8.0、8.1向けに最小限の修正のもとになるプログラムが用意されました。
これは、自分でPHPを組み立てられる技術者や、長期サポートの事業者向けの材料です。
レンタルサーバーでサイトを動かしている会社が、自分で当てられる種類のものではありません。
8.1以前を使っている会社にとっての現実的な道は、サポートされている系統へ移ることです。
移るまでの間をどうしのぐかは、このあとの「8.1以前を使っていた場合の進め方」で説明します。
PHP 5.4以降は少なくとも1件の影響を受ける
IPAは、調査に関わったセキュリティ企業の情報として、PHP 5.4以降の版はどちらかの脆弱性の影響を少なくとも受けると紹介しています。
PHP 5.4が出たのは10年以上前です。
「古いから狙われない」ことはなく、古い版ほど直す手段が限られる、と考えておくのが現実的です。
調査に関わったセキュリティ企業は、報告の題に「AIが見つけた、インターネットの70%に影響する重大な遠隔コード実行の脆弱性」（英語の題をこちらで和訳）と付けています。
70%という数字はその企業の見立てなので、ここでは「対象になるサイトがとても多い」という程度に受け取っておけば十分です。
Windowsで動かしている場合の追加の告知
10月26日には、Windows向けに配られているPHPの組み立て済みの版が、もう一度配り直されました。
中に含まれる圧縮データを展開する部品に、別の脆弱性が見つかったためです。
版の番号の末尾に「-1」が付いたものが新しい配布物で、PHPそのものの中身は変わっていないと説明されています。
社内のWindowsのサーバーでPHPを動かしている会社は少数だと思いますが、該当する場合は担当者に伝えておきましょう。
自社のサイトがPHPで動いているかを確かめる
最初の分かれ道は、自社のサイトがそもそもPHPで動いているかどうかです。
ここで「動いていない」と言い切れれば、今回の件でサイトについてやることはほとんどありません。
WordPressで作ったサイトは必ずPHPで動いている
管理画面のアドレスが「/wp-admin/」で終わるなら、そのサイトはWordPressです。
WordPressはPHPで書かれているので、この場合は「PHPで動いている」が答えになります。
WordPress以外にも、国内で使われている業務用の仕組みやネットショップの仕組みには、PHPで作られたものが少なくありません。
見た目では分からないときの手がかり
ページのアドレスの末尾が「.php」になっていれば、PHPで動いている可能性が高いと言えます。
ただし、末尾に「.php」が無いからといってPHPではないとは限りません。
WordPressも、ふつうの設定ではページのアドレスに「.php」を出さないからです。
見た目で判断がつかないときは、次の節の「誰が管理しているか」から当たるほうが早く済みます。
サイト以外でPHPが動いている場所
見落としやすいのは、ホームページ以外の仕組みです。
予約の受付、会員ページ、社内の日報や在庫の管理画面などを、制作会社に作ってもらった会社は多いと思います。
それらがPHPで作られていれば、ホームページと同じく対象になり得ます。
このあと作る確認の一覧には、ホームページだけでなく、外から見える仕組みをすべて書き出しておきましょう。
たとえば、採用ページだけ別の会社に作ってもらった、というケースもよくあります。
見積もりのフォームや資料請求のページが、ホームページと別のサーバーで動いていることもあります。
請求書の宛先や毎月の引き落としを見直すと、忘れていた契約が見つかることがあります。
| 自社の状況 | PHPで動いている見込み | 次にすること |
|---|---|---|
| WordPressでサイトを作った | 確実に動いている | PHPの版を確かめる |
| ページのアドレスが「.php」で終わる | 高い | PHPの版を確かめる |
| 制作会社が独自に作った予約や会員の仕組みがある | 作り方による | 制作会社に何で作ったかを聞く |
| クラウド型のサイト作成サービスで作った | 提供会社の側の話になる | 提供会社のお知らせを確かめる |
| 何で作ったか分からない | 分からない | 契約書と請求書から委託先をたどる |
PHPの版を確かめる方法
PHPで動いていると分かったら、次は版の番号です。
番号が分かれば、先ほどの表に当てはめるだけで、対象かどうかが決まります。
確かめた番号は、確かめた日付と一緒にメモしておきましょう。
あとで委託先から「更新しました」と連絡が来たとき、前と後の番号を比べれば、本当に上がったかを自分で確かめられます。
WordPressなら管理画面のサイトヘルスで見られる
WordPressの管理画面で「ツール」から「サイトヘルス」を開き、「情報」のタブを選びます。
「サーバー」の項目を開くと、PHPのバージョンが「8.3.36」のような形で表示されます。
管理者の権限で入っていないと見られない項目があるので、表示されなければ管理者の担当者に頼みましょう。
同じ画面の「ステータス」のタブには、PHPが古いときに注意が出ることもあります。
レンタルサーバーの管理画面で見る
レンタルサーバーを使っている場合、たいていは管理画面に「PHPのバージョン設定」のような項目があります。
ここで見えるのは「8.3」のような系統までで、細かい番号は出ないこともあります。
系統しか見えないときは、サーバー会社のお知らせで、その系統を修正済みの版に上げたかどうかを確かめます。
サーバー会社によっては、ドメインごとに別の系統を選べるので、複数のサイトを持っている会社はサイトごとに見てください。
確認用のページを公開したままにしない
PHPの版を調べる方法として、設定の一覧を表示するページを置くやり方が紹介されることがあります。
このページには、サーバーの細かい設定がそのまま表示されます。
攻撃する側にとっては、どの穴が使えるかを調べる手間が省ける情報です。
使う場合は確認が済んだらすぐに消し、消したことを担当者と確かめ合いましょう。
WordPressの推奨と今回の対象を並べて見る
WordPressの公式サイトの動作要件では、推奨は「PHP 8.3以上」です（英語の原文をこちらで和訳）。
同じページには、古い環境向けにPHP 7.4以上でも動くとしたうえで、それらの版は公式のサポートが終わっており、サイトを脆弱性にさらすおそれがあるという注意も書かれています。
WordPressが動いているからPHPも大丈夫、とは言えないということです。
| 見えた版 | 今回の判定 | 次にすること |
|---|---|---|
| 8.5.12以降／8.4.27以降／8.3.36以降 | 今回の2件は修正済み | 3件目の設定の案内が反映されているかを委託先に確かめる |
| 8.2.35以降 | 今回の2件は修正済み | 年末のサポート終了に向けて、8.3以降へ移る日を決める |
| 8.2〜8.5系で修正前の版 | 対象 | すぐに更新を頼む |
| 8.1以前 | 対象で、正式な修正版が出ない | 移行の段取りと、それまでの扱いを決める |
| 系統しか分からない | 判定できない | サーバー会社のお知らせか委託先の回答で確かめる |
誰が更新するかはサイトの置き場所で決まる
PHPの版を上げるのは、サイトの持ち主とは限りません。
サイトをどこに置いているかで、更新する人も、持ち主がすることも変わります。
| サイトの置き場所 | PHPの本体を更新する人 | 持ち主がすること |
|---|---|---|
| レンタルサーバー（共用） | ふつうはサーバー会社 | 管理画面で選んでいる系統が8.2以降か、8.1以前を選んだままでないかを見る |
| 仮想サーバーやクラウドのサーバーを自社で契約 | 契約した側（自社か委託先） | 誰がOSとPHPを更新する契約になっているかを確かめる |
| 制作会社のサーバーに置いてもらっている | 制作会社 | 制作会社に対応状況を文書で聞く |
| クラウド型のサイト作成サービス | サービスの提供会社 | 提供会社のお知らせを確かめる |
| 社内に置いたサーバー | 自社 | 担当者に更新の日時と、更新後の版を報告してもらう |
レンタルサーバーでも「選んだ系統」は持ち主の責任になりやすい
共用のレンタルサーバーでは、PHPの本体の更新はサーバー会社が行うのが一般的です。
一方で、どの系統を使うかは、利用者が管理画面で選ぶ形になっていることが多くあります。
サイトを作った当時に7.4や8.0を選び、そのまま何年も触っていない、というのはよくある話です。
サーバー会社によっては、古い系統を選んだままのサイトに、メールや管理画面でお知らせを出していることもあります。
そのお知らせが、退職した担当者のメールアドレスに届き続けている、ということも起こり得ます。
サーバーの契約の連絡先が、今いる担当者になっているかも、この機会に確かめておきましょう。
その場合、サーバー会社が8.3や8.4を直しても、自社のサイトは古い系統のまま残ります。
契約書に「保守」とあっても中身はさまざま
制作会社との契約に「保守」と書いてあっても、その範囲は会社によって違います。
文章の差し替えだけを指す契約もあれば、WordPressとプラグインの更新までを含む契約もあります。
PHPの版を上げる作業が含まれているかどうかは、契約書の文言を見ないと分かりません。
分からなければ、次の節の文面で聞いてしまうのが早道です。
クラウド型のサイト作成サービスで作ったサイトは、PHPの版をこちらで選ぶ仕組みになっていないことがほとんどです。
その場合は、提供会社のお知らせのページに、今回の件への対応が書かれているかを見れば足ります。
社内にサーバーを置いている会社は、更新の作業も確認の責任も自社にあります。
担当者が1人しかいない場合は、その人が休んでいる間に誰が判断するかも決めておくと安心です。
ここまでの確認を、1本の流れにまとめると次のようになります。
委託先やサーバー会社への聞き方
自分で版を見られない場合や、見えても判断に自信がない場合は、管理している相手に聞くのが確実です。
そのとき「大丈夫ですか」とだけ聞くと、「大丈夫です」という返事しか返ってこないことがあります。
返事を見て判断できるよう、聞く項目を先に決めておきましょう。
聞く項目は4つ
1つ目は、自社のサイトや仕組みが使っているPHPの版の番号です。
2つ目は、修正済みの版に更新したかどうかと、更新した日です。
3つ目は、10月23日に案内された3件目への設定が入っているかどうかです。
4つ目は、攻撃を受けた痕跡が無いかを調べたかどうかと、調べた範囲です。
4つとも、答えが番号か日付か「はい・いいえ」で返ってくる聞き方にしてあります。
答えの形が決まっていると、委託先も調べる範囲がはっきりするので、返事が早く届きやすくなります。
| 聞く項目 | 判断できる返事の例 | もう一度聞いたほうがよい返事 |
|---|---|---|
| 使っているPHPの版 | 「8.4.27です」と番号で返ってくる | 「最新です」「新しいものです」 |
| 更新したかと更新日 | 「10月22日に更新しました」 | 「順次対応しています」 |
| 3件目への設定 | 「設定を変えて、すべての処理を再起動しました」 | 「影響はないと思います」 |
| 痕跡の調査 | 「通信の記録を10月1日までさかのぼって見ました」 | 「特に問題は出ていません」 |
| 8.1以前だった場合の方針 | 「12月までに8.4へ移す見積もりを出します」 | 「今のところ動いているので大丈夫です」 |
そのまま送れる文面の例
次の文面は、委託先にメールで送ることを想定した例です。
会社名やサイトのアドレスは、自社のものに置き換えてください。
件名は「PHPの脆弱性（10月21日公表）への対応状況のご確認」とし、本文には次の4点を並べます。
「1. 弊社サイト（アドレス）と予約ページが使っているPHPの版の番号」
「2. 修正済みの版（8.5.12、8.4.27、8.3.36、8.2.35のいずれか以降）への更新の有無と更新日」
「3. 10月23日に案内された設定の変更の有無」
「4. 攻撃の痕跡の調査の有無と、調べた期間」
最後に「8.1以前をお使いの場合は、移行の方法と時期のご提案をお願いします」と添えておくと、次の話につながります。
返事が「大丈夫です」だけだったとき
返事に番号も日付も入っていないときは、遠慮せずにもう一度聞いてください。
相手を疑うための質問とは違います。
自社としてどこまで確認したかを記録に残すためです。
取引先や役員から「うちは大丈夫か」と聞かれたとき、番号と日付があれば一言で答えられます。
返事そのものが来ない場合は、保守の契約が切れている可能性も考えましょう。
届いた返事は、メールのまま放っておかず、確認した日付と一緒に1枚の表にまとめておきます。
表にしておけば、サイトが複数あるときも、どれが済んでいてどれが残っているかが一目で分かります。
次に同じような注意喚起が出たときも、この表がそのまま確認の出発点になります。
8.1以前を使っていた場合の進め方
いちばん困るのは、版を確かめたら8.1以前だった、という場合です。
この場合、更新のボタンを押すだけでは終わりません。
サイトの作り直しに近い作業が要ることがあります。
IPAは注意喚起の中で、修正対応が難しい場合の考え方を6つの手順にまとめています。
なぜ古い版の更新は難しくなるのか
IPAは、更新が難しくなる理由を次のように書いています。
「PHPなどを長期間更新していないシステムでは、更新に伴うアプリケーションの改修や動作確認が必要となるほか、開発時の資料・ノウハウの不足、担当者の不在、保守契約の終了などにより、対策が難しくなっている場合があります。」
中小企業のサイトで当てはまりやすいのは、後半の「担当者の不在」と「保守契約の終了」です。
作った制作会社が廃業している、当時の担当者が辞めている、という話は珍しくありません。
IPAが示す6つの手順
IPAの6つの手順を、中小企業のサイトに当てはめると次の表のようになります。
| IPAの手順 | 中小企業のサイトで言うと | 決める人 |
|---|---|---|
| 1. サポート状況を確認する | PHPの版が8.1以前かどうかを確かめる | 担当者 |
| 2. 更新・移行までの暫定対策を講じる | 委託先に、つなぎの設定やアクセスの制限ができるかを聞く | 担当者と委託先 |
| 3. システムの状況と難易度を把握する | そのサイトや仕組みで今も問い合わせや予約が来ているかを見る | 担当者 |
| 4. 組織として実現性を検討する | 移行と、その後の保守に払える費用と人手があるかを話し合う | 経営者 |
| 5. 今後の方針を決める | 移す、機能を減らす、公開を終える、のどれにするかを決める | 経営者 |
| 6. 影響を考えて実施する | お客様への案内と、残すデータの移し先を決めてから作業する | 担当者と委託先 |
経営者が決めることが入っている
6つの手順のうち4つ目について、IPAは次のように書いています。
「システム管理担当者だけでなく、事業責任者や経営層も含め、更新・移行の実施と、その後の継続的な維持管理に必要な人員・予算・保守体制を確保できるか検討してください。」
サイトの担当者だけで抱えず、経営者が判断する話として扱ってほしい、という意味だと読めます。
担当者の方は、この表と委託先からの返事をそろえて、経営者に判断を仰ぐ形にすると話が進みやすくなります。
「閉じる」も選択肢に入っている
5つ目の手順で、IPAは次のように書いています。
「体制を確保する見通しが立たない場合は、現行システムの継続を前提とせず、保守を受けられる製品・サービスへの移行、提供機能の縮小、公開の終了やシステムの廃止も含めて検討してください。」
何年も更新していない会員ページや、使われていない古いキャンペーンのページは、この機会に閉じるほうが安全なこともあります。
問い合わせがほとんど来ていない仕組みなら、閉じても売上への影響は小さく、守る対象を減らせます。
閉じるかどうかの判断には、アクセス解析で直近1年の訪問数と問い合わせの件数を見るのが手早い方法です。
数字を委託先からの見積もりと並べれば、移行にかける費用に見合うかどうかを経営者が判断しやすくなります。
閉じる場合も、残すべきお客様のデータの移し先と、お客様への案内の文面を先に用意しておきましょう。
8.2系は2026年12月31日でサポートが終わる
今回の修正で8.2.35に上げた会社も、安心しきるのは早いかもしれません。
PHPの公式サイトが公表した「サポートしている版」の一覧によると、8.2系のセキュリティの修正は2026年12月31日までです。
あと2か月ほどで、8.2系も「直る版が出ない」側に移るということです。
| 系統 | 最初の公開 | セキュリティの修正が出る期限 | いま使っている会社がすること |
|---|---|---|---|
| 8.2 | 2022年12月8日 | 2026年12月31日 | 年内に8.3以降へ移る日を決める |
| 8.3 | 2023年11月23日 | 2027年12月31日 | 来年中の移行を計画に入れる |
| 8.4 | 2024年11月21日 | 2028年12月31日 | 修正版への更新を続ける |
| 8.5 | 2025年11月20日 | 2029年12月31日 | 修正版への更新を続ける |
| 8.1以前 | 2021年以前 | すでに終了 | サポートされている系統へ移る |
年末の移行は混み合うと考えておく
8.2系を使っている会社が一斉に動けば、制作会社の手が空かない時期が出てきます。
移行には、WordPressのテーマやプラグインが新しい系統で動くかを確かめる時間も要ります。
今回の確認のついでに、8.3以降へ移る日と費用の見積もりを委託先に頼んでおくと、年末に慌てずに済みます。
次の系統の8.6も準備が進んでいる
PHPの公式サイトでは、10月21日に次の系統8.6の試験版（RC4）が公開され、今回の修正も含まれていると案内されています。
同じ告知では、試験版は本番のサイトで使わないようにと書かれています。
新しい系統が出たからといってすぐに飛びつく必要はなく、サポート期間の長い8.4か8.5を移行先の候補にするのが落ち着いた選び方です。
更新までのつなぎの設定は「安全にする」ものにならない
すぐに更新できないときのために、PHPの開発チームはいくつかの設定の変更を案内しています。
ただ、公式の告知は、この設定で安全になるわけではないと、はっきり断っています。
告知の該当箇所を和訳すると「更新だけが完全な解決策であり、以下の対策は特定の攻撃経路にさらされる度合いを下げるが、環境を安全にはしない」という内容です（英語の原文をこちらで和訳）。
案内されている設定の中身
1つ目の脆弱性には、PHPが使えるメモリの上限や、一度に受け取るデータの大きさの上限を変えるといった設定が案内されています。
2つ目の脆弱性には、ファイルの送信の進み具合を記録する機能を止め、すべての処理を再起動するという設定が案内されています。
どちらも、サーバーの設定ファイルを書き換える作業です。
サイトの持ち主が自分で行う作業とは違い、委託先かサーバー会社に頼む種類の作業になります。
3件目は設定で防ぐ方針
10月23日に公表された3件目（CVE-2026-115560）について、PHPの開発チームは、起きるには珍しい設定とプログラムの組み合わせが要ると説明しています。
そのため、急ぎの修正版は出さず、次の通常の更新で直す方針です。
それまでは、2つ目の脆弱性で案内された「ファイルの送信の進み具合を記録する機能を止める」設定を続けるよう勧めています。
JPCERT/CCも、この設定がすでに入っていれば追加の対応は要らないとしています。
委託先に聞くときは「10月23日の案内の設定も入っていますか」と日付を添えると、話が通じやすくなります。
| やったこと | 防げる範囲 | 残る心配 | 次にすること |
|---|---|---|---|
| 修正済みの版に更新した | 今回の2件の根本 | 3件目は通常の更新待ち | 3件目の設定が入っているかを確かめる |
| つなぎの設定だけを入れた | 確認された一部の攻撃経路 | ほかの攻撃経路が残る | 更新の日を決める |
| アクセスを社内や特定の相手に限った | 外から届く攻撃の大部分 | 許した相手の側から来る攻撃 | 更新か移行の日を決める |
| 何もしていない | なし | すべて | 今日中に委託先に連絡する |
| サイトを一時的に止めた | 止めている間の攻撃 | 再開したときに同じ状態に戻る | 再開する前に更新を済ませる |
止めるという判断もある
IPAは、2つ目の手順の中で次のように書いています。
「更新や移行が完了するまで、脆弱な状態での運用を放置せず、利用環境に応じた暫定対策やアクセス制限を検討してください。」
続けて、有効な暫定対策が取れない場合は、外からのアクセスを遮ることや、サービスを一時的に止めることも判断するよう求めています。
集客のためのサイトを止めるのは痛いですが、乗っ取られたサイトからお客様に迷惑をかけるよりは傷が浅く済みます。
止める場合は、お知らせのページだけを残し、電話やメールの問い合わせ先を書いておけば、お客様との連絡は途切れません。
止める期間と再開の条件を先に決めておくと、ずるずると止めたままになるのも防げます。
すでに攻撃を受けていないかを調べる
修正済みの版に更新しても、更新する前に入り込まれていたら、その痕跡は残ったままです。
JPCERT/CCは注意喚起で、発見者らの情報をもとに、攻撃を受けた可能性を調べるための3つの点を挙げています。
| 調べる点 | どこを見るか | 見つかったときにすること |
|---|---|---|
| 利用者を見分けるためのクッキーに、不自然に長い値や形のおかしい値を入れて返していないか | サーバーの通信の記録 | 記録を保全し、委託先に調査を頼む |
| 不審なファイル送信の形式の通信が無いか、その前後にメモリ上限のエラーやエラー画面（500番）が出ていないか | サーバーの通信の記録とエラーの記録 | 同じ時間帯のほかの記録もあわせて保全する |
| PHPの処理が予期せず止まったり、何度も再起動したりしていないか | サーバーの動作の記録 | 止まった時刻を一覧にして委託先に渡す |
| 見覚えのないファイルが増えていないか | サイトのファイルの一覧 | 消さずに残し、調べてもらう |
| サーバーから見知らぬ相手への通信が出ていないか | サーバー会社や委託先の監視 | サイトを外から切り離す判断をする |
痕跡が無くても安全とは言い切れない
JPCERT/CCは、調査の結果について次のように念を押しています。
「上述の痕跡が確認されない場合でも、本脆弱性を悪用した攻撃を受けていないと断定することはできません。」
攻撃の方法や、記録をどこまで残す設定にしていたかによって、痕跡が残らない場合があるからです。
レンタルサーバーでは、通信の記録が残る期間が決まっていて、古い記録から順に消えていくことがあります。
10月21日より前の記録が消えてしまう前に、委託先かサーバー会社に保存を頼んでおくと、後から調べ直せます。
調査は「やったかどうか」を記録として残し、そのうえで修正済みの版への更新と、その後の見張りを続けるのが現実的な線です。
疑わしいものが見つかったら先に保全する
JPCERT/CCは、侵害が疑われる場合は、関係する記録などの証拠を保全したうえで、影響の範囲を調べたり、そのシステムを切り離したりするよう勧めています。
慌ててファイルを消したりサーバーを作り直したりすると、何が起きたかを後から調べられなくなります。
お客様の情報が漏れた可能性がある場合は、個人情報保護委員会への報告が必要になることもあるので、記録を残しておく意味はさらに大きくなります。
更新でサイトが表示されなくならないための段取り
PHPの系統を上げると、古いテーマやプラグインが動かなくなり、画面が真っ白になることがあります。
これを恐れて更新を先延ばしにしている会社もあると思いますが、段取りを踏めば止まる時間は短くできます。
更新の前に必ずバックアップを取る
サイトのファイルとデータベースの両方を、更新の直前に保存しておきます。
レンタルサーバーには自動のバックアップがあることが多いものの、どこまでさかのぼって戻せるかは契約によって違います。
戻し方を一度も試したことがないなら、更新の前に委託先と手順を確かめておきましょう。
更新の作業は、問い合わせや予約が少ない時間帯に行ってもらうと、万一止まったときの影響を抑えられます。
お客様が多く訪れる時期に移行が重なる場合は、先に同じ系統の中の更新だけを済ませ、系統をまたぐ移行は落ち着いた時期に回すという分け方もあります。
同じ系統の中の更新と、系統をまたぐ移行を分けて考える
8.4.26から8.4.27に上げるような同じ系統の中の更新は、ふつうは表示への影響が小さく済みます。
7.4から8.4に移るような系統をまたぐ移行は、テーマやプラグインの書き換えが要ることがあります。
前者は今すぐ、後者は試験用の環境で確かめてから、と分けて頼むと、委託先も動きやすくなります。
| 作業 | 例 | 表示が崩れる心配 | 頼み方 |
|---|---|---|---|
| 同じ系統の中の更新 | 8.4.26から8.4.27へ | 小さい | 今すぐ行い、更新後の版を報告してもらう |
| 1つ上の系統への移行 | 8.2から8.3へ | 中くらい | テーマとプラグインの対応を確かめてから行う |
| いくつも系統をまたぐ移行 | 7.4から8.4へ | 大きい | 試験用の環境で動かしてから本番に移す |
| サイトの作り直し | 古い独自の仕組みを新しい仕組みに移す | 作り直しになる | 移すページと閉じるページを先に決める |
プラグインの数を減らす機会にする
系統をまたぐ移行で動かなくなるのは、更新が止まったプラグインであることが多いです。
何年も更新されていないプラグインは、今回の件とは別に、それ自体が穴になり得ます。
WordPressの管理画面のプラグインの一覧では、それぞれのプラグインが最後に更新された時期を、配布元のページから確かめられます。
2年以上更新が止まっているものは、代わりのプラグインに入れ替えられないかを委託先に相談してみましょう。
使っていないプラグインはこの機会に止めて消し、守る対象を減らしておきましょう。
AIが脆弱性を見つける時代にサイトの持ち主が変えること
今回の脆弱性は、調査にAIが使われたことでも注目されました。
調査に関わったセキュリティ企業が報告の題に「AIが見つけた」と入れたのは、先に紹介したとおりです。
見つける側にAIが使われるようになると、サイトの持ち主にも影響が出てきます。
見つかる数が増えれば更新の回数も増える
AIを使って穴を探せるようになれば、PHPに限らず、これまで見落とされていた穴が見つかる回数は増えていくと考えられます。
見つかれば修正版が出て、修正版が出れば更新が要ります。
年に1回の点検で間に合っていた会社も、お知らせを受け取ってから数日のうちに動ける形に変える必要が出てきます。
そのためには、注意喚起を受け取る窓口を社内で1人決めておくことが近道です。
IPAやJPCERT/CCは注意喚起をホームページで公開しているので、担当者がそこを週に1度見るだけでも、気づくまでの日数は縮みます。
守る側にもAIを使う動きは広がっていますが、中小企業のサイトで最後に効くのは、誰が受け取り、誰に頼み、いつまでに直すかが決まっていることです。
修正版が出た直後が危ない
修正版が公開されると、直す前と直した後の違いから、穴の場所を逆算できるようになります。
今回も、10月末までに、悪用を試みる通信を観測したという報告が相次ぎました。
「修正版が出たから、そのうち委託先がやってくれるだろう」と待っている間が、いちばん狙われやすい期間です。
保守の契約に入れておきたいこと
今回の件をきっかけに、委託先との契約を見直す会社もあると思います。
そのとき、次の表の項目が契約に入っているかを確かめておくと、次に同じことが起きたときに慌てずに済みます。
| 契約で決めておくこと | 決めていないと起きること | 決め方の例 |
|---|---|---|
| PHPの版の更新が保守に含まれるか | 誰も更新しないまま年が過ぎる | 「PHPとWordPressとプラグインの更新を含む」と書く |
| 重大な脆弱性のときに何日で対応するか | 順番待ちのまま狙われる | 「公的機関が注意喚起を出したら3営業日以内」 |
| 対応したことの報告の形 | やったかどうかが分からない | 「更新後の版の番号と日付をメールで報告」 |
| 系統のサポートが終わる前の提案 | 年末に慌てて移行する | 「サポート終了の半年前までに移行の見積もりを出す」 |
| 攻撃が疑われるときの初動 | 証拠が消える | 「記録を保全してから復旧に入る」 |
よくある質問
WordPressを最新にしていれば今回の件は大丈夫ですか
大丈夫とは言えません。
今回の穴はPHPそのものにあるので、WordPressの本体やプラグインを最新にしても、その下で動くPHPが古ければ対象のままです。
WordPressの更新とPHPの更新は別の作業だと考えてください。
WordPressの本体の自動更新が有効になっていても、PHPの版は自動では上がりません。
管理画面の更新の通知が消えているからといって、サーバーの側まで新しいとは限らない点に気をつけましょう。
レンタルサーバーを使っていれば自動で直りますか
サーバー会社がPHPの本体を直していても、管理画面で古い系統を選んだままだと、自社のサイトは古い系統で動き続けます。
管理画面で選んでいる系統と、サーバー会社のお知らせの両方を確かめてください。
系統の切り替えは管理画面から数回の操作でできることが多いものの、切り替えた直後に表示が崩れることもあります。
自分で切り替える前に、バックアップの取り方と元に戻す方法を確かめておきましょう。
小さな会社のサイトでも狙われますか
今回のような穴を狙う攻撃は、相手の会社の大きさを見て選ぶものとは限りません。
インターネットに公開されているサーバーを片端から調べ、条件に合うところを探す形の攻撃もあるからです。
JPCERT/CCは「JPCERT/CCでは、当該製品が国内で広く利用されていることを確認しています。」と書いており、国内でも同じ条件にあるサイトは少なくないと見ておくべきでしょう。
更新するとサイトの表示が崩れませんか
同じ系統の中の更新なら、表示への影響は小さいことが多いです。
系統をまたぐ移行は、テーマやプラグインの対応によっては崩れることがあるので、バックアップを取り、試験用の環境で確かめてから本番に移してもらいましょう。
委託先と連絡が取れないときはどうすればよいですか
まずサーバーの契約者が誰かを確かめ、自社が契約者ならサーバー会社に直接問い合わせます。
自社に管理画面へ入る権限が無い場合は、ほかの制作会社に調査を頼むことも考えましょう。
それも難しい場合は、IPAの手順にあるとおり、外からのアクセスを止めるか、サイトの公開を一時的に止めることも選択肢に入ります。
まとめ
2026年10月21日に公表されたPHP2Shellは、PHPそのものにある2つの脆弱性で、深刻度はどちらも10点満点の9.2です。
10月26日には米国の機関が悪用の確認された脆弱性の一覧に載せ、10月29日には侵害の成功を示す痕跡の報告も出ました。
サイトの持ち主がすることは、PHPで動いているかを確かめ、版の番号を確かめ、管理している相手に番号と日付で答えてもらうことです。
8.2〜8.5系なら修正済みの版に上げ、8.2系は年内に8.3以降へ移る日も決めます。
8.1以前なら、IPAの6つの手順に沿って、移す、機能を減らす、公開を終える、のどれにするかを経営者が決めます。
更新が済んだら、痕跡の調査をした記録を残し、次に同じことが起きたときに数日で動ける契約に変えておきましょう。
今日できる点検
最後に、今日のうちに手を付けられる点検を表にまとめます。
上から順に進めれば、自社のサイトがどの段階にあるかが分かります。
全部を今日中に終える必要はありませんが、委託先への連絡だけは今日のうちに送っておくと、返事を待つ間に残りの点検を進められます。
| 点検すること | 見る場所 | 今日の目標 |
|---|---|---|
| 外から見える自社の仕組みを書き出す | 契約書、請求書、ブックマーク | ホームページ、予約、会員ページなどの一覧ができている |
| それぞれがPHPで動いているかを確かめる | 管理画面のアドレス、委託先への問い合わせ | 一覧の横に「PHP」「違う」「不明」が書けている |
| PHPの版の番号を確かめる | WordPressのサイトヘルス、サーバーの管理画面 | 番号か、少なくとも系統が分かっている |
| 委託先に4つの項目を送る | メール | 送信済みで、返事の期限を伝えてある |
| 8.2系と8.1以前の扱いを決める | 委託先の返事、経営者との打ち合わせ | 移行の日か、閉じる日の候補が出ている |
| ネットワーク機器のお知らせを確かめる | メーカーのお知らせ | 該当する機器があるかどうかが分かっている |
