MENU
気になったことの先には、いつも人間がいる。
  1. ホーム
  2. 調べてみた
  3. 日本中のサイトが止まった夜。PHPの脆弱性「php2shell」をこどもにも分かる言葉で解説

日本中のサイトが止まった夜。PHPの脆弱性「php2shell」をこどもにも分かる言葉で解説

調べてみた

2026年10月21日の夜、普段使っているサービスが次々と「緊急メンテナンス」に入りました。ニュースやSNSには「PHPの脆弱性」「php2shell」「サイトを止めろ」といった言葉があふれ、日本の首相までもが異例の呼びかけをする事態になりました。

ふだんPHPという言葉を聞かない人にとっては、何のことだかさっぱり分からなかったと思います。そしてサイトを運営している人にとっては、「うちは止めるべきだったの？」「修正が終わったからもう大丈夫？」「AIが見つけたって本当？」と、疑問が次々にわいてくる出来事でした。

この記事では、今回のPHPの脆弱性について、専門用語をできるだけ使わずに、日本の記事ではあまり触れられていない海外の情報も交えながら、順番に整理していきます。

目次

この記事でわかること

  • 今回のPHPの脆弱性（通称php2shell）が一体何だったのか
  • 6歳の子どもにも伝わるたとえ話で見る、PHPと脆弱性のしくみ
  • 修正版を入れたあとでも、まだやるべきことが残っている理由
  • 脆弱性を見つけたのがAIだったこと、攻撃する側もAIを使っていること、そしてこのいたちごっこの先行き
  • レンタルサーバーの人とVPSなどを自分で管理している人とで違う、最善の対応
  • 国内の大手レンタルサーバー各社が実際にとった対応の違い

※この記事は2026年10月22日夕方時点の公開情報をもとに書いています。状況は時間単位で変わるため、最新の情報は必ずPHP公式サイトや契約先の案内で確認してください。

はじめに　SNSやニュースで話題になったPHPの脆弱性は一体何だったのか

まず結論を3行で

  • 世界中のホームページを動かす土台のソフト「PHP」に、とても深刻な欠陥（脆弱性）が2件見つかりました。
  • 欠陥を突かれると、ログインもしていない外部の人に、サーバーを乗っ取られる可能性がありました。
  • 修正版が出る前に情報が漏れてしまい、世界中のサイト運営者が準備不足のまま、攻撃者と同じスタートラインに立たされました。

この2件の脆弱性には「CVE-2026-109618」と「CVE-2026-109619」という番号がついています。CVE番号とは、世界共通で脆弱性を区別するための背番号のようなものです。2件をまとめて、セキュリティ業界では「php2shell（ピーエイチピー・ツー・シェル）」と呼んでいます。

深刻度を表す点数（CVSS v4.0）は、PHP側の評価でどちらも9.2でした。10点満点で9.2ですから、最高ランクの「緊急」にあたります。セキュリティ会社のwatchTowrは、さらに高い10.0と評価していると伝えられています。

何が起きたのかを時系列で

日本時間で、出来事を順番に並べてみます。

  • 10月17日　AmazonのAWSが、おとり用のサーバー（ハニーポット）に対する攻撃の試みを観測しました。修正版が出る4日前です。どうやって攻撃者が情報を得たのかは分かっていません。
  • 10月20日（協定世界時）　PHPのセキュリティチームが「深刻な脆弱性2件を修正する特別リリースを出す」と予告しました。詳細は伏せたまま、準備を呼びかけました。
  • 10月21日未明　掲示板サイトに脆弱性の情報が書き込まれ、攻撃ツールの動画も出回りました。セキュリティ会社が「情報漏えいは本物だ」と確認しました。
  • 10月21日昼ごろ　Cloudflareが、攻撃を防ぐためのルールを先回りして配信しました。夕方にはCloudflareが「すでに攻撃が始まっている」と公表しました。
  • 10月21日午後　BASE、コドモン、エックスサーバーなどが、予防のためにサービスや管理画面を止め始めました。
  • 10月21日夜　国家サイバー統括室と高市首相がXで対応を呼びかけました。
  • 10月21日22時台　PHPの修正版が公開されました。予定の23時より少し早い公開でした。
  • 10月22日　朝から順次、サービスが再開されました。一方で、国税庁のe-Taxのホームページのように、22日の午前から予防的に公開を止めた例もありました。

なぜここまで大騒ぎになったのか

理由は大きく4つあります。

  1. アプリを直しても意味がない問題だったから　WordPressなどのアプリではなく、その下にあるPHP本体の欠陥でした。アプリを最新にしていても、PHPが古ければ危険でした。
  2. ログイン不要で乗っ取れる可能性があったから　専門用語では「認証なしのリモートコード実行」といいます。パスワードを知らなくても、外から命令を実行されてしまう、という意味です。
  3. 昔からあって、対象がとても広かったから　問題のコードは2012年のPHP 5.4から存在していました。約14年間、見つからないまま眠っていたことになります。
  4. 修正版が出る前に情報が漏れたから　本来は、修正版の公開と同時に情報を出すのが決まりです。今回はその順番が崩れ、守る側の準備時間が短くなりました。

数字で見る影響の大きさ

W3Techsの2026年10月の集計では、サーバー側の言語が分かるサイトのうち69.3％でPHPが使われています。つまり、世界のサイトの約7割がPHPで動いています。

