PHPの重大な脆弱性「php2shell」で何が起きたか|個人店・中小企業が今日やること

PHPの重大な脆弱性「php2shell」で何が起きたか|個人店・中小企業が今日やること

2026年10月21日の夜、多くのホームページの裏側で動いているプログラムPHPに重大な脆弱性があると公表され、修正版が出ました。翌22日にかけて、サーバー会社やネットショップ、ゲームなどが一斉に緊急メンテナンスをし、「ホームページが開かない」「サーバー会社から緊急の知らせが来た」という声が増えました。

結論:今日やることと、本当に必要なこと

先に結論だけ書きます。

図解:個人店・中小企業が今日からやる8項目のチェックリスト。まず確認する:1 サーバー会社の案内を確認(今回の対応は完了したか、自分でやることはあるか)、2 PHPを使っているか・どの版かを確認(8.1以前なら新しい版への切り替えを計画)、3 サイトが動くかを確認(表示・問い合わせフォーム・予約や注文の流れ)。次に整える:4 WordPress・プラグイン・テーマを更新(使っていないものは無効化ではなく削除まで)、5 バックアップを取り戻せるか確かめる、6 サーバーに置いてあるものを減らす(古いサイト、辞めた人のアカウント、溜め込んだデータ)。決めておく:7 連絡を受け取る人と止める判断をする人(緊急の知らせが届くメールを今も誰かが見ているか)、8 おかしいと気づいたときの初動(非公開にして保存し、サーバー会社と制作会社へ連絡)

なお、GMOグループのセキュリティ会社が注意喚起を出し、グループのサービスも対応を発表したため、「GMOが大変なことになっている」という印象を持った方もいたと思います。確認できた範囲では、GMOの会社自身が被害を受けたという発表は見つかりませんでした。GMOの名前が出てくるのは、注意喚起をした側、対応した側、「PHPを使っていないので影響なし」と発表した側です。

ここから先は、この結論の根拠です。何が起きたのか、なぜ今後も続くと考えるのか、8項目の中身、PHPを使い続ける場合の仕組みの作り方、そしてPHPに頼る範囲を減らす選び方、の順に書きます。その前に、お断りが2つあります。

そもそも「脆弱性」とは何か

脆弱性とは、プログラムの中にある、鍵のかけ忘れのような不具合のことです。普段は何も起きませんが、その不具合のある場所を知っている人は、外から入り込めてしまいます。

ホームページは、文字や画像だけでできているとは限りません。WordPress、予約フォーム、問い合わせフォーム、ネットショップなどは、サーバーの上でPHPが動いて、画面を組み立てたり、入力を受け取ったりしています。PHPそのものに鍵のかけ忘れがあると、その上で動くサイトは、どれも影響を受けるおそれがあります。

今回の件がこれまでと違うのは、WordPressのプラグインのような「追加の部品」ではなく、PHP本体の脆弱性だった点です。サーバー会社も、制作会社も、個人のお店も同じ土台を使っているため、影響が広く及びました。

2026年10月21日〜23日に何が起きたか

時系列で見る

図解:2026年10月17日から23日の時系列。10月17日、Amazonがこの脆弱性を狙った試みを検知(公開の4日前)。10月20日、PHP開発チームが21日夜11時に修正版を出すと予告し、前倒しの可能性も明記。10月21日の昼から夜にかけて、GMO Flatt Securityが公開前にできる対策を公表し、国家サイバー統括室が注意喚起。10月21日22時台、修正版(8.2.35、8.3.36、8.4.27、8.5.12)を予告より少し早く公開。10月22日、各社が緊急メンテナンスを実施し、サイトの表示を止めた会社もあった。10月23日、PHP公式が続報CVE-2026-115560を公表、この分の修正版は未公開。注記として、試みと成功した被害は別で、公的機関による被害の発表は10月25日時点で確認できていない

日本時間で、順に並べます(出典は記事末尾)。

予告より早く修正版が出たことは、頭に入れておいてください。あとの「今後も同じことが起きると考える理由」につながります。

脆弱性の中身:2件、どちらも「最も深刻」の区分

公表された脆弱性は2件で、番号はCVE-2026-109618とCVE-2026-109619です。どちらも、深刻さを表す国際的な指標(CVSS v4.0)で9.2と評価され、最も深刻な「緊急」の区分にあたります。2件を合わせて「php2shell」という通称で呼ばれています。

PHP公式の説明を、かみくだいてまとめます。

