PHPの重大な脆弱性で何が起きたか：修正版が出るまでの経緯と、次に備えて平時に決めておく5つのこと

2026年10月21日の夜、国内の多くのWebサービスが、予定外のメンテナンスに入りました。原因は、Webサイトの裏側で広く使われているプログラミング言語、PHPに見つかった2件の重大な脆弱性です。

PHPは、WordPressをはじめ、多くの業務システムやECサイトで使われています。W3Techsの調査では、サーバー側の言語が分かっているWebサイトのうち69.3%がPHPを使っています（W3Techs、2026年10月22日時点）。自社のサイトや業務システムが関係するかどうか、気になっている方も多いはずです。

この記事では、まず何が起きたかを、公式発表と公的機関の情報をもとに整理します。そのうえで、今回の出来事から分かったことと、次に同じような脆弱性が見つかったときに慌てないために、平時に決めておきたいことをまとめます。

開発会社や保守会社にシステムを任せていて、「何を確認すればいいのか」をすぐに知りたい方は、クリーヴァが運営する発注者向けメディア SucSak の記事「PHPの脆弱性への対応は？発注側が開発会社に確認する6点」から読むことをおすすめします。確認する項目と、回答を書面で残す理由を、発注する側の立場でまとめています。

何が起きたか：要点

PHPの開発チームは、2026年10月21日に、2件の重大な脆弱性を直した修正版を公開しました（PHP公式のお知らせ）。要点は次のとおりです。

2件の脆弱性は、どちらも「前のリクエストが中途半端に残した状態を、後のリクエストが使ってしまう」という性質を持っています。1件目（CVE-2026-109618）は、メモリが足りなくなって処理が途中で止まったときに、初期化が終わっていないデータが残るもの。2件目（CVE-2026-109619）は、リクエストが終わったあとも内部の状態が消されずに残り、同じ処理の担当（ワーカー）が次のリクエストでそれを使ってしまうものです。

重要なのは、これがPHPそのものの問題だという点です。発見者の1社であるWizは、当時最新のWordPress、Drupal、Joomlaのコンテナイメージで、認証なしにプログラムを実行できることを示しました。パスワードやAPIキーを含むメモリの内容を読み出せることも示しています（Wiz）。WordPressやプラグインを最新にしていても、PHPが古ければ影響を受けます。

なお、深刻度の数字は、評価する組織によって違います。PHPはCVSS v4.0で9.2、米国のNVDはCVSS v3.1で9.8、Red HatはCVSS v3.1で8.1と評価しています（piyolog のまとめ）。どの評価でも、高い深刻度であることに変わりはありません。

修正版が出るまでの経緯

今回は、修正版の公開が事前に予告されていました。ところが、予告から公開までの間に、情報の一部が外に出ていました。日本時間で、経緯を並べます。

経緯は、PHPの開発を支える団体 The PHP Foundation の説明（The PHP Foundation）と、piyolog のまとめをもとにしています。The PHP Foundation によると、報告者の1社が、攻撃の手順を示す動画を誤って公開してしまい、その複製が広がって、攻撃コードづくりを早める結果にもなりました。

予告の時点で、PHPの開発チームは「どちらかの脆弱性の詳細が公になった場合や、実際の悪用が確認された場合は、予定より早く公開することがある」（筆者訳）と書いていました。公開を1日早めたのは、早く出すことと、各OSの提供元が更新を用意して、利用者が素直に更新できる状態を両立させるための判断だったと説明しています。

国内では、修正版の前に「止める」判断が相次いだ

10月21日の夕方から夜にかけて、国内では多くの組織が、Webサービスを止めたり、一部の機能を制限したりしました。ITmediaは、保育施設向けのコドモン、ゲームの Shadowverse: Worlds Beyond、さくらのレンタルサーバなどが緊急メンテナンスに入ったと報じています（ITmedia NEWS）。

piyolog は、各組織の告知で確認できた範囲で、国の機関、自治体、金融機関、交通、大学、ゲーム、ECなど、211の組織がサービスの停止や制限をしたと数えています（piyolog、10月22日午前時点）。