脆弱なPHPがどれだけインターネットにさらされているかは、調査会社によって数字が違います。VirusTotalは、インターネットに公開されたPHPのホストが510万台以上と推計しました。Palo Alto Networksは、2260万の脆弱な可能性のあるインスタンスを確認したと伝えられています。数え方が違うので、ここでは「数百万から数千万の単位」と受け止めておくのがよさそうです。

国内でも、セキュリティ情報をまとめているブログpiyologの集計によると、10月22日の午前までにサービスやサイトの停止を告知した組織は200を超えました。銀行、証券、保育サービス、ゲーム、ネット通販、自治体、省庁まで、幅広い分野に及んでいます。

6歳でも分かる！PHPとは？今回見つかった脆弱性は何だったの？

PHPってなに？

インターネットでホームページを見るとき、画面の向こうには「サーバー」という大きなコンピューターがいます。サーバーは、レストランでいうと「厨房（ちゅうぼう）」です。

あなたがホームページを開くと、それはレストランの「注文」になります。厨房にいるコックさんが、注文に合わせて材料を集めて、お皿にのせて出してくれます。このコックさんの名前が「PHP（ピー・エイチ・ピー）」です。

ブログのWordPressも、買い物サイトも、会員サイトも、PHPのコックさんが作っています。世界のホームページのうち、約7割でこのコックさんが働いています。世界中の厨房で、同じコックさんが働いているようなものです。

「脆弱性」ってなに？

「ぜいじゃくせい」は、むずかしい言葉ですが、「弱いところ」「すきま」のことです。おうちでいえば、鍵がこわれている窓です。そこから悪い人が入ってくるかもしれません。

今回見つかった「すきま」はなに？

今回のすきまは、コックさんの「お片付け」にありました。

ものすごく大きな注文が来ると、厨房の机がいっぱいになってしまうことがあります。専門用語では「メモリ不足」といいます。すると、コックさんは「もうむり！」と、作業を途中でやめてしまいます。

このとき、コックさんは机の上をきれいに片付けないまま、「やりかけのメモ」を残してしまうことがありました。さらに困ったことに、コックさんは次のお客さんの注文のときに、そのメモを「これは自分が書いた正しいメモだ」と信じて、そのまま使ってしまうのです。

悪い人は、ここをねらいます。わざと大きな注文を送ってコックさんをあわてさせ、残ったメモをこっそり書きかえます。そして次の注文のときに、「悪い命令」をコックさんにやらせてしまうのです。

そうなると、2つのことが起きます。

  • 悪い人が、厨房（サーバー）を自由に動かせるようになります。これを「乗っ取り」といいます。
  • 前のお客さんの内緒のメモ（パスワードなど）が、のぞかれてしまいます。

しかも、この「お片付けの失敗」は、お店の入口のチェック（ログインなど）より前の、厨房のとても早い段階で起きます。入口の警備員さんが何もできないうちに、もう台所の中で事件が起きてしまう、というのが今回の怖いところです。

2つの脆弱性は、名前は別々ですが、根っこは同じ「お片付けの失敗」です。

ちょっとだけ大人向けの補足

ここからは、少しだけ大人向けの説明です。

2つの脆弱性の中身

  • CVE-2026-109618　大きな要求でメモリが足りなくなったとき、PHPが準備の途中のデータを抱えたまま処理を中断します。その後の後始末で、壊れたデータを正しいものとして使ってしまいます。ファイルのアップロードの進み具合を扱う機能が関わっています。さらに、他のリクエストのメモリの中身が、応答のクッキーを通して外に漏れる可能性があります。
  • CVE-2026-109619　エラーで処理が中断されたあと、前のリクエストの内部データがワーカー（PHPを動かす係）の中に残ります。次に同じワーカーが別の人のリクエストを処理するとき、その残りかすを使ってしまいます。

どちらも、すでに使い終わったメモリを使い続けてしまう、という種類のバグです。海外のセキュリティ会社は、情報が漏れる点を、2014年に世界を騒がせた「Heartbleed（ハートブリード）」になぞらえています。Heartbleedとは、通信を守る仕組みの欠陥から、サーバーのメモリの中身が外に漏れた事件です。

どんな環境が対象か

PHP公式は、Webからのリクエストを処理するPHPは、すべてリスクがあるとしています。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedといった、PHPの動かし方の違いにかかわらず対象です。

特に危険とされているのがmod_phpです。サイト側のプログラムが1行も動かないうちに、認証なしの1通のリクエストで攻撃が成立する実演が確認されているからです。

どのバージョンが直ったのか

修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。PHP 8.1以前には、通常の公式リリースは出ていません。ただしPHPのセキュリティチームは、特例として、7.4、8.0、8.1向けに最小限の修正のソースコードを公開しました。自分でビルドする人向けの措置です。

アプリでは防げない

発見した研究者は、WordPress、Drupal、Joomlaの最新の公式イメージで、認証なしのコード実行を実演しました。ただし、これらは「見せやすい例」として選ばれただけです。「Hello World」を表示するだけの簡単なプログラムでも、PHPが古ければ脆弱になりえます。

もし悪用されたら、何が起きるの？

一言でいえば、インターネット越しにサーバーを乗っ取られる可能性があります。具体的には、次のようなことが考えられます。

  • 情報の盗難　会員情報、パスワード、決済に関わる情報、APIキーなどが盗まれます。
  • サイトの改ざん　ページの書きかえや、偽の入力フォームの埋め込みが行われます。
  • バックドアの設置　攻撃者が、あとから何度でも出入りできる「裏口」を仕込みます。
  • 踏み台にされる　乗っ取ったサーバーから、ほかの会社への攻撃やスパムメールの送信が行われます。
  • データの破壊や暗号化　ランサムウェアのように、データを人質にとられます。