GMO Flatt Securityは、この脆弱性の発見者ではないと明記しています。公開された情報と自社の検証をもとに、「PHP 5.x系、7.x系、8.x系に広く影響すると考えるべき」という見立てと対策を公表しました。また、問題の混入は古く、PHP 5.2系や5.4系にさかのぼると推定しています。

各社の対応:公式の発表から

次の表は、各社が自分で公表した内容のうち、確認できたものだけをまとめたものです。

会社・サービス公表された内容(確認日:2026年10月25日)
GMO Flatt Security修正版の公開前に取れる対策を公表。サーバー内のデータを減らす、サーバーの持つ権限を減らす、ログの設定を見直す、サーバーを止める場合の連絡体制を決めておく、などを提案
お名前.com レンタルサーバー10月22日12時から21時の予定で緊急メンテナンスを実施し、20時45分に終了。提供中のすべてのPHPのバージョンに修正を適用。利用者がPHPのバージョンを変える必要はない。WordPressのサイトヘルスの画面では、修正済みでも従来の版番号が表示されることがある
ヘテムル10月21日の昼過ぎから順に機能を停止し、22日の未明には全サーバーでサイトの表示を停止。同日11時24分にサイトの表示を再開、12時12分に管理画面などを再開。PHP 8.2〜8.5は公式の修正版、7.4〜8.1は公式のサポート終了後に出た修正、5.6〜7.3は自社で作った修正を適用。脆弱性を悪用しようとしたとみられるアクセスの試みを確認したと記載
GMOグローバルサイン電子証明書の発行サービスは、PHPを使っていないため影響なし。製品サイトのブログとお知らせの一部ではPHPを使っていたため、10月22日0時に対策を完了
さくらインターネットクラウドサービスの一部機能の停止を発表(時事通信の報道)
ゲーム・動画など『ウマ娘 プリティーダービー』『グランブルーファンタジー』がメンテナンスを発表。ブシロード、バンダイチャンネル、ニコニコが公式サイトで緊急メンテナンスを告知(電ファミニコゲーマーの報道)

この表を読むと、GMOグループの名前が出てくるのは、注意喚起をした側、対応した側、そして「PHPを使っていないので影響がない」と発表した側です。確認できた範囲では、GMOの会社自身が被害を受けた、という発表は見つかりませんでした。

実際に悪用されたのかどうかについては、日本の公的機関が「悪用された」と発表した例は、10月25日時点で私たちが確認できた範囲では見つかりませんでした。一方で、悪用の「試み」は、複数の会社が観測しています。Amazonは、修正版の公開の4日前(10月17日)に、この脆弱性を狙った試みを検知したと発表しました。Cloudflareのマシュー・プリンスCEOは、公開の前の10時間で数千件、公開から45分で数万件、2時間で数十万件の試みを確認したと述べています(The Registerの報道)。ヘテムルのように、試みを確認した国内の会社もあります。

ただし、「試み」と「成功」は別です。Reutersによると、セキュリティ会社のHunt.ioは、10月22日(木曜)の時点では、追跡している犯罪者が実用的な攻撃の道具を作れていないように見える、と述べています。一方でPHP公式は、認証のいらないリクエストで動くエクスプロイト(脆弱性を突くプログラム)が実証されていると評価しています。「被害が確認されていない」ことは、「安全だった」ことを意味しません。

続報:10月23日の情報提供(CVE-2026-115560)

10月23日、PHP公式が、「セッションのアップロード進捗」という機能に関する情報提供を公表しました。番号はCVE-2026-115560で、完全な説明は、次の定期的な修正版のリリースと合わせて公開される予定です。公式の説明は次のとおりです。

修正版はまだ出ていません。この設定は、レンタルサーバーではサーバー会社が決めることが多い部分です。ご自身で触る前に、サーバー会社の案内を確認してください。この項目は状況が動いています。2026年10月25日時点の内容ですので、最新の案内もあわせてご確認ください。

今後も同じことが起きると考える理由(ここは考察です)

ここからは、事実ではなくこの記事の考察です。根拠にした事実は、1つずつ書きます。

根拠にした事実

専門家の見方:「毎週のように緊急対応が続く」

Reuters(2026年10月23日配信)が、サイバーセキュリティの専門家7人に取材した記事を出しています。内容をそのまま整理します。

注意してほしい点が3つあります。

