2026年10月、Webサイトの多くで使われているプログラム言語「PHP」に、致命的な脆弱性が2件見つかり、緊急の修正版が公開されることになりました。
「うちのホームページは大丈夫?」「何をすればいいのか分からない」と不安に感じている方も多いと思います。
当社でも、公開の前に自社のサーバーを確認しました。当社のサイトは、いずれもPHPのサポート期間中のバージョンで動いており、修正版が提供される対象です。サーバー会社による修正版の適用を待ちながら、備えを進めています。
SNSでは、「共用のレンタルサーバーで、PHP 8.3以上、日ごろからバックアップや更新をしていれば、とくにすることはない」という情報も見かけます。方向性はおおむね正しいのですが、注意したい点もあります。
- PHP 8.3以上でも、修正版が入るまでは対象とされています。
「安全なバージョン」ではなく、「修正版が提供されるバージョン」と考えるのが正確です(サポート中の8.2も、修正版の対象です) - 共用サーバーでも、修正版が実際に適用されたかは、サーバー会社のお知らせなどで確認したほうが安心です
- バックアップを取っていても、対象に抜けがあることがあります
実際に当社でも、確認の中で、毎日取っていたバックアップに、思わぬ抜けがあることが分かりました。
この記事では、今回の脆弱性の概要とサイトを運営している方が確認したいこと、当社が実際に行ったバックアップの見直しを図解と動画で紹介します。
※ この記事は、2026年10月21日時点の情報をもとにしています。
対象のバージョンや修正版などの最新の情報は、必ず公式の発表を確認してください。
この記事の要点
- PHPに、外部からプログラムを動かされるおそれがある致命的な脆弱性が2件見つかり、修正版が公開される
- 共用のレンタルサーバーでは、PHP本体の更新はサーバー会社が行う
ただし、自分のサイトが使っているPHPのバージョンは自分で確認する - サポートが切れた古いPHPを使っている場合は、修正版が出ても対象にならないことがあるので、切り替えが必要
- 当社では確認の結果、毎日のバックアップから3つの対象が漏れていたことが分かり、すぐに取り直してサーバーの外にも保存した
今回のPHPの脆弱性とは
PHPの開発チームは、2026年10月20日(協定世界時)に、致命的と評価された脆弱性2件を修正する緊急のセキュリティリリースを予告しました。修正版は、日本時間の10月21日23時に公開される予定で、影響を受けるバージョンや修正済みのバージョンは、公開と同時に発表されるとしています。
| 項目 | 内容(10月21日時点) |
|---|
| 呼び名 | PHP2Shell(研究者の投稿などでの呼び名) |
| 番号 | CVE-2026-109618、CVE-2026-109619 |
| 深刻度 | 2件とも「致命的(Critical)」。CVSS 4.0 の基本値は 9.2 |
| 起きるおそれのあること | 外部から、サーバーの上で任意のプログラムを動かされる(リモートコード実行)おそれがあると報じられている |
| 影響を受ける範囲 | 公式の詳細は公開時に発表。一部の注意喚起では、PHP 5以降の幅広いバージョンが対象とされている |
公開前に情報の一部が出回ったこともあり、海外のセキュリティ企業の中には、修正版の公開から短い時間で、大規模な攻撃が始まると見ているところもあります。日本でもIPA(情報処理推進機構)が、PHPを使っているサイトの運営者に向けて、公開後すぐに修正版を適用できるよう準備をお願いする情報を出しています。
なお、公開前の対策として、PHPの設定の一部を変える方法も紹介されていましたが、その後の調査で、それだけでは対策にならないと分かったと報じられています。
確実な対策は、修正版のPHPに更新することです。

レンタルサーバーでは、誰がPHPを更新する?
PHP本体を更新するのが誰かは、使っているサーバーの種類によって変わります。