特に怖いのは、3つ目のバックドアです。この話は、次の章でもう一度出てきます。

脆弱性の対応が終わったらもう大丈夫？

結論から言うと、修正版を入れただけでは、まだ終わりではありません。

修正版を入れる作業は、「窓の鍵を直した」ことにあたります。でも、直す前に誰かがもう家に入っていたら、鍵を直しても、その人は家の中にいます。今回は、修正版が出る前から攻撃の試みが確認されているため、この考え方がとても大切です。

本当に直ったかを確認する

  1. PHPを再起動したか　新しい修正版を入れても、動いているPHPの係（ワーカー）を再起動しないと、古いままのものが動き続けます。PHP-FPM、Apache、バックグラウンドで動く処理など、PHPを使う長時間動作のものは、すべて再起動が必要です。
  2. コンテナを作り直したか　Dockerなどのコンテナを使っている場合、サーバー本体を更新しても、動いているコンテナは古いままです。修正済みの部品でイメージを作り直して、入れ替える必要があります。
  3. PHPが入っている別のソフトを見落としていないか　アプライアンス（機器）、管理画面ソフト、業者から納品されたシステムの中にも、PHPが入っていることがあります。IPAも、製品や機器の中のPHPについては、提供元のセキュリティ情報を確認するよう求めています。
  4. バージョン番号だけで判断していないか　ディストリビューションや事業者は、番号を変えずに修正だけを入れる（バックポート）ことがあります。実際に、国内のレンタルサーバーmixhostは、番号が変わらない形で修正を入れたと案内しています。番号が古く見えても直っている場合があり、逆に、番号が新しくても再起動が済んでいなければ危険です。確認は、事業者の告知やパッケージの更新履歴を基準にします。

直す前に入られていないかを調べる

海外のセキュリティ会社は、調査を始める起点を、公開日ではなく10月17日にするよう勧めています。AWSの観測が、その日にあったからです。

見るべきサインとして、複数の会社が次のようなものを挙げています。

  • 大きなファイルアップロード形式のリクエストのあとに、メモリ不足のエラーや、500エラーが続いている
  • とても長い、または形のおかしいPHPSESSIDというクッキーが返されている
  • PHPの係（ワーカー）が理由もなく何度も再起動している
  • 見覚えのないPHPファイルや、最近更新されたPHPファイルがある
  • 知らない管理者アカウントが増えている
  • .user.iniなどの設定が書きかえられている
  • サーバーから外への、見慣れない通信がある

ここで大切な注意が2つあります。

1つ目は、ログがきれいでも、安全とは言い切れないことです。PHPが公開した情報でも、欠陥の1つは、決まった形のログが残らない形で悪用できる、と注意されています。

2つ目は、証拠は、直す前に保存することです。ログのローテーション（古いログの削除）や、コンテナの作り直しで、調べるための証拠が消えてしまうことがあります。更新作業の前に、バックアップを取っておくのが基本です。

漏れたかもしれない情報を守る

今回の欠陥は、ほかのリクエストのメモリの中身を読めてしまう点も問題でした。そこには、パスワード、セッションの情報、APIキー、証明書などが入っている可能性があります。

乗っ取られた形跡がなくても、念のため、重要なサーバーのパスワードやAPIキーの入れ替えを検討する、という助言が複数の海外のセキュリティ会社から出ています。入れ替えるかどうかは、そのサイトが扱う情報の重さで判断します。

一時的な対策は元に戻す

更新までの「時間かせぎ」として、設定の変更をした人も多いはずです。たとえばPHP公式は、メモリの上限を外す設定や、アップロードの進み具合を扱う機能を切る設定などを紹介していました。

ただし、これらは公式自身が「完全な対策ではない」としています。さらに、メモリの上限を外すと、1つのリクエストがサーバーのメモリを使い切る危険があります。修正版を入れて確認できたら、有限の適切な上限に戻し、一時的に付けたアップロード制限なども見直します。

古いPHPは「直せない」問題が残る

PHP 8.1以前は、公式の通常リリースが出ません。PHP 8.2も、2026年末でサポートが終わる予定です。レンタルサーバーによっては、事業者が独自に修正を入れてくれる場合もありますが、これは事業者ごとの対応です。

古いバージョンのままのサイトは、今回の件に限らず、今後ずっと危険が残ります。この機会に、新しい版への移行計画を立てるのが現実的です。

「見つかったもの」が全部ではない

発見したWizの研究者は、今回報告した4つのバグのほかにも、同じパターンの別の変種があると述べています。そして、PHPの修正は、問題を根っこから直すもので、変種も同じ修正でふさがれる、としています。つまり、今回の修正版は、1つ1つの穴をふさいだというより、同じ種類の穴をまとめて直したものだと考えられます。

とはいえ、OpenAIも、今回のような重大な発見は「この先数か月で急に増える」と見ています。「今回で終わり」ではなく、「また来る」と考えて運用を整えておくほうが安全です。

実際の被害は、まだ見えていない

「公開されている被害」は、まだ多くありません。海外の解説でも、悪用の試みが観測された数、攻撃を受けたサイトの数、実際に侵入されたサイトの数は、それぞれ別の数字だと説明されています。

国内では、10月22日にバルテックという会社が、PHPの脆弱性を狙ったサイバー攻撃による不正アクセスを公表しました。ただし、報道によれば、今回のphp2shellとの関係は特定されていません。

