2026年10月21日、ウェブサイトの開発に広く使われているプログラミング言語「PHP」に、重大な脆弱性が2件見つかったことが公表され、修正版が公開された。
修正版の公開が予告された当日から公開後にかけて、官公庁や自治体、金融機関、交通、外食、エンターテインメントなど、業種を問わず多くの組織が、ウェブサイトやサービスを一時的に停止した。
その多くは、被害が確認されたからではなく、被害を防ぐための予防的な措置だった。
一方で、全ての組織がすぐに止める判断を下せたわけではなかっただろう。自社のどのサービスにPHPが使われているのかを把握するところから始めた組織や、委託先からの連絡を待つしかなかった組織もあったと考えられる。
本稿では、今回何が起きたのかを整理したうえで、AI時代に重大な脆弱性とどう向き合うべきかを考える。
そのうえで、「止める判断」を難しくした要因と、企業が平時に備えておくべきことを示す。
何が起きたのか
まずは、今回の脆弱性がどのようなもので、それを受けて企業や行政機関がどう対応したのかを整理する。
業種を問わず多くの組織がサービスを止めた一方で、止める範囲を絞った組織や、サービスそのものを終えた組織もあった。
ウェブの7割を支える言語に見つかった脆弱性
PHPは、ウェブサイトの裏側で動くプログラムを作るための言語だ。
調査会社W3Techsによると、サーバー側で使われている言語が分かるウェブサイトのうち、69.2%がPHPを使っている。
WordPressをはじめ、企業サイトやネットショップの多くがPHPで動いている。
今回見つかった脆弱性は、「CVE-2026-109618」「CVE-2026-109619」の2件で、報道や各社の発表では「PHP2Shell」と呼ばれることが多い。
脆弱性の深刻度を10点満点で示すCVSSの値はいずれも9.2で、最も深刻な「緊急」（9.0以上）に分類される。どちらも、認証なしに外部からプログラムを実行されるおそれがある脆弱性だ。
影響を受けるのは、PHP5.4から最新の8.5までの、過去10年以上にわたるほぼ全てのバージョンだ。
PHPの開発チームは、サポート中の8.2から8.5について修正版を公開した。
一方、サポートが終了している8.1以前には正式な修正版は提供されず、7.4、8.0、8.1についてのみ、ソースコードの形で最小限の修正が示されるにとどまった。
業種を問わず相次いだ「予防的な停止」
修正版の公開前後から、国内では多くの組織がサービスを止めた。
報道や各組織の発表によると、国税庁や財務省、厚生労働省、文部科学省、大阪市といった行政機関のほか、銀行、航空会社、鉄道会社、外食チェーン、ゲーム会社、レンタルサーバー事業者などが、ウェブサイトや一部のサービスを一時的に停止したり、緊急メンテナンスを実施したりした。
こうした停止の多くは、被害が出たことを示すものではない。
発表時点で不正アクセスや情報漏えいを確認していないとする組織が多く、修正版の適用を終えたものから順次再開していった。
情報処理推進機構（IPA）は、有効な暫定対策を講じることが難しい場合には、攻撃を受けた際の被害や業務への影響を踏まえ、外部からのアクセス遮断やサービスの一時停止が必要か判断するよう求めていた。
今回の一斉停止は、こうした判断の積み重ねだったといえる。
影響は国内にとどまらない。
オランダでは、行政情報サイトや電子認証サービスが予防的な停止の対象となり、フランスやドイツ、フィンランドでも一部の政府関連サイトが停止したと報じられている。
止める範囲を絞った組織、サービスを終えた組織
対応は一様ではなかった。
例えば、さくらインターネットは、会員関連の機能や一部のサービスを予防的な緊急メンテナンスで止め、レンタルサーバーで提供しているPHPに修正を適用した。一方で、VPSについては、サービスを提供する部分でPHPを使っていないため影響はないと発表した。
自社のサービスのどこにPHPが使われているかを把握していたからこそ、止める範囲を絞り込めた例といえる。
エックスサーバーも、利用者のサイトの表示やメールの送受信は止めずに、公式サイトや管理画面などに限って停止した。そのうえで、サポートが終了したバージョンを含め、PHP 5.6から8.5までに修正を適用したと告知している。
サービス全体を止めるのではなく、影響の大きい部分を見極めて対応した例だ。
一方で、PHPの脆弱性への対応が難しいとして、サービスの終了を発表したゲームもあった。
脆弱性への対応が、事業そのものの継続を左右した例である。
重大な脆弱性への緊急対応は新しくない
広く使われているソフトウェアに重大な脆弱性が見つかり、多くの組織が一斉に対応に追われる。こうした事態は、今回が初めてではない。
例えば、2021年には、Javaで書かれたシステムで広く使われている「Log4j」に重大な脆弱性が見つかり、世界中の組織が自社のシステムのどこにLog4jが含まれているのかを調べることに追われた。
PHPでも、2024年にWindows上で動くPHPの脆弱性（CVE-2024-4577）が見つかり、公表後まもなく攻撃に悪用された。
サポートが終了したソフトウェアが使われ続ける問題も、以前から指摘されてきた。
前述のW3Techsの統計でも、PHPを使っているウェブサイトのうち、すでにサポートが終了しているバージョン7や5を使っているサイトは、合わせて3割を超えている。
つまり、「何が動いているかを把握する」「速やかに修正を適用する」「サポートが切れる前に移行する」という対策の基本は、これまでと変わっていない。
それでも今回、多くの組織が「止める」ことを選んだ背景には、いくつかの変化がある。
AI時代の脆弱性対応に求められる判断の速さ
対策の基本が変わっていないとすれば、なぜ今回、これほど多くの組織が「止める」ことを選んだのか。
その背景には、脆弱性が見つかってから攻撃が始まるまでの流れに起きている、3つの変化がある。
AIが脆弱性を見つけるようになった
1つ目の変化は、脆弱性を見つける側にAIが加わったことだ。
今回の脆弱性を見つけた米セキュリティ企業Wizの研究チームは、自社のAIに加えて、GoogleやOpenAIのAIモデルを使い、脆弱性の発見から攻撃コードの作成までを進めたとしている。
同社によると、2026年8月19日に最初の脆弱性を見つけ、その数日後には、DrupalやWordPressなどを対象に、認証なしで外部からプログラムを実行できることを確認した。
見つかった不具合は、10年以上前のものを含む設計上の判断に起因するものだったという。
長年にわたって見過ごされてきた不具合を、AIを使った調査が短期間で掘り起こしたことになる。
AIが脆弱性の発見を速めることは、防御側にとって助けになる。
ただし、同じことは攻撃する側にもできる。
なお、AIが攻撃と防御の両方に使われる状況については、「AIが攻撃に使われるとき防御側のAIは動くのか？NVIDIAら「オープンAI連合」に見る備えるべき設計とは」も参考にしてほしい。
公表前から攻撃が始まる
2つ目の変化は、公表と攻撃の時間差が縮んでいることだ。
今回、脆弱性の識別番号などの情報が公表前に出回り、攻撃の様子を示す動画が誤って公開されるといった混乱があった。
そのため、修正版の公開は当初の予定から1日前倒しされた。
Amazonの脅威情報チームは、公表の4日前にあたる10月17日に、この脆弱性を狙ったとみられる攻撃の試みを観測したと報告している。
つまり、脆弱性が公表された時点で、すでに攻撃を受けていた組織があった可能性があるのだ。
そのため同社は、攻撃を受けたかどうかを調べる際は、公表日からではなく、攻撃の試みが最初に確認された10月17日までさかのぼって調べるよう呼びかけた。
同社はまた、修正版の公開から実際に機能する攻撃コードが出回るまでの時間が短くなっていると指摘している。
AIを使えば、修正版や脆弱性の公表内容を分析して攻撃コードを作る手間が小さくなるためだ。
判断に使える時間が短くなった
3つ目の変化は、その結果として、企業が判断に使える時間が短くなったことだ。
これまでは、修正版の公開を待ち、影響を調べ、準備を整えてから適用する、という手順を踏む余裕があった。
しかし、公表前から攻撃が始まりうる状況では、その余裕は小さくなる。
修正版をすぐに適用できない、あるいは影響範囲をすぐに把握できない組織にとって、新たな攻撃を確実に防ぐ手段は、サービスを止めることだった。
今回の一斉停止は、判断の時間が足りないことへの、現実的な答えだったとも言える。
「止める判断」を難しくした4つの要因
一方で、止めること自体も簡単な判断ではない。
サービスを止めれば、顧客や業務に影響が出る。
今回の対応から見えてきたのは、止める判断を難しくする4つの要因だ。
1. 何が動いているか分からない
1つ目は、自社のどのサービスやシステムにPHPが使われているのかが分からないことだ。
PHPは、自社で開発したシステムだけでなく、購入したソフトウェアや、外部のサービスの中でも使われている。
さらに、PHPはウェブサイトだけでなく、ファイアウォール（外部からの不正な通信を防ぐ機器）やNAS（ネットワークに接続する記憶装置）、ルーター（ネットワーク同士をつなぐ機器）といった機器の管理画面にも組み込まれていることがある。
Google Cloudは、PHPを組み込んだ機器を洗い出し、メーカーと連携してファームウェアの更新や暫定対策を進めるよう呼びかけている。
また、国内の機器メーカーも対応を進めている。
例えば、ヤマハは、ルーターやスイッチなどの主要なネットワーク製品はPHPを使っていないため影響がないと発表し、一部の製品については影響を確認中だとした。
アイ・オー・データ機器は、現行品と生産終了から5年以内の製品を対象に調査を進め、それより古い製品については使用を控え、買い替えを検討するよう案内している。
機器の場合、利用者が自分でPHPを更新することはできず、メーカーの調査と修正を待つしかない。
何が動いているかが分からなければ、どこを止めればよいかも分からない。
止める範囲を絞り込めなければ、必要以上に広く止めるか、止めずに様子を見るかの二択になってしまう。
2. 誰が直すのか決まっていない
2つ目は、修正の責任が誰にあるのかが、はっきりしていないことだ。
例えば、レンタルサーバーを使っている場合、サーバー事業者が提供するPHPには事業者が修正を適用する。
一方、VPSのように、利用者が自分でOSやソフトウェアを管理するサービスでは、修正するのは利用者自身だ。
さくらインターネットも、VPSの中で動かしているPHPについては、利用者に更新を求めている。
クラウドでも同じことが言える。
Google Cloudでは、一部のサービスは自動的に修正されたが、それ以外のサービスでは、利用者がアプリケーションを作り直して配置し直す必要があった。
つまり、クラウドを使っていれば全てが自動的に安全になる、というわけではないということだ。
ウェブサイトの制作や運用を外部の会社に任せている場合は、さらに複雑になる。
修正するのは制作会社なのか、運用会社なのか、サーバー事業者なのか。契約で決まっていなければ、まずそれを確認するところから始めることになる。
さらに言えば、PHPそのものの開発も、限られた人々に支えられている。
PHPの開発を支援するPHP Foundationは、今回の脆弱性の一つにつながる不具合の兆候に2024年の時点で気づいていながら、修正の方針を決めきれず、対応できる開発者も少なかったことを、構造的な失敗だったと認めている。
自社のシステムを支えるソフトウェアが、誰によって、どのような体制で保守されているのか。その点も、修正の責任を考えるうえで無視できない。
3. サポート切れで修正版がない
3つ目は、サポートが終了したバージョンには、正式な修正版が提供されないことだ。
インターネットに公開されているPHPのうち、バージョンが分かるものの半数以上が、サポートの終了したバージョンで動いていたとする調査が複数ある。
例えば、セキュリティ企業のMalloryは、検索サービスShodanのデータをもとに、2026年10月20日時点でその割合を59%とした。CybelAngelも、修正版の公開後に調べた結果を54%としている。
こうしたサービスでは、修正版を適用するという通常の対応がとれない。
サポート対象のバージョンに移行するには、アプリケーションの改修が必要になることも多く、すぐには終わらない。
前述のとおり、対応が難しいとしてサービスを終了したゲームもあった。
サポート切れのまま使い続けてきたことのつけが、一度に回ってきた形だ。
現在サポート中のPHP 8.2も、2026年末でサポートが終了する予定であり、この問題は今回で終わりではない。
4. 止めたときの影響が見積もれていない
4つ目は、サービスを止めたときに、業務や顧客にどのような影響が出るのかを、事前に見積もれていないことだ。
保育施設向けのサービスを提供するコドモンは、今回、修正版の公開前に予防的にサービスを止めた。
同社は、攻撃を受ければ預かっているデータに重大な影響が出るおそれがあり、この種の攻撃は検知した時点ですでに被害が出ている可能性が高いため、攻撃を防ぐための予防的な措置として止めたと説明している。
止めることによる業務への影響よりも、情報漏えいを避けることを重く見た判断だ。
こうした判断を短時間で下せるのは、守るべき情報の重さと、止めたときの影響を比べる軸を持っている場合だ。
逆に、その軸がなければ、止めるべきか、止めずに修正を急ぐべきかを、その場で議論することになる。
今回の停止の中には、止める範囲を絞った例もあった。
例えば、前述のエックスサーバーは、公式サイトや管理画面などは止めたが、利用者のサイト表示やメールの送受信は止めなかった。
止めるか止めないかの二択ではなく、何を止め、何を守るかを切り分けられるかどうかが、影響の大きさを左右する。
一方で、止めることの影響が大きいサービスもある。
例えば、聴覚や発話に障害のある人の通話を通訳オペレーターが仲介する電話リレーサービスは、法律で公共インフラと位置づけられており、24時間365日提供されている。
このサービスも今回、PHPの脆弱性への対応のために停止し、再開は10月23日になった。
停止中も緊急通報は利用できるようにしていたが、運営団体は、今回の停止を「長時間にわたるサービス停止」と表現している。
社会的な役割の大きいサービスほど、止めたときの影響を見積もったうえで、どのような対応を施すかを事前に決めておく必要がある。
なお、多くの組織が「被害は確認されていない」と発表しているが、JPCERTコーディネーションセンターは、痕跡が見つからなくても攻撃を受けていないとは断定できないとして、侵害の有無を確認するよう求めている。
つまり、サービスを再開した後も、確認の作業は続けなければならないということだ。
企業の状況別に、いま何をすべきか
最後に、ここまでの内容を踏まえて、企業が平時に備えておくべきことを整理する。
自社のシステムをどのように運用しているかによって、優先すべきことは異なる。
そこで、ウェブサイトの制作や運用を外部に任せている企業、自社でシステムを運用している企業、止められないサービスを持つ企業の3つに分けて考える。
ウェブサイトの制作や運用を外部に任せている企業
まず確認したいのは、自社のウェブサイトやサービスについて、誰が何を管理しているかだ。
具体的には、ウェブサイトがどのサーバーで動いているのか、そこで使われているソフトウェアの更新は誰が担当するのか、緊急時に誰に連絡すればよいのかといった点だ。
こうした点を、制作会社や運用会社、サーバー事業者との間で整理しておきたい。契約や保守の範囲に、脆弱性への対応が含まれているかどうかも確認しておく必要がある。
今回の脆弱性についても、修正版を適用したかどうかだけでなく、攻撃を受けた痕跡がないかを確認したかどうかを、委託先に尋ねておきたい。
前述のとおり、公表前から攻撃の試みが観測されているため、確認は公表日より前にさかのぼって行う必要がある。
自社でシステムを運用している企業
自社でシステムを運用している企業では、まず、どのシステムで、どのソフトウェアの、どのバージョンが動いているのかを一覧にしておくことが出発点になる。
ウェブサーバーだけでなく、購入したソフトウェアや、ネットワーク機器、NASなどに組み込まれたソフトウェアも対象に含めたい。
そのうえで、サポートが終了している、あるいは近く終了するソフトウェアを洗い出し、移行の計画と予算を確保しておく。
修正版が出てから移行を考えるのでは、今回のように間に合わない。
また、修正版を速やかに適用できる体制も欠かせない。
検証環境を用意しておく、適用の手順を決めておく、といった準備があれば、判断から適用までの時間を縮められる。
なお、Google Cloudは、PHPを更新しただけでは、すでに動いている処理に古いプログラムが残り続けるため、更新後にPHPを動かしているサービスを再起動する必要があると注意を促している。
手順書には、こうした細かな点まで含めておくことが望ましい。
止められないサービスを持つ企業
止めることが難しいサービスを持つ企業ほど、平時の準備が重要になる。
まず、自社のサービスを、止めても影響が限られるもの、短時間なら止められるもの、止められないものに仕分けておきたい。
そのうえで、止められないサービスについては、止めずに守るための手段を用意しておく。
例えば、外部からのアクセスを一時的に制限する、攻撃とみられる通信を遮断する仕組みを使う、といった方法だ。
あわせて、止める判断を誰が下すのかも決めておきたい。
情報システム部門だけで決めるのか、事業部門や経営層が加わるのか。夜間や休日に判断が必要になった場合、誰に連絡するのか。
今回の修正版は、日本時間の夜11時に公開された。判断の手順が決まっていなければ、こうした時間帯に迅速に動くことは難しい。
脆弱性への備えは、「止める判断」の設計でもある
「広く使われているソフトウェアに重大な脆弱性が見つかり、多くの組織が対応に追われる」といった構図は、以前から変わっていない。
対策の基本も、何が動いているかを把握し、速やかに修正を適用し、サポートが切れる前に移行する、という点で変わらない。
変わったのは、脆弱性が見つかってから攻撃が始まるまでの速さだ。
AIが脆弱性を見つける速さを上げ、公表前から攻撃が始まりうる状況では、企業が判断に使える時間は短くなる。
修正が間に合わないとき、新たな攻撃を確実に防ぐ手段は、止めることになる。
だからこそ、脆弱性への備えは、修正の速さだけでは完結しない。
何が動いているのかを知り、誰が直すのかを決め、どのサービスなら止められるのか、誰が止める判断を下すのかを、平時に決めておくこと。
今回の事態は、多くの組織に、その備えがどこまでできていたかを問いかけたと言えるだろう。
参考資料
- Usage statistics of PHP for websites（W3Techs）
- News Archive 2026（PHP）
- CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP（Rapid7）
- 【事前準備のお願い】PHPのセキュリティリリース公開予定について（IPA）
- PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)（IPA）
- 【PHP重大脆弱性】財務省・厚労省も一部サービス停止、アサヒGHD・京急など上場企業や欧州政府に波及（財経新聞）
- PHP脆弱性でサービス停止が相次いだ10月21〜22日、日本で何が起きたか（レジット）
- PHP脆弱性で停止した企業・サービス一覧【2026年】銀行・航空・ゲームの復旧状況（lifetrix）
- 【重要】PHPの脆弱性に関する当社の対応状況について（さくらインターネット）
- 予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ（エックスサーバー）
- PHPの重大な脆弱性が発覚。ゲーム業界への影響と各社の対応まとめ（4Gamer.net）
- Apache Log4j の脆弱性対策について(CVE-2021-44228)（IPA）
- Review of the December 2021 Log4j Event（Cyber Safety Review Board）
- Cyber Safety Review Board report on Log4j（FedScoop）
- PHPの脆弱性対策について(CVE-2024-4577)（IPA）
- New PHP Vulnerability Exposes Windows Servers to Remote Code Execution（The Hacker News）
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet（Wiz）
- Today’s PHP Security Release, and How We’re Strengthening PHP Security（PHP Foundation）
- Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot（AWS）
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619（Google Cloud）
- PHP脆弱性による当社ネットワーク製品およびサービスへの影響と対応について（ヤマハ）
- PHPの脆弱性に関する弊社調査・対応状況について（アイ・オー・データ機器）
- 2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming: What We Know About php2shell（CybelAngel）
- Supported Versions（PHP）
- PHP2Shellへの対応を振り返って（コドモン Product Team Blog）
- 【サービス提供の再開】PHPの脆弱性対応に伴うサービス提供の一時停止について（電話リレーサービス）
- 「電話リレーサービス料」の設定について（NTTコミュニケーションズ）
- PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起（JPCERT/CC）
現在、デジタルをビジネスに取り込むことで生まれる価値について研究中。IoTに関する様々な情報を取材し、皆様にお届けいたします。