共用のレンタルサーバーでは、PHP本体の修正はサーバー会社が行います。
今回、当社が使っているエックスサーバーでは、公開の前の10月21日16時から、予防のために公式サイトやサーバーパネルなどの管理画面を一時的に止め、利用中のサーバーは稼働を続けながら対策を進めるという案内が出ました。
Webサイトの表示やメールは、ふだんどおり使える状態でした。
ただし、共用サーバーでも「すべて任せきり」にはできません。次の2つは、自分で確認する必要があります。
- 自分のサイトが、どのバージョンのPHPで動いているか:サーバーの管理画面(エックスサーバーなら「PHP Ver.切替」)で、ドメインごとに確認できます
- サポートが切れた古いバージョンを使っていないか:PHPの公式のサポートは 8.2 以降です。8.1 以前を使っている場合、修正版が提供されないことがあるので、新しいバージョンへの切り替えを検討します
当社のサーバーでは、Webサイトはすべてサポート中のバージョンで動いていたため、サーバー会社の修正版の適用を待つ形になりました。
一方で、サーバーの中で定期的に動かしている処理の一部が、細かいバージョンまで固定した古いPHPを指定していることも分かったので、修正版が出たら向け直す予定です。
公開の前に、サイト運営者が確認したいこと
| 確認すること | 内容 |
|---|
| PHPを使っているものの洗い出し | ホームページ、ブログ(WordPressなど)、予約や会員のシステム、お問い合わせフォームなど、PHPで動いているものをすべて書き出す |
| PHPのバージョン | それぞれのサイトのバージョンを確認。8.1 以前があれば、切り替えの準備をする |
| バックアップ | 今のうちに最新のバックアップを取り、サーバーの外(パソコンや別の保存先)にも保存する |
| 連絡の体制 | 制作会社・サーバー会社・社内の担当者の連絡先と、サイトを一時的に止める判断を誰がするかを決める |
| お知らせの確認 | サーバー会社の障害・メンテナンス情報や、公式SNSを確認できるようにしておく |
PHPのバージョンを確かめるために、phpinfo() を表示するファイルをサイトに置く方法がありますが、サーバーの詳しい情報が外から見えてしまいます。使う場合は、推測されにくい名前にして、確認したらすぐに消してください。サーバーの管理画面で確認できるなら、そのほうが安全です。
当社で見つかった「バックアップの抜け」
はじめにお伝えしておくと、バックアップは脆弱性そのものを直す対策ではありません。
脆弱性への対策は、あくまで修正版のPHPへの更新です。
それでも今回、バックアップを確認したのは、修正版が入るまでの間に万一攻撃を受けたり、更新でサイトに不具合が出たりしたときに、元の状態に戻せるかどうかが、被害の大きさを左右するからです。
今回、もしものときに戻せる状態かを確かめるため、毎日のバックアップの中身を確認しました。
毎朝決まった時刻に、自動でバックアップを取っていたので安心していたのですが、照らし合わせてみると、3つの対象が漏れていました。
下の図(再生ボタンで動画になります)は、そのときの実例です。