被害の全体像は、これから数日から数週間かけて少しずつ明らかになっていくと思われます。過去の大規模な脆弱性（たとえば2021年のLog4Shell）でも、被害の公表は、修正版の公開からしばらく経ってから増えていきました。「今日、被害の話が少ない」ことは、安心の材料ではありません。

脆弱性を見つけたのはAI？ハッカーもAIを使っているなら、このイタチごっこはいつまで続くの？

誰が、どうやって見つけたのか

今回の話題の中心は、見つけたのが「AI」だったことでした。ただし、経緯は少し複雑で、発表元によって語られ方にも違いがあります。

  • Calif（カリフ）　アメリカのAIレッドチーム会社です。OpenAIの「Patch the Planet」という取り組みに参加して、8月1日ごろ、OpenAIのAIモデル（GPT-5.6 Sol）を使って最初の問題を見つけたと説明しています。PHPは何年も多くの専門家に調べられてきたため、重大なものが見つかるとは期待していなかったそうです。
  • Wiz（ウィズ）　クラウドセキュリティ会社です。Califとは別に、8月19日ごろに最初の問題を見つけ、8月24日にPHP側へ報告しました。GoogleのGemini、OpenAIのGPT、自社のAIツールを組み合わせて使ったと説明しています。
  • OpenAI　発見の追加調査をし、PHPの開発側、WizやCloudflareなどをまとめる「連合」の調整役を担ったと説明しています。
  • PHP側　PHPの開発チームが、修正とリリースを主導しました。PHP財団は、AIは報告の確認を手伝ったが、判断と修正は人間がすべてやった、と説明しています。
  • なお、Cloudflareは、発見者としてQuarkslabというフランスの会社の名前も挙げています。

OpenAIは、「AIが、攻撃者よりも先に見つけた」と主張しています。ただし、報道機関のPPC Landは、この主張は発表した会社自身によるもので、第三者による裏づけは示されていないと指摘しています。また、Cloudflareは「修正版の公開前に情報が漏れ、攻撃も観測した」としており、OpenAIの説明には、その点への言及がありません。「AIが先に見つけた」ことと、「そのあとで情報が漏れた」ことは、両方が事実である可能性もあります。

なぜ14年間も見つからなかったのか

PHP財団によると、問題のきざしは、2024年に開発者の1人がすでに見つけていました。しかし、技術的に難しい判断が多く、人手も限られていたため、作業は何度も止まっていたそうです。また、OpenAIのグレッグ・ブロックマン氏は、2024年に見つかったのは限定的なもので、当時は重要とは見なされなかった、と説明しています。

Wizは、さらに踏み込んだ見方をしています。欠陥そのものは10年以上そこにあった。変わったのは、AIによって、欠陥の弱点を理解して、実際に使えるものに仕立てる難しさが大きく下がったことだ、というのです。

実際に使えるものにするには、複数のバグをつなぎ、PHPのバージョンや設定ごとのメモリの配置に合わせて調整する、という手間のかかる作業が必要でした。Wizは、これまで世界トップクラスのチームが数か月かける作業を、AIを使った1人の研究者が1週間でやり遂げた、と述べています。

ハッカーもAIを使っているの？

使っています。ただし、今回のphp2shellの攻撃で、AIがどこまで使われたかは、分かっていません。

AmazonのAWSは、パッチの差分や技術情報をもとに、AIが攻撃を作る手間を減らせる、と警告しています。同時に、AWSが見た10月17日以降の攻撃の試みについては、AIが使われたと言える材料はまだない、としています。

一般論としては、AIを使った攻撃は増えています。アメリカの経済誌Fortuneによると、9月25日から数週間にわたって、1人の攻撃者が、AIエージェントの軍団に1200以上のサイトを自動で攻撃させました。人間が張りつかなくても、およそ100社への侵入に成功したそうです。かかった費用は、AIの利用料でおよそ5000ドルで、成功1件あたり50ドルほどだと伝えられています。専門家は、攻撃のコスト構造を根本的に変える、と指摘しています。

守る側もAIを使っている

守る側もAIを使っています。今回のphp2shellは、その代表例です。OpenAIは、攻撃者が見つける前にAIが見つけたことで、守る側に「準備の猶予（Defender’s Window）」が生まれた、と説明しています。そのうえで、同社は次のような取り組みを発表しています。

  • 修正から公開までを5段階で進める枠組み（修正、関係者への事前連絡、政府機関との連携、各製品の更新準備、公開後の支援）を提案しました。
  • 資金の限られた重要サービスの守り手に向けて、10億ドル分の割引利用枠を設けると発表しました。
  • 小さなチームで運営されるオープンソースのメンテナーを、資金や技術面で支援するとしています。

ただし、これらはAIを売る会社自身の発表です。評価は、これから第三者の検証を待つ必要があります。

いたちごっこは、いつまで続くのか

ここからは、集めた情報にもとづく私の見立てです。

いたちごっこは、終わらないと思います。ただし、中身が変わりました。

  1. 速さ　パッチが出てから攻撃ができるまでの時間が、短くなっています。「人間が気づいてから動く」運用では、間に合わなくなってきました。
  2. コスト　1件あたり数十ドルで、攻撃を自動で回せる例が出ています。小さなサイトも、ねらわれる対象になります。
  3. 技術の壁　これまでは「難しすぎて、現実には悪用されない」と思われていた欠陥が、悪用される対象に変わりつつあります。Wizは、複雑さが「守りの壁」にならなくなるかもしれない、と述べています。