そこから考えたこと

  1. 一つの穴の影響が大きくなっている。同じ部品(PHP、WordPress、共通のプラグイン)を、世界中の多くのサイトが使っています。攻撃する側にとっては、一つの手口で多くの標的に届きます。今回、サーバー会社や大きなサービスが一斉に止まったのは、その表れだと考えます
  2. 「うちは小さいから狙われない」は、通用しにくい。条件に合うサイトを自動で探して攻撃する仕組みは、会社の規模や業種を見ません。個人のお店でも、PHPが動いていて修正されていなければ、条件には当てはまります
  3. 直す側の時間は、短くなる。公開から攻撃まで数時間という世界では、「週明けに確認する」では間に合わない場面が出てきます。自分で直せなくても、誰が・いつ・何を確認するかを決めておくことが、備えの中心になります
  4. サーバー会社が直してくれるのは、土台まで。WordPress公式のセキュリティの手引き(Hardening WordPress)は、サーバー会社が責任を持つのは土台の部分で、利用者が入れたアプリケーションまでは責任を負わないことが多い、と説明しています。今回は、土台のPHPをサーバー会社が直してくれました。ただ、WordPressやプラグインの更新、使っていない古いサイトの整理は、利用者の側に残ります

図解:ホームページを支える5つの層を下から積んだ図。下から、サーバー(OS)、PHP、WordPressや予約・問い合わせフォーム、プラグイン・テーマ、サイトのデータ(記事・問い合わせの内容・顧客情報)。下の2層(サーバーとPHP)がレンタルサーバー会社が直した範囲で、今回の脆弱性はPHPの層にある。上の3層は利用者に残る範囲で、WordPressやプラグインの更新、使っていない古いサイトの整理、バックアップの確認が含まれる。根拠はWordPress公式のHardening WordPress

「また同じことが起きる」と言い切る根拠はありません。ただ、上の4つが同時に変わらない限り、程度の差はあっても、似たことは繰り返される、というのが私たちの見立てです。

個人店・中小企業が、今日からやること

冒頭の図の8項目を、順に説明します。まだやっていない場合の確認として読んでください。公表から日が経っているので、サーバー会社の修正はすでに済んでいることが多いはずですが、「済んでいるはず」と「確かめた」は別です。専門の知識がなくても、できることから並べています。①〜③は「まず確認する」、④〜⑥は「次に整える」、⑦〜⑧は「決めておく」ことです。

4コマ漫画:店主がパソコンを見て「サーバー会社から、緊急メンテナンスのお知らせ…」と不安そうにしている。担当者がホワイトボードに鍵の絵を描き「PHPという部品の鍵に、不具合が見つかりました」。ホワイトボードに、サーバー会社の案内・PHPの版・サイトの動作の3つのチェックを示し「まだなら、この3つを確認しましょう」。最後に、積み木を減らした図を見せながら「動かすものが少ないほど、直すものも少ない」

1. ご契約のサーバー会社の案内を確認する

まず、サーバー会社の「お知らせ」や、メンテナンス・障害情報のページを開いてください。確認するのは次の3点です。

案内が見つからない、読んでも分からない、という場合は、サーバー会社のサポートか、サイトを作った会社に問い合わせてください。

2. 自分のサイトがPHPを使っているか、どの版かを確認する

次のどれかに当てはまれば、PHPを使っている可能性が高いです。

使っている版を調べたら、次の図のように考えます。

図解:使っているPHPの版ごとの判断チャート。8.2から8.5の場合、修正版(8.2.35、8.3.36、8.4.27、8.5.12)が出ているので、サーバー会社が適用済みかを確認する。修正済みでも表示の版番号が変わらない会社もある。8.2を使っている場合は2026年12月31日でサポートが終わるので、8.3以上へ移る計画を立てる。8.1以前の場合、通常の修正版は出ていないサポートの終わった版で、サーバー会社が独自に修正を当てた例もあるので案内で確かめ、新しい版(WordPress公式の推奨は8.3以上)への切り替えを計画する。切り替える前にバックアップを取る。どちらの場合も、切り替えたらサイトが動くかを確認する。出典はPHP公式とWordPress.org、2026年10月25日時点

切り替え先の目安は、WordPress公式が推奨環境に挙げるPHP 8.3以上です(2026年10月25日時点)。PHP 8.2も、公式の発表では2026年12月31日でサポートが終わります。

ただし、PHPの版を切り替えると、古いテーマやプラグインが動かなくなることがあります。切り替える前にバックアップを取り、切り替えたあとにサイトが動くかを確認します(次の項目)。