止めた理由の多くは、予防です。修正版の公開は夜の23時の予定で、それまでは詳細も分かりません。修正版が出れば、攻撃する側も修正の中身から脆弱性を調べられます。IPAも、修正版の公開後は攻撃者が極めて短時間で悪用するおそれがあるとして、すぐに更新できる準備を求めていました（IPA）。

米国のCISAは、すぐに更新できないシステムや、PHP 8.1以前で動いているシステムは、更新できるまでオフラインにするよう求めています（CISA）。止めるかどうかは、「更新がいつ終わるか」と「止めたときに業務やお客さまにどれだけ影響するか」の比べ合いです。今回は、その判断を、多くの組織が数時間のうちに迫られました。

実際に悪用されているのか

悪用の状況は、情報源によって見方が分かれています。CISAは、公開の時点で悪用を観測していないとしています。一方で、GMO Flatt Security は、悪用できると主張するコードがネットに出回り始めたと伝えています（GMO Flatt Security）。複数のセキュリティ企業が、攻撃の試みを観測したと発表しています（piyolog）。

「まだ悪用は確認されていない」という情報だけを見て、更新を後回しにしないことが大切です。観測されていないことと、起きていないことは同じではありません。

今回、何が特別だったのか

PHPの脆弱性は、これまでも何度も見つかってきました。今回、ここまで大きな騒ぎになった理由は、次の5つにまとめられます。

1. 使われている範囲が広く、アプリの作りに関係なく影響した

ふつうの脆弱性は、特定のプラグインや、特定の書き方をしたアプリにだけ影響します。今回はPHPの中の問題なので、PHPで動くほぼすべてのWebシステムが確認の対象になりました。Wizは、PHP 5.4以降のほぼすべての版が、少なくとも1件の影響を受けるとしています。

2. 詳細が出る前に、情報の一部が外に出た

CVE番号の流出、報告者による動画の誤公開、取り決めより早い修正の公開。いくつもの「漏れ」が重なり、修正版が出る前から、攻撃の準備が進みうる状態になりました。

3. AIが、見つけることと攻撃コードを作ることの両方を速めた

今回の脆弱性の報告には、AIを使ったセキュリティの調査が関わっています。CVEの記録では、Wiz、Calif.io、OpenAIが報告者として挙げられています（piyolog）。The PHP Foundation も、報告の検証などにAIのツールを使っていると説明しつつ、判断と修正は人が行っていると強調しています。

一方で、Wizは、今回の脆弱性は10年以上前からあったもので、AIはむしろ「攻撃に使うまでのハードル」を大きく下げたと書いています。脆弱性が公開されてから攻撃が始まるまでの時間は、これからさらに短くなると考えておいたほうがよいでしょう。

4. 見つかってから直るまでに、長い時間がかかっていた

The PHP Foundation の説明によると、今回の問題の最初の兆しは、2024年に行われた外部の監査の中で、すでに見つかっていました。ところが、具体的な攻撃の方法が分からず、直し方の合意も難しかったため、修正の作業は何か月も止まったり動いたりを繰り返しました。2026年8月に、複数の報告者から、認証なしでプログラムを実行できるという報告が届いて、ようやく全体の深刻さが分かりました。

The PHP Foundation は、この経緯を「構造的な失敗」と書いています。セキュリティの判断を全員の合意で決める進め方や、限られた人数で対応していたことが原因だとして、多数決で決められるようにすることや、担当者を増やすことを発表しました。PHPのような、世界中で使われているソフトの安全も、少人数の開発者の働きに支えられています。このことは、使う側も知っておきたい事実です。

5. 古い版が取り残された

PHP 8.1以前には、PHPからの修正版は出ていません。サポートが終わった版を使い続けていたシステムは、OSの提供元が独自に修正を出していない限り、新しい版に移るまで危険な状態が続きます。PHP 8.2も、2026年12月31日でセキュリティの修正が終わります（PHP のサポート期間）。

いま確認したいこと

今回の脆弱性への対応がまだ終わっていない場合は、次の3点を先に確かめてください。