OpenAI自身も、先行して見つける力と、広く使える力の差が小さくなれば、準備の時間は短くなる、と認めています。

海外では、AIの安全装置が、守る側の邪魔になる問題も話題になっています。Fortuneによると、ある攻撃を受けた会社が防御にAIを使おうとしたところ、AIが依頼を断った例があったそうです。悪用を防ぐ工夫と、守る側が使えることの両立は、まだ答えが出ていません。

では、長い目で見て何が根本の解決になるのか。OpenAIが挙げているのは、次のような方向性です。

  • 安全なコードを、書く段階から作る
  • メモリの扱いを誤りにくい言語に移していく
  • 数学的な証明でセキュリティを確かめる
  • 信頼できないデータを扱う部分を、狭い箱の中に閉じ込める

今回の欠陥は、すべて「メモリの扱いの誤り」という種類でした。こうした方向性とは、相性の悪い種類の欠陥でもあります。ただし、PHPのような巨大で古いソフトの土台を作りかえるには、長い年月がかかります。

OpenAIは、もう1つ議論を呼びそうな問いも投げかけています。管理者の手が届かなくなったシステムを、政府などが脆弱性を使って直接修正してよいのか、という問いです。提案ではなく、議論を求める質問という位置づけですが、将来「知らないうちに修正される」世界を想像させるテーマです。

サイト運営者が、いまできること

いたちごっこが続く前提で、運営者ができることは、地味ですが次の5つです。

  1. 何が、どこで、どのバージョンで動いているかを一覧にする　今回、一番危なかったのは「誰かが昔立てて、忘れられたサーバー」でした。
  2. 更新を、誰が・いつ・どうやってやるかを決めておく　できる範囲で自動更新を使います。
  3. 「止める基準」を、事前に決めておく　慌てて決めると、止めすぎるか、止められないかのどちらかになります。
  4. バックアップと、ログの保存を整える　調査の材料になります。
  5. サポートが切れたバージョンを使い続けない　今回のように、修正版が出ない現実に直面します。

今回のWebサイト所有者の対応で正解は何だった？サイトの閉鎖は本当に必要だった？

先に結論

結論は、次の3つです。

  • 公開前の夜に止める判断は、条件付きで合理的でした。修正版がなく、情報は漏れていて、攻撃の試みも出ていたからです。特に、個人情報や決済を扱うサイトで、すぐに更新できない場合です。
  • ただし、止めること自体が目的ではありません。止めるのは「修正版を当てて確認するまでの時間かせぎ」です。当てて確認できたら戻します。
  • 全員が止める必要はありませんでした。事業者が夜のうちに更新を終えたレンタルサーバーの利用者や、PHPを使っていない静的サイトまで止める必要は、ほとんどありませんでした。

以下で、立場ごとに分けて説明します。

責任の分かれ目を、ホテルとおうちでたとえる

  • レンタルサーバーはホテルの部屋のようなものです。建物の設備（PHPなど）の修理は、ホテル（事業者）がやります。あなたの役目は、部屋の中の荷物（WordPressやプラグイン）と、ホテルのお知らせを見ることです。
  • VPSやクラウドで自分で管理しているサーバーは、借りた一軒家のようなものです。鍵も水道も、直すのは自分です。誰も代わりにやってくれません。

この違いが、最善の対応を大きく分けます。

時系列で見る、最善手

修正版が出る前（10月20日から21日の夜）

  • 使っているPHPと、PHPが入っている機器や納品システムをすべて洗い出す
  • 修正版をすぐ当てられる準備をする（バックアップ、作業担当、手順）
  • 「当てられない場合は止める」というラインを決める
  • やり方が分からない、当てる体制がない、重要データを扱う場合は、止める

首相や国家サイバー統括室も、すぐに修正版を当てるのが難しい場合は、サイトの一時停止もリスクを減らす有効な手段だと案内しました。海外でも、イギリスのNCSCは「更新するか、更新できるまでオフラインにする」よう求めました。PHPのコア開発者のGina Peter Banyard氏も、リリース前に止めるのが最も現実的だ、との趣旨を述べたとSansecは伝えています。オランダでは、下院、NCSC-NL、大手ITメディアTweakersなどが、予防的にサイトを止めました。

修正版が出た後（10月21日22時台から）

  • 修正版を当てる（8.5.12、8.4.27、8.3.36、8.2.35、またはディストリビューションの修正済みパッケージ）
  • 再起動する、コンテナを作り直す
  • 動作を確認する（フォーム、ログイン、決済、定期処理など）
  • 少なくとも10月17日にさかのぼって、ログや不審なファイルを調べる
  • 問題なければ、再開する

大手レンタルサーバーを使っている場合

多くの人は、自分でPHPを更新する必要はありませんでした。更新するのは事業者だからです。

  • まず、契約している事業者の告知を見る。事業者によって、「止めずに更新した」「利用者のサイトの一部を止めた」「まだ調整中」など、状況はまったく違いました。
  • 自分でできる設定変更は、ほぼない。PHPが公式に紹介した一時的な対策の中には、サーバー全体の設定が必要なものがあります。ある解説では、アップロード関連の設定を、.user.iniやini_setで変えても効かない、と注意しています。
  • 事業者が更新を終えるまでの間、判断が必要になることがあります。たとえばKAGOYAは、一部のプランで、利用者側に公開停止やアクセス制限の検討を呼びかけました。
  • PHPのバージョンは、サポート中のものにしておく。8.1以前を使っていたら、8.2以上（さくらインターネットは8.3を案内）への切り替えを検討します。WordPressなら、テーマやプラグインの対応も確認します。
  • 更新が終わった後は、自分のサイトが正しく動くかを確認する。表示、ログイン、フォーム、決済、メール通知などです。
  • Cloudflareなどを前に置いているなら、保険になる。Cloudflareは、10月21日の昼ごろから、無料プランを含めて、攻撃を防ぐルールを配信しました。ただし、有料プランでは、自分の設定でルールが「ブロック」になっているかを確認する必要があります。また、Cloudflareを通らない直接のアクセスは守れません。Cloudflare自身も、これは「保険」で、PHPの更新の代わりにはならない、と言っています。