3. サイトが正常に動くかを確認する

サーバー会社が修正を当てたあとは、念のため、次を実際に試します。

4. WordPressとプラグイン、テーマを最新にする

PHPが直っても、WordPressやプラグインに古い部分が残っていれば、そこから入られます。管理画面で、本体・テーマ・プラグインの更新を確認します。使っていないプラグインとテーマは、無効化ではなく、削除までします。詳しくは、ワードプレスは危険?の弱点の章に書いています。

5. バックアップを取り、戻せるかを確かめる

更新の前には、必ずバックアップを取ります。そして、取ってあるだけでなく、戻せるかどうかを、一度は確かめてください。自動バックアップがあるサーバーでも、戻す操作が有料だったり、数日かかったりすることがあります。バックアップと復元の記事に、確認の手順をまとめています。

6. サーバーに置いてあるものを減らす

GMO Flatt Securityは、今回の対策として、サーバー内のデータを減らすことと、サーバーの持つ権限を減らすことを挙げています。個人のお店や中小企業では、次のような形になります。

7. 連絡を受け取る人を決めておく

サーバー会社の緊急のお知らせは、契約したときのメールアドレスに届きます。そのアドレスが、今も見ているアドレスかを確認してください。担当者が辞めて、誰も見ていないメールボックスに届いている、ということはよくあります。

あわせて、「サーバー会社の告知を見るのは誰か」「サイトを一時的に止める判断をするのは誰か」を決めておきます。国家サイバー統括室は、修正を速やかに適用できないときは、サイトの一時停止も有効な方法の一つとしています。自分のサイトを止めるかどうかを、止まってから慌てて決めないことが大切です。

8. おかしいと気づいたときの動き方

次のような兆候があったら、改ざんされている可能性があります。

まず、サイトを一時的に非公開にして、その時点のファイルとデータを保存します。慌てて上書きして直すと、原因を調べる手がかりが消えます。そのうえで、サーバー会社と、サイトを作った会社(あるいは専門の業者)に連絡します。ログ(アクセスの記録)が残っているかも、サーバー会社に確認してください。

PHPを使い続けるなら:「その場しのぎ」を仕組みにする

ここまでの8つは、今回の件に対する確認です。ただ、専門家の見立てが当たるにせよ外れるにせよ、公開から攻撃までの猶予が短くなっていることは、今回の件で見えました。「事件が起きてから、慌てて確認する」というやり方を、その都度くり返すのは、いちばん消耗します。WordPressや予約システムなど、PHPで動く仕組みを使い続けるなら、事件のたびの確認を、最低限決まった仕組みに置き換えてください。

図解:その場しのぎの対応と、仕組みにする対応の対比7組。ニュースを見て慌てて確認する→確認する人と頻度(月1回など)を決め、サーバー会社の知らせを決まった人が見る。管理画面に出た更新だけを気づいたときに行う→使っている部品の一覧とサポートの終わる日を1枚にまとめる。設定の変更やファイアウォールでとりあえず乗り切る→応急処置と割り切り、本体の更新を前提にする(保護はパッチの代わりにならない)。古いサイトや使っていないデータをそのままにする→年に1回は棚卸しをして、使っていないサイト・アカウント・データを消す。バックアップはあるはずと考える→年に1回は実際に戻せるかを試す。止めるかどうかを起きてから考える→どんなときに止めるかと判断する人を先に決めておく。自分でやるのか誰かに頼むのかが曖昧→範囲を文書にして決め、頼むなら何を・いつまでに・誰がやるかを確かめる

仕組みにするときの、いちばん小さな形は次のとおりです。

  1. 月に1回、15分の確認の時間をカレンダーに入れる(サーバー会社のお知らせ、PHPの版、WordPressとプラグインの更新、バックアップの日付を見る)
  2. 使っている部品の一覧を、1枚作る(PHPの版とサポートの終わる日を書く。サポートが終わる半年前に、移る計画を立てる)
  3. 緊急の知らせが来たときの、連絡先と判断する人を決める(休日の夜でも連絡がつくかを確かめる)
  4. 自分で全部は見られない場合は、どこまでを誰に頼むかを決める(頼むときの範囲の決め方は保守の範囲と相場に書いています)

写真:店主が壁のカレンダーに月1回の青い印を書き込み、担当者がその横に貼った部品の一覧表を指さしている。壁の板に「月1回・15分」

ただし、この仕組みは守る範囲が変わらないまま、確認を続けるための工夫です。確認の回数そのものを減らす方法は、次の章にあります。