1. 自社のシステムがPHPで動いているか、版はいくつか。 IPAもCISAも、最初にやることとして、PHPを使っているシステムの洗い出しを挙げています。製品やサービスの中に組み込まれているPHPもあります。
2. 修正版に更新したか。 8.5.12、8.4.27、8.3.36、8.2.35 のいずれかになっているかを確かめます。PHPの公式発表は、設定で影響を減らす暫定の方法も示していますが、同時に「インストールを安全にするものではない」と明記しています。暫定の設定は、更新までのつなぎとして扱います。
3. 更新を誰がするのか。 レンタルサーバーなら、サーバー側のPHPは事業者が更新することが多いものの、古い版を選んでいる場合は、利用者が新しい版に切り替える必要があります。自社で管理するサーバーや、開発会社に保守を任せているシステムは、その担当者が更新します。

更新したあとに確かめること

更新が終わっても、更新する前に攻撃を受けていた可能性は残ります。次のような兆しがないか、ログを確かめておきます。

• PHPの処理が、シェル（コマンドを実行する仕組み）を起動したり、外部からツールをダウンロードしたりしていないか（CISA）
• ファイルのアップロードの形式（マルチパート）を使った見慣れないリクエストのあとに、メモリ不足のエラーが続いていないか
• サーバーのエラー（HTTP 500）が繰り返し返されていないか
• セッションのCookie（PHPSESSID）が、異常に長かったり、形が崩れていたりしないか
• PHPの処理の担当（ワーカー）が、理由なく何度も入れ替わっていないか

2つ目から5つ目は、Wizが挙げている兆しです（Wiz）。GMO Flatt Security は、攻撃を受けた疑いがある場合には、読み出された可能性のあるデータを調べることや、そのサーバーに与えている権限（クラウドの権限やサービスアカウント）から、ほかのシステムに広がるおそれがないかを確かめることも挙げています（GMO Flatt Security）。メモリの中にはパスワードやAPIキーが入っていることがあるので、疑いがあるときは、それらを新しいものに変えることも考えます。

開発会社や保守会社に任せている場合

開発会社や保守会社に任せている場合に、何をどう確認すればよいかは、SucSak の「発注側が開発会社に確認する6点」に詳しくまとめています。システムの一覧と版、更新の日時と動作確認の範囲、暫定の設定、ログの確認、更新できない環境の扱い、保守契約の範囲。この6つを確認し、回答を書面で残しておくと、あとから「やったはず」「聞いていない」のすれ違いを防げます。

次に備えて、平時に決めておく5つのこと

今回、多くの組織が夜中に判断を迫られました。重大な脆弱性は、これからも見つかります。そのたびに慌てないために、落ち着いている今のうちに決めておきたいことを5つ挙げます。

1. 動いているソフトと版の一覧を作っておく

IPAもCISAも、まず洗い出しを求めました。逆に言えば、一覧がない組織は、最初の数時間を「どこでPHPが動いているのか」を調べることに使ってしまいます。

一覧は、立派な仕組みでなくてかまいません。表計算ソフトで、次のような項目をそろえておくだけで、判断の速さが変わります。

ポイントは、「インターネットに公開しているか」と「止めたときの影響」まで書いておくことです。

自社で作ったシステムだけでなく、買ったソフトや機器の中でPHPが動いていることもあります。IPAは、製品に組み込まれたPHPについては、製品の説明書や、提供元のセキュリティ情報で確かめるよう案内しています。そのうえで、使っているすべての製品を一つずつ確かめる必要はない、ともしています。一覧には、提供元のセキュリティ情報がどこに出るかも書いておくと、いざというときに探す手間が省けます。今回のように、全部を同時には直せないとき、どれから手を付けるかを決める材料になります。CISAも、インターネットに公開しているシステムから優先して更新するよう求めています。

2. サポートの期限を、予定表に入れておく

PHPは、それぞれの版に、セキュリティの修正を出す期限があります。期限を過ぎた版には、今回のような重大な脆弱性が見つかっても、修正版が出ません。

出典：PHP のサポート期間