「WordPressのメンテナンスモードにすれば安全」と考える人もいますが、これは間違いです。Sansecによると、PHPは、アプリが「メンテナンス中か」を確認するより前に、リクエストを読み込みます。そのため、WordPressやMagentoのメンテナンスモードでは、今回の攻撃は防げません。止めるなら、PHPの動作そのものを止めて、Webサーバーが用意した静的なお知らせページを返す必要があります。レンタルサーバーでは、これは自分では難しいので、事業者に相談するか、サイトのアクセスを制限する手段を考えることになります。

VPS・クラウド・自社サーバーを使っている場合

ここは、自分で全部やる必要があります。

  1. PHPのバージョンと動かし方（PHP-FPM、mod_phpなど）を確認する。
  2. 修正版か、ディストリビューションの修正済みパッケージを入れる。
  3. PHPの係（ワーカー）を再起動する。
  4. コンテナを使っているなら、イメージを作り直して入れ替える。
  5. 動作確認と、ログ・不審なファイルの調査をする。
  6. 重要なパスワード、APIキー、トークンの入れ替えを検討する。

落とし穴も、いくつかあります。

  • RHEL系で、Remiリポジトリを使っている場合。Sansecによると、ボランティアが運営するRemiリポジトリは、10月21日には更新を出さないと、PHP財団が伝えました。ディストリビューション標準のPHPに切り替えるか、ソースからビルドする必要が出ます。
  • PHP 8.1以前の場合。公式のリリースはありません。ディストリビューションやLTSの提供元に、修正の有無を確認します。ない場合は、8.2以上への移行か、停止か、隔離です。
  • すぐに更新できない場合。止めるのが一番確実です。全部を止められないなら、GETとHEAD以外のリクエストを断る方法もあります（閲覧だけ残し、ログインや注文は止める）。ファイルアップロード形式のリクエストを断る方法もありますが、画像のアップロードなどが壊れます。Sansecは、こうした方法を示しつつ、いずれも一時的で部分的な対策だと念を押しています。

AWSは、攻撃の調査を始める起点を、公開日ではなく10月17日にするよう勧めています。VPSなどを自分で管理している人は、ここまでさかのぼって、ログを見るのが安全です。

企業で、自社サーバーや納品システムがある場合

企業の場合は、さらに次の点が加わります。

  • PHPを使っているものの棚卸し。自社サイトだけでなく、受託開発で納品したシステム、機器に入ったPHP、CI/CDのイメージも含みます。
  • 取引先や委託先の確認。自社のシステムを預けているサービスの事業者が、どう対応したかを確認して、記録に残します。
  • 個人情報が漏れた可能性がある場合の対応。個人情報保護委員会への報告が必要になるケースがあります。具体的な判断は、専門家に相談してください。
  • 説明の準備。「いつ更新したか」「その間にアクセスがあったか」を、説明できる状態にしておきます。

止める場合のSEOの注意（海外の情報より）

サイトを止めるときは、検索順位への影響も気になるところです。Googleは、10月21日、PHPの更新のためにサイトを止める人に向けて、「503」というステータスコードを返すよう注意喚起しました。

503は「サービスが一時的に利用できません」という意味です。Googleによると、503を返している間、すでに検索結果に登録されているページは、一時的に保持されます。一方、「ページが見つからない」という意味の404や、お知らせページを「正常」を意味する200で返すと、ページが検索結果から消えたり、「ソフト404」と判断されたりするおそれがあります。

ただし、注意点があります。503で守られるのは、ずっとではありません。Googleの文書によると、サーバーのエラーが続くと、最終的には検索結果から外されます。別のGoogleの資料では、エラーを1日から2日より長く出し続けないよう注意しています。止めるなら、短期間にとどめましょう。

「全部止める」以外の選択肢もあった

  • 一部だけ止める。国税庁は、e-Taxの案内ホームページを止めましたが、申告書を作る「確定申告書等作成コーナー」は、続けると説明しました。
  • キャッシュのコピーで見せる。オーストラリアのGovCMSは、サーバーへの直接アクセスを止めつつ、公開ページのキャッシュは見られるようにしました。
  • アップロード機能だけ止める。オーストラリアのホスティング事業者VentraIPは、一部のファイルアップロードを制限しました。副作用として、添付のあるフォームが失敗する可能性を知らせています。

状況別の早見表

あなたの状況まずやること止める判断
大手レンタルサーバーで、個人のブログ（WordPressなど）事業者の告知を確認し、PHPを8.2以上にしておく事業者が更新済みなら不要。未対応の告知があれば、事業者の案内に従う
レンタルサーバーで、会員情報や決済を扱うサイト事業者の更新完了を確認し、再開後は動作とログを点検する事業者が未対応なら、公開停止やアクセス制限を検討する
VPS・クラウドで自分で管理している修正版の適用、再起動、コンテナ作り直し、ログ調査すぐ更新できない場合は、止める（または機能を絞る）
企業の自社サーバー、納品システム、機器棚卸し、提供元への確認、適用、侵害調査重要データを扱い、更新できないなら、止める
PHPを使っていない静的サイトPHPが本当に使われていないかを確認する止める必要はない