本当に必要なこと:PHPに頼る範囲を減らす

ここまでの対策は、PHPやWordPressが動いていることを前提にしています。動いている以上、更新と確認はこれからも続きます。専門家の予測どおり緊急対応が頻繁になれば、その回数は増えます。

WordPressは、本体もテーマもプラグインも、無料で手に入ります。だからこそ広く使われ、だからこそ、動かしたあとの更新・保守・止める判断は、すべて利用者の持ち分です。今回のような事態では、「無料で始められた」ことの裏側にあった負担が、一度に表に出ます。無料で始められた分の負担は、更新・バックアップ・サーバー・保守の費用として、あとから形を変えて現れます。

これからのサイトに求められるのは、機能を足し続けることではなく、しっかりした、無駄のない土台です。守る範囲を小さくする方法は、2つあります。

  1. WordPressから離れる。WordPressは、訪問者がページを開くたびにサーバーの上でPHPが動く仕組みです。PHPで動く以上、PHP本体の脆弱性からは逃れられません。更新が年に数回の会社案内やお店の基本情報のサイトなら、PHPを動かさない静的サイトに作り直す道があります。乗り換え先の4つの道と、やめて困ることは、WordPressをやめたいにまとめています
  2. 必要以上に動的なサイトにしない。予約や問い合わせ、お知らせの更新のために、サイト全体をPHPで動かす必要はありません。フォームや予約は外部のサービスに任せ、サイト本体は静的なファイルだけにすれば、サーバーの上で動くプログラムをゼロに近づけられます。「この機能のために、本当にサイトの中でプログラムを動かす必要があるか」を、一つずつ問い直してください

写真:カウンターの左に、札だらけで絡まった大量の鍵束。右に頑丈な鍵が1本だけ置かれ、店主の手がその1本を取ろうとしている。守る鍵が少ないほど守りやすい、というたとえ

今回、GMOグローバルサインが「電子証明書の発行サービスはPHPを使っていないため、影響がない」と発表したのは、この考え方の実例です。PHPが動いていなければ、PHPの脆弱性はそのサイトには届きません。

図解:PHPが動くサイトと静的サイトの構造の違い。左はPHPが動くサイト(WordPress・予約・フォーム)で、サーバー(OS)の上でPHPが動き、その上にWordPressやプラグインが載る。PHPの脆弱性の影響を受け、更新と確認がこれからも続く。右は静的サイト(当スタジオのホームページなど)で、配信サービス・サーバーの上にHTMLと画像のファイルだけがあり、PHPは動いていない。PHPの脆弱性はこのサイトには届かず、動かすものが少ないほど直すものも少ない。静的サイトでも残る作業として、ドメインとアカウントの管理、公開に使うサービスの設定、フォームなど外部サービスの確認がある。向かない使い方は、管理画面から自分で文章を直すことと、予約・ネットショップをサイトの中で動かすこと

ただし、静的サイトが「何もしなくてよい」わけではありません。ドメインとアカウントの管理、公開に使うサービスの設定、フォームなどの外部のサービスの確認は残ります。また、管理画面から毎日のように自分で文章を直す使い方や、ネットショップをサイトの中で動かす使い方には向きません。その場合は、よく変える項目だけを編集できる仕組みを静的サイトに足す道もあります(WordPressをやめたいの4つ目の道)。

当スタジオは、自社のホームページも、お客様向けの格安パッケージも、静的サイトで制作しています。サーバーの上でPHPを動かさないので、今回のような脆弱性のたびにサイトを止めたり、慌てて確認したりする必要がありません。動かすものが少ないほど、直すものも少なく、表示も速くなります。保守込みの維持費と、サーバー費用を0円にできる条件は格安パッケージのページに、費用の考え方はCloudflareの無料プランの記事にあります。いまのWordPressのサイトを静的サイトに移せるかどうかは、過去1年の更新を書き出すところから判断できます。維持費と表示速度の無料診断から、お問い合わせください。

まとめ

「自分のサイトがPHPを使っているのか、どの版なのか、誰が見ているのか」が分からない、という状態そのものが一番のリスクです。サーバーの契約内容の確認だけでも、静的サイトに移せるかどうかの相談でも構いませんので、必要でしたらお問い合わせください。

出典(2026年10月25日確認)

LPのCVR、見直してみませんか。

具体的な改善ポイントを、現状をもとにご提案します。

お問い合わせフォームへ →