| 漏れていたもの | 漏れていた理由 |
|---|
| 別ドメインのサービス(CMS・ツール) | バックアップを作ったあとに、新しいサービスを別のドメインで始めていた |
| WordPressのブログとデータベース | ファイルだけでなく、データベースも別に保存する必要があった |
| 自動処理(cron)の設定・道具 | 公開しているフォルダの外にあり、対象に入っていなかった |
WordPressのデータベースで、1回失敗したこと
WordPressのデータベースを保存するとき、最初は設定ファイル(wp-config.php)から接続情報を読み取ろうとして、失敗しました。そのWordPressは、Composerという仕組みで管理する構成(Bedrock)で作っていて、接続情報が .env という別のファイルに書かれていたためです。
このように、サイトの作り方によって、大事な情報の置き場所は変わります。
いざというときに慌てないよう、どこに何があるかを、ふだんから記録しておくことが大切だと改めて感じました。
サーバーの外にも保存する
取り直したバックアップは、すべて手元のパソコンにもダウンロードしました。
サーバーが攻撃を受けると、サーバーの中に置いたバックアップも一緒に消されたり、書き換えられたりするおそれがあるためです。
ただし、バックアップには、会員の情報やお問い合わせの内容、データベースの接続情報なども含まれます。
パソコンに置いたまま放置せず、パスワード付きの外付けドライブや暗号化した場所に移し、自動で同期されるクラウドのフォルダには入れないなど、扱いにも注意が必要です。
バックアップがあるだけで安心しない
バックアップは、取ってあることより、実際に戻せることが大切です。
ファイルとデータベースがそろっているか、データベースの接続情報や、戻す手順が分かる人がいるかまで含めて、「戻せる状態」かを確かめておきましょう。可能であれば、別の環境で一度、戻す練習をしておくと安心です。
バックアップを見直すときのチェックリスト
- サーバーにあるサイト(ドメイン)を、すべて書き出したか
- それぞれのサイトのファイルとデータベースの両方が、対象に入っているか
- 公開フォルダの外にあるもの(設定ファイル、会員のデータ、自動処理の道具など)も入っているか
- データベースの接続情報の場所(wp-config.php、.env など)を把握しているか
- サーバーの外にも保存しているか
- バックアップから、実際に戻せるかを試したことがあるか
- 新しいサイトやサービスを始めたときに、バックアップの対象に加える手順になっているか
修正版が公開されたあとにやること
- PHPの公式の発表で、影響を受けるバージョンと修正済みのバージョンを確認する
- サーバー会社のお知らせで、修正版の適用状況を確認する
- 自分のサイトのPHPのバージョンが、修正済みのものに変わったかを確認する
- 自分で管理するサーバー(VPSなど)は、手順に沿って修正版に更新し、動作を確認する
- しばらくの間は、アクセスの記録や、ファイルの不審な変更、知らない管理者アカウントがないかを確認する
よくある質問
Q. WordPressを使っていなくても、影響はありますか?
あります。今回の脆弱性はPHPそのものにあるとされているため、WordPressに限らず、PHPで動くさまざまなシステムが対象になりえます。報道では、WordPressのほか、LaravelやSymfonyなどの構成でも攻撃が再現したとする研究者の投稿も紹介されています。
Q. 共用のレンタルサーバーで、PHP 8.3以上なら、何もしなくていいですか?
PHP本体の修正はサーバー会社が行うので、大がかりな作業は必要ありません。ただし、次の3つは確認しておくと安心です。
- 修正版が適用されたか:サーバー会社のお知らせや、管理画面のPHPのバージョンで確認する
- 古いバージョンが残っていないか:ドメインごとにバージョンを選べるサーバーでは、1つだけ古いまま(8.1以前)ということがある。サーバーの中で定期的に動かす処理が、古いバージョンを指定していることもある
- 修正前に攻撃されていないか:今回は公開前に情報の一部が出回っていたため、適用後もしばらくは、見覚えのないファイルや管理者アカウント、不審なアクセスがないかを確認する
Q. 静的なHTMLだけのホームページも危ないですか?
ページがHTMLのファイルだけで、PHPを一切使っていない場合は、今回の脆弱性の直接の対象にはなりにくいと考えられます。ただし、お問い合わせフォームなど、一部でPHPを使っていることも多いので、念のため確認してください。
Q. 自分で確認するのが難しい場合は?
サイトを作った制作会社や、サーバーを管理している会社に、「使っているPHPのバージョン」と「修正版の適用の予定」を問い合わせてください。あわせて、バックアップがどこに、どの範囲で取られているかも確認しておくと安心です。
まとめ:緊急のときこそ「戻せる状態か」を確かめる
- PHPに致命的な脆弱性が2件見つかり、修正版が公開される。確実な対策は、修正版への更新
- 共用サーバーでは、PHP本体の更新はサーバー会社が行う。使っているバージョンの確認と、古いバージョンからの切り替えは自分で
- 「毎日バックアップしている」は、「すべてを戻せる」とは限らない。対象を照らし合わせ、サーバーの外にも保存する
- サイトの作り方によって、大事な情報の置き場所は変わる。どこに何があるかを記録しておく
金風株式会社では、PHPのバージョンの確認やバックアップの見直しなど、サイトの安全な運用のご相談も承っています。「自社のサイトが何で動いているか分からない」という段階でも、お気軽にご相談ください。
あわせて読みたい
参考資料