閉鎖は本当に必要だったのか、改めて

ここまでをふまえた私の評価です。

  • 必要だった人は、確かにいた。修正版が出る前の夜に、自力で更新できない、重要データを扱うサイトは、止める判断に理由がありました。
  • 必要なかった人も、多かった。夜のうちに更新を終えたレンタルサーバー（さくらインターネットや、Value-domain系など）の利用者が、自分のサイトを止める意味は、ほとんどありませんでした。
  • 止めても、安全は保証されない。すでに入られていたなら、止めても意味がありません。止めるのは、「これからの攻撃」を避けるための手段です。
  • 後から「過剰だった」と言うのは簡単。当時は、修正版も、攻撃の実態も、分からない状況でした。「止めた判断」を責めるより、「準備して、基準を決めておくこと」が大切です。

今回の出来事から得られる一番の教訓は、「止めるか止めないか」より、「何をいつまでにやれば戻せるか」を、事前に決めておくことだと思います。

国内の大手レンタルサーバーだと安心？各社の対応から見える違い

先に結論

「国内の大手だから安心」とまでは言えません。ただし、「大手のほうが対応が速い」傾向は、今回の動きからも見えました。大切なのは、「大手かどうか」ではなく、「何を、いつまでに、どう知らせてくれたか」です。

各社の対応（10月22日昼ごろ時点）

以下は、各社の公式告知を整理した第三者の記事（Into the Program、zephel01氏のnote、人鳥日記など）をもとにまとめたものです。時間とともに状況が変わっている可能性が高いので、必ず契約先の最新の告知を確認してください。

事業者公開前から公開直後までの動き22日昼ごろまでの状況気をつける点
さくらインターネット21日23時から22日6時30分まで、PHPの更新のための緊急メンテナンスを実施数秒程度の接続断で更新を完了。コントロールパネルで選べる全バージョンで対応済みと案内周辺機能（ウェブメール、ファイルマネージャ、phpMyAdminなど）は止めた。旧PHPの利用者には8.3を案内
エックスサーバー（シン・レンタルサーバー、スターサーバー含む）21日16時から、公式サイトと管理画面などを予防的に停止。利用者のサーバーは稼働を継続22日6時45分に、PHP 8.2から8.5の全対象サーバーへ修正を適用。旧PHPには独自修正を作成し順次適用管理画面は、段階的に再開。再開後に追加の対策を依頼する場合がある
mixhost公式発表の範囲では、止めたかどうかは確認できなかった22日10時18分ごろ、修正パッケージの適用を完了。サポート切れ版を含むPHP 5.2から8.5が対象バージョン番号は変わらない。8.2未満は8.2以上への変更を推奨
ロリポップ！、ヘテムル21日22時にFTPなどを停止。22日3時台に一部サーバーのサイトを一時停止22日朝時点で、PHPの更新を順次進行。全サーバーへの適用と再開は昼ごろの予定利用者のサイトやユーザー専用ページ、FTP、APIなど広く止めた。ロリポップ！の公式ページは緊急メンテナンス表示
ConoHa WING、お名前.comレンタルサーバー21日19時から22日10時までの緊急メンテナンスを告知ファイルマネージャやWebメールが停止。終了は未定の部分あり告知は「システムの保守作業」とだけ書かれ、PHPとは明記されていない。対応していないという意味ではなく、確認できないということ
KAGOYA事業者側ではサイトを止めなかったPHP 8.2から8.5は、修正版への更新を調整中（22日10時35分時点の告知）利用者に、公開停止やアクセス制限の検討を呼びかけた。被害は確認されていないとしている
CPI21日21時から、管理画面などを順次停止再開は未定。利用者のサーバーは通常どおり稼働PHPの適用状況は、告知からは読み取れなかった
Value-domain系（CORESERVER、VALUESERVER、XREAなど）22日0時台に、メンテナンスを実施夜のうちに完了「お客様側でのPHPのバージョン変更などの対応は必要ない」と案内

各社の対応から見える3つの違い

1　「止めずに直した」か「止めて直した」か

さくらインターネットや、Value-domain系のように、数秒から数十分の作業で、サイトを止めずに更新を終えた事業者がありました。これは、日ごろから「更新を回す仕組み」が整っていることの表れだと思います。PHP公式も、Linuxのディストリビューションなどには、事前に修正を渡していたと説明しています。

一方で、ロリポップ！やヘテムルのように、利用者のサイトの一部を止めて、時間をかけて更新した事業者もありました。これは「安全のために止めた」という判断でもあり、一概に悪いとは言えません。ただ、利用者の側から見れば、サイトが見られない時間が長くなります。

2　古いPHPの扱い

PHP 8.1以前は、公式の修正が出ません。ここを、事業者が独自に直すかどうかで、差が出ました。さくらインターネットとmixhostは、古い版にも修正を入れたうえで、新しい版への移行を勧めています。エックスサーバーは、独自の修正を作って、順次適用しています。

この「独自の修正」は、事業者の技術力や運用にかかっています。今後、古いPHPを使い続ける人は、事業者に頼る部分が大きくなります。

3　告知の書き方

BASEやShadowverseのように、「PHPの脆弱性への対応」と明記したところがありました。一方で、「システムの保守作業」とだけ書いた告知もありました。