版を上げる作業には、動作の確認を含めて時間がかかります。期限の半年前には、予算と担当を決めておくと安心です。PHPに限らず、OSやデータベース、CMSにも同じような期限があります。一覧に「サポートの期限」の列を足しておくと、見落としを防げます。

3. 更新の担当と費用を、契約で決めておく

今回のような緊急の更新を、誰が、いつまでに、いくらでやるのか。これが決まっていないと、夜中に連絡を取り合いながら、費用の話から始めることになります。

確認しておきたいのは、次のような点です。

• 保守契約に、PHPやOSの緊急の更新が含まれているか
• 含まれていない場合、緊急の作業はどう頼み、費用はどう決まるか
• 夜間や休日に連絡が取れるか、何時間以内に動いてもらえるか
• 更新のあと、どこまで動作を確認するか

受託開発の保守にどこまで含まれるのかは、SucSak の「受託開発の保守の範囲と費用相場」でも整理しています。

4. 「止める」基準と、止めたときの手順を決めておく

今回、止めるかどうかの判断が、多くの組織を悩ませました。止めれば売上や業務に影響が出ます。止めなければ、攻撃を受けるおそれがあります。この判断を、情報が足りない夜中に、ゼロから考えるのは大変です。

平時に決めておけるのは、たとえば次のようなことです。

• 誰が決めるか：止める判断をする人と、その人に連絡が取れないときの代わりの人
• 何を基準にするか：「インターネットに公開していて、深刻度が最上位で、数時間以内に更新できないときは止める」のような、あらかじめ合意した基準
• どう止めるか：サイト全体を止めるのか、ログインや管理画面など一部だけを止めるのか。メンテナンス画面に切り替える手順
• 誰に、どう知らせるか：お客さまへの告知文のひな形、社内への連絡の流れ

今回、自治体の中には、公式サイトを簡易版のサイトに切り替えて、最低限の情報を出し続けたところもありました（piyolog）。「止める」にも段階があることを、事前に考えておくと選べる手が増えます。

5. 情報の受け取り先と、防御の重ね方を決めておく

今回の流れでは、PHPの公式の予告から修正版の公開まで、丸1日ほどありました。この時間を準備に使えたかどうかは、予告にすぐ気づけたかで決まります。

情報の受け取り先は、少なくとも次の3つを決めておくとよいでしょう。

• ソフトの公式：今回なら PHPの公式サイトのお知らせ
• 公的機関：IPA の重要なセキュリティ情報、JPCERT/CC の注意喚起
• 使っているサービスの事業者：レンタルサーバーやクラウドの障害・メンテナンス情報

あわせて、更新までの時間を稼ぐ防御も考えておきます。今回は、Cloudflare などのWAF（Webアプリケーションファイアウォール）の事業者が、既知の攻撃の経路をふさぐルールを素早く配りました。CISAも、更新までのあいだ、WAFが一定の防御になりうるとしています。ただし、WAFも暫定の設定と同じく、更新の代わりにはなりません。

更新したあとは、ログの確認も欠かせません。CISAは、PHPの処理がシェルを起動したり、ツールをダウンロードしたりする不審な動きを監視するよう求めています。ログが残っていなければ、攻撃を受けたかどうかを確かめられません。ログがどこに、どれくらいの期間残るのかも、平時に確かめておきたい点です。

おわりに

今回の出来事で、多くの組織が「どこでPHPが動いているか分からない」「誰が更新するのか決まっていない」「止めるかどうかを夜中に決めなければならない」という状況に置かれました。どれも、脆弱性が見つかってから考え始めると間に合わないことです。

重大な脆弱性は、使っている技術を選んだ時点で、いつか必ず向き合うことになります。大切なのは、見つかったときに速く動ける状態を、ふだんから作っておくことです。システムの一覧、サポートの期限、契約、止める基準、情報の受け取り先。どれも、今日から少しずつ始められます。

いま対応の途中で、開発会社や保守会社に何を確認すればよいか迷っている方は、SucSak の「PHPの脆弱性への対応は？発注側が開発会社に確認する6点」をあわせてご覧ください。