どこまで書くかは、攻撃者への情報の出し方との兼ね合いもあるので、一概には言えません。ただ、利用者が「自分のサイトにどう影響するか」を判断するには、PHPと明記してあるほうが動きやすいのは確かです。

レンタルサーバーを選ぶときの視点

今回の件で、レンタルサーバー選びで見るとよい点が、はっきりしました。

  • 緊急時に、どのくらいの時間で更新を終えるか。
  • 止めずに更新できる運用か。
  • 告知が、具体的で分かりやすいか。
  • 古いPHPの扱いを、きちんと案内しているか。
  • 管理画面や周辺機能の再開が、どの順番で進むか。
  • 利用者に何を求めるのかが、明確か。

「今回止めた事業者がダメ」「止めなかった事業者が良い」という単純な話ではありません。止めたのは安全側の判断で、止めなかったのは準備ができていた、という見方もできます。大切なのは、あなたが運営するサイトの性質に合う事業者か、という視点です。

契約者が、いま確認しておくこと

  1. 契約している事業者の最新の告知を読む。
  2. 自分のサイトのPHPのバージョンを確認する（8.2以上に）。
  3. 再開後に、表示、フォーム、ログイン、決済、メール通知が動くかを確認する。
  4. 管理画面の再開後に、事業者から追加の案内がないかを確認する。
  5. 不審なファイルや管理者アカウントがないかを確認し、心配なら事業者や専門家に相談する。

まとめ　今回のPHP脆弱性から、私たちが持ち帰るもの

最後に、各章の内容をふり返ります。

1　何があったのか。PHPという、世界のサイトの約7割を動かす土台のソフトに、認証なしでサーバーを乗っ取られる可能性のある欠陥が2件ありました。約14年前のPHP 5.4から存在し、修正版の公開前に情報が漏れました。

2　6歳でも分かる説明。PHPは「厨房のコックさん」で、今回の欠陥は「注文が大きすぎて、お片付けに失敗する」ことでした。机に残ったメモを書きかえられて、悪い命令をさせられる、というのが、あらましです。

3　対応が終わっても、まだ終わりではない。修正版を入れ、再起動し、コンテナを作り直し、10月17日にさかのぼって侵入の形跡を調べ、必要ならパスワードやキーを入れかえる。ここまでが、本当の「対応」です。

4　AIは、守りにも攻めにも使われる。今回の欠陥は、AIの力で、見つかり、検証され、修正に至りました。同時に、AIは攻撃のコストと技術の壁を下げています。このいたちごっこは終わらないので、「人間が気づいてから動く」やり方から、「あらかじめ決めておく」やり方に変える必要があります。

5　最善手は、立場で違う。ホテル（レンタルサーバー）の利用者は、事業者の告知を見て、自分のサイトの動作を確認し、再開後の点検をします。一軒家（VPSなど）を借りている人は、自分で更新し、再起動し、調べます。サイトを止めるのは、更新できない夜の「時間かせぎ」としては合理的でした。ただし、止めること自体が目的ではなく、止めたからといって安全が保証されるわけでもありません。止めるときは、検索順位を守るために503を返しましょう。

6　国内大手でも、対応には差があった。さくらインターネットなど、止めずに更新を終えた事業者もあれば、利用者のサイトの一部を止めた事業者、告知にPHPと書かなかった事業者もありました。「大手だから安心」ではなく、「何をいつまでにしてくれるか」で選ぶ時代です。

今回の出来事は、「誰かが気づく前に、すでに始まっている」時代の、予告編だったのかもしれません。それでも、慌てないための準備は、今日からできます。

  • 使っているPHPの一覧を作る
  • 更新と再起動の担当を決める
  • 「止める基準」を決めておく
  • バックアップとログの保存を整える
  • サポートが切れたPHPから、計画的に移行する

この記事が、次に何かが起きたときに、あなたとあなたのサイトを守る助けになれば幸いです。状況は日々動いています。最新の情報は、PHP公式サイトや、契約先の事業者の告知で確認してください。

参考文献・参照元

【公式・公的機関】

【セキュリティ企業・事業者の発表（海外）】

【海外の報道】

【国内の報道・解説】

ご注意

この記事は、2026年10月22日夕方時点で公開されている情報をもとに、筆者が個人の立場でまとめたものです。内容の正確性、完全性、最新性を保証するものではありません。脆弱性をめぐる状況は時間単位で変わるため、記事の公開後に新しい事実が判明したり、各社の対応が変わったりしている可能性があります。

記事中の「筆者の見立て」や評価は、集めた情報にもとづく個人の意見であり、特定の事業者や製品を推奨・批判するものではありません。セキュリティ対策や、サイトの停止・再開、個人情報の取り扱いなどの判断は、必ずご自身の責任で、PHP公式サイトや契約先の公式案内、必要に応じて専門家の助言を確認したうえで行ってください。

この記事の情報を利用した結果として生じたいかなる損害やトラブルについても、筆者およびサイト運営者は一切の責任を負いません。

調べてみた
PHP 危険 気になった 脆弱性

この記事が気に入ったら
フォローしてね！

よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

シヴィエさんのアバター シヴィエさん

手帳が続かない・考えすぎて動けない、そんな時期を何度も経験してきました。
手帳歴20年以上、GTD・振り返り・小さな習慣を実践しながら、少しずつ自分なりの整理術を見つけてきた人間です。
「頑張りすぎない改善」をテーマに、手帳・習慣化・心理・オカルト・日常の気になることを丁寧に発信しています。

関連記事

目次