PHPの脆弱性はなぜ世界中で大騒ぎに？長年の欠陥が今になって問題化した理由

2026年10月、世界各地のWebサイトで緊急メンテナンスや一時停止が相次ぎました。原因は、Webサイトの裏側で広く使われているプログラミング言語「PHP」に見つかった重大な脆弱性です。

「PHPって何？」「サイトが止まったということは、ハッキングされたの？」。ニュースを見て、そんな疑問を抱いた人もいるでしょう。

今回の2件の欠陥は、条件によってはログインしていない第三者がサーバー上で不正なプログラムを実行できるほど深刻なものでした。ただし、脆弱性の発見やサービス停止は、それだけで情報漏洩が起きたことを意味しません。

さらに、欠陥の一つにつながる問題の兆候は、2024年の時点で確認されていました。それなのに、なぜ2026年10月になって世界中が対応を急ぐ事態になったのでしょうか。

この記事では、発見から修正までの経緯と、公開直前に何が起きたのかをたどります。WordPressへの影響や、一般の利用者・サイト運営者が確認したいことも整理します。

PHPの重大脆弱性で何が起きた？世界中でサイト停止が相次いだ理由

2026年10月21日、国内のWebサービスで緊急メンテナンスや一時停止の発表が相次ぎました。ネットショップ、ゲーム、保育施設向けのサービスなど、普段は別々に動いているサービスが、同じセキュリティ問題への対応を迫られたのです。

原因は、多くのWebサイトが共通して利用するPHP本体の重大な脆弱性でした。一つの企業のシステムに限った問題ではありません。

各社はなぜサービスを止める必要があったのでしょうか。また、停止したサービスでは本当に情報漏洩が起きていたのでしょうか。まずは発表された事実と、国内での対応を整理します。

2026年10月、PHPの重大な脆弱性2件に修正版が公開

PHPの開発チームは10月21日、2件の重大な脆弱性に対応する修正版を公開しました。識別番号は「CVE-2026-109618」と「CVE-2026-109619」。同じ時期に公表されたものですが、問題が生じる仕組みはそれぞれ異なります。

2件とも、深刻度の評価指標「CVSS v4.0」で9.2と評価されています。条件がそろえば、第三者が正規の利用者としてログインせずに、サーバー上で不正なプログラムを実行できる恐れがありました。

サーバーは、Webサイトの情報を保存し、利用者からの要求に応じて処理するコンピューターです。そこで本来許されない命令を実行されれば、内部の情報やサービスの運営に大きな影響が及ぶ可能性があります。もちろん、脆弱性があるだけで、すべてのサーバーが乗っ取られたわけではありません。

このような欠陥が、世界中で利用されるPHPの基本部分に見つかったことが、広範囲での緊急対応につながりました。

日本でもサービス停止や緊急メンテナンスが相次いだ

影響は専門的な開発サービスだけにとどまりませんでした。保育・教育施設向けICTサービス「コドモン」は10月21日、関連するサービスの即時停止を発表。施設の職員が使う機能だけでなく、保護者向けアプリも対象でした。

また、学校と保護者の連絡などに利用される「さくら連絡網」も、管理ページやメール・LINE配信機能などを一時停止しました。そのほか、ネットショップ作成サービス「BASE」、ゲームの「Shadowverse: Worlds Beyond」、さくらインターネットの一部サービスでも緊急メンテナンスやその予告が報じられました。

買い物、ゲーム、保育施設との連絡、Webサイト運営。一見関係のないサービスでも、裏側で同じ技術を使っていれば共通の問題への対応が必要になります。ただし、各社が同じ時間だけ停止したわけではありません。PHPの利用方法、システムの構成、更新作業の進め方によって、数秒の接続断で済む場合もあれば、機能やサービス全体を一時停止する場合もありました。

海外でも政府機関や公共サービスを含むWebサイトの予防的停止が報じられ、欧州のセキュリティ当局も迅速な対応を呼びかけました。今回の問題は、特定の国や業界に閉じたものではなかったのです。

サイト停止はハッキング被害を意味する？個人情報への影響は？

サービスが突然止まれば、「自分の個人情報が漏れたのでは」と心配になるかもしれません。しかし、脆弱性が存在すること、攻撃を受けること、攻撃が成功して情報漏洩が起きることは別です。

例えば、建物の窓に欠陥が見つかっても、必ず泥棒が入ったとは限りません。修理が終わるまでその部屋を使わない判断もあります。Webサービスの一時停止にも、被害を防ぐために外部からのアクセスを止め、安全確認を進めるという意味があります。

実際、「さくら連絡網」は発表時点で利用者情報の漏洩を確認しておらず、停止は予防的な措置だと説明しました。バンダイナムコエクスペリエンスも、脆弱性への対策を発表する一方、告知時点で悪用による被害や利用者データの流出を確認していないと案内しています。

もちろん、ある事業者で被害が確認されていないからといって、すべてのサイトで被害がなかったとは言えません。気になるサービスがある場合は、その運営者がいつ、どの範囲について発表した情報なのかを確認する必要があります。

一般の閲覧者が、自分のスマートフォンやパソコンのPHPを更新する必要は通常ありません。自分でWordPressなどを運営している場合は、サーバー側の更新状況を確認する立場になります。

では、これほど深刻な問題は、なぜ2026年になるまで表面化しなかったのでしょうか。事情をたどると、2024年のセキュリティ監査に行き着きます。

なぜPHPの欠陥が2026年になって大問題になったのか

今回の脆弱性は、2026年になって突然生まれたものではありません。PHP Foundationの説明によれば、問題の一つにつながる異常は、2024年の時点で開発者に認識されていました。

それでも、修正には時間がかかりました。攻撃につながる具体的な経路が確認されていなかったうえ、欠陥を直そうとすると、これまで正常に動いていたプログラムに影響する恐れもあったためです。

状況が大きく変わったのは2026年夏。AIを活用した研究を含む複数の調査で、問題を実際の攻撃に利用できることが示され、修正の優先順位が一気に高まりました。

2024年には問題の兆候が確認されていた

PHPの開発を支援する非営利団体「PHP Foundation」は、2026年10月21日、今回の脆弱性が発見・修正されるまでの経緯を詳しく公表しています。

2024年、PHPでは数年ぶりとなる外部セキュリティ監査が実施されました。監査を担当したのはQuarkslabです。監査で指摘された別の問題をPHP開発者が修正する過程で、メモリ不足時の処理に異常の兆候を見つけました。これは今回公表された「CVE-2026-109618」につながる問題です。

メモリとは、プログラムが動いている間に一時的なデータを置く場所のこと。PHPの処理中に使用できるメモリが足りなくなると、内部のデータをうまく整理できない場合がありました。

当時も悪用の可能性は検討されましたが、実際にどのような操作でサーバーへの深刻な攻撃につながるのか、具体的な経路は確認できていませんでした。影響がはっきりしている別の問題への対応も並行していたといいます。

2024年の時点で、今回の2件の脆弱性すべての危険性が完全に判明していたわけではありません。兆候を認識していた問題が、後に重大な攻撃につながると具体的に示された、というのが正確な経緯です。

危険な欠陥なのに、なぜすぐに修正できなかった？

問題の兆候が見つかっていたのなら、先に直しておけばよかったのではないか。そう感じるのは自然です。ところが、世界中のシステムで動くソフトウェアでは、危険な部分だけを単純に書き換えれば済むとは限りません。

PHP Foundationによれば、開発チームは複数の修正方法を検討していました。しかし、ある案では以前のPHPで正常に動いていたプログラムとの互換性を失い、別の案では新たなサービス停止の危険が生じます。多数の外部拡張機能に変更を求めなければならない方法もありました。

例えば、長年運営しているネットショップのシステムが、PHP内部の変更によって注文や会員管理を正常に処理できなくなれば、セキュリティのための修正が新たな業務障害を引き起こします。これは今回そうした障害が実際に起きたという意味ではなく、互換性を保つ必要性を示す一例です。

技術的な難しさに加え、PHP内部に深く精通した開発者が少なく、ほかの業務も担当していました。合意を重視する意思決定の中で、どの修正案を選ぶか判断が難航し、作業は停滞と再開を繰り返したといいます。

PHP Foundationはこれを、意思決定の仕組みと資源不足の両面に起因する構造的な失敗だったと認めています。したがって「仕方がなかった」と片づけることも、「危険性がすべてわかっていたのに意図的に放置した」と単純化することも、どちらも適切ではありません。

2026年夏、AIを活用した研究などで深刻な危険性が明らかに

転機となったのが2026年夏の研究です。PHP Foundationによれば、7月30日、セキュリティ企業CalifがPHPの監査を開始しました。OpenAIが支援するオープンソースの安全性向上の取り組み「Patch the Planet」の一環でした。

8月11日にはCalifの研究者が、ログインせずに成立する重大な攻撃経路を報告。同じ日にOpenAIも独立した調査で同じ根本原因を報告しました。さらに8月24日にWiz、9月18日にOpenAIから追加の攻撃経路が報告されています。

これにより、2024年には具体的な攻撃方法まで確認できなかった問題が、実際にサーバーへの不正なコード実行につながることが示されました。PHP Foundationは、8月11日以降、この問題の修正をセキュリティ関連業務の最優先事項にしたと説明しています。

研究にはAIも活用されました。ただし、AIが単独ですべての欠陥を発見し、修正まで終えたわけではありません。研究者が報告内容を検証し、PHPの開発者が安全な修正方法を検討するという作業が続きました。

長く残っていた欠陥が、突然生まれたのではなく、危険性を具体的に示せる段階になった。これが「なぜ今なのか」を理解するうえで大切な違いです。

そもそもPHPとは？なぜ世界中のWebサイトに関係するのか

ネットショップで商品を買うとき、会員サイトにログインするとき、ブログの記事を開くとき。私たちは普段、Webサイトの裏側でどんなプログラムが動いているかを意識することなく、サービスを利用しています。

そうした仕組みを支えるプログラミング言語の一つがPHPです。今回、まったく異なる業界のサービスが同じ脆弱性への対応を急いだ背景には、PHPが幅広いWebサイトで使われている事情があります。

PHPは何を担当し、WordPressとどう関係するのでしょうか。利用率の数字をどう読むべきかも含めて確認します。

ログインやネットショップなど、サイトの裏側を支えるPHP

例えばPHPで作られた会員サイトなら、利用者がページを開くと、サーバー側でPHPが動いて必要な情報を取得し、その人に合った表示内容を作ります。ブラウザには処理の結果が送られ、画面として表示されます。実際にはデータベースや別のプログラムも連携しています。

1. 利用者がブラウザで会員ページを開く
2. サーバーでPHPのプログラムが動き、必要な情報を取得する
3. その人に合ったページ内容を作る
4. 結果をブラウザに送り、画面に表示する

PHPが動いているのは、基本的に利用者のスマートフォンではなく、サイトを提供する側のサーバーです。普段Webサイトを閲覧するだけなら、自分でPHPをインストールする必要はありません。

もちろん、すべてのサイトがPHPを利用しているわけでもありません。それでも広く普及しているため、PHP本体の問題は、多数の運営者に共通する課題になります。

WordPressにも使われているため影響が広がりやすい

身近な例がWordPressです。WordPressはブログや企業サイトを作成・管理できる仕組みで、記事の投稿や画像管理、ページ編集などを行えます。このWordPressもPHPを使って動いています。

例えば記事を表示するとき、WordPressはサーバー上で動き、データベースから記事情報を取得してページを組み立てます。PHPはその動作を支える基盤の一つです。

ただし、今回の欠陥はWordPress本体ではなく、PHP側に見つかったものです。WordPress公式は今回の問題に対応するためのWordPress本体の特別な更新は必要ないと説明し、ホスティング会社の案内を確認してPHP側の対応を進めるよう呼びかけました。

WordPress本体が最新でも、サーバーで動くPHPが未修正ならPHP側の問題は残り得ます。一方、WordPressのサイトすべてで攻撃が成功したという意味でもありません。

「世界のサイトの約7割が危険」は本当なのか

PHPについて「世界のサイトの約7割で使われている」という数字を目にした人もいるでしょう。W3Techsの調査では、2026年10月21日時点のPHP利用率として69.3%という数値が紹介されています。

ただし、この数字には母数の条件があります。世界中のすべてのWebサイトではなく、サーバー側で利用するプログラミング言語を判別できたサイトを対象とした割合です。

したがって、「世界の全サイトの69.3%が今回の脆弱性で攻撃された」「約7割で情報漏洩が起きた」といった読み方は誤りです。また、PHPを使っているサイトでも、バージョンや実行環境、セキュリティ対策は異なります。

さらに、セキュリティ企業Palo Alto Networksの研究部門Unit 42は、今回の2件の脆弱性について、外部からアクセスできる2,260万件超のインスタンスに影響が及ぶ可能性があると報告しています。

ここでいうインスタンスとは、外部から確認できるサーバーやサービスの稼働単位を指します。必ずしもWebサイト一つにつきインスタンスが一つとは限りません。実際のWebサイト数や、被害を受けた件数と同じ数字ではないのです。

Unit 42の数字は、同社の観測データに基づき、今回の脆弱性の影響を受ける可能性がある公開インスタンスを推定したものです。2,260万件超の環境で攻撃が成功した、あるいは情報漏洩が確認されたという意味ではありません。

区別したいのは、PHPを利用しているサイト、今回の更新が必要な環境、外部に公開された影響可能性のあるインスタンス、実際の侵害が確認されたサイトです。これらの数字は、そのまま置き換えられません。

普及率が高いという数字から理解できるのは、一つの基盤技術に重大な欠陥が見つかると、多くのサービスで確認や対策が必要になるということ。その危険性をもう少し具体的に見ていきます。

今回のPHP脆弱性は何が危険？ログイン不要で攻撃される恐れも

Webサイトの不具合と聞くと、画面が表示されなくなったり、一部の機能が使えなくなったりする状態を想像するかもしれません。しかし、今回のPHPの問題は、それだけでは済まないものでした。

条件がそろうと、外部の第三者がサーバー上で不正なプログラムを実行できる恐れがあります。正規の利用者としてログインしなくても成立する攻撃が実証されていることも、深刻な点です。

原因は、PHPが内部でデータを扱う際の処理にありました。2件の脆弱性は何が違い、どのような場合に危険になるのでしょうか。

サーバー上で不正なプログラムを実行される可能性

今回の問題を理解するうえで知っておきたいのが「リモートコード実行（RCE）」です。離れた場所にいる第三者がネットワーク越しに、対象のコンピューターへ意図しない命令を実行させられる状態を指します。

通常、Webサイトの利用者は商品を検索したり、会員ページを開いたりできても、サーバー内部の命令を自由に動かせるわけではありません。しかし脆弱性が悪用されると、サーバー上のファイルや設定情報へ不正にアクセスされたり、攻撃用のプログラムを動かされたりする可能性があります。

実際の影響はPHPの実行権限、サーバーの設定、周辺の防御策によって異なります。欠陥があるだけですべての情報が盗まれるわけではありません。

さらに重大なのは「認証不要」という条件です。管理画面のログイン認証を突破しなくても、細工されたWebリクエストによって攻撃が成立する構成が実証されています。ただし、ログイン不要だからといって、誰でも何の条件もなく攻撃に成功するという意味ではありません。

PHP内部の処理ミスが重大な攻撃につながる仕組み

2件の欠陥は、どちらもPHP内部の「メモリ」に関係しています。メモリはプログラムが一時的に使うデータの置き場所で、必要になれば領域を確保し、使い終われば解放するという管理を行います。

1つ目のCVE-2026-109618は、メモリが不足したときの後始末に関する問題です。

PHPは処理の途中で使えるメモリが足りなくなると、作業を中断することがあります。本来なら途中まで用意したデータの状態を確認し、安全に処理を終えなければなりません。

ところが今回の欠陥では、準備が完了していないデータを、後片づけの際に正常なものとして扱ってしまう場合がありました。その結果、メモリ内の情報が壊れ、PHPが想定していない動作につながる恐れがあったのです。通常ならエラーとして終わる状況が、攻撃の足がかりになってしまう可能性があります。

2つ目のCVE-2026-109619は、すでに解放したメモリを再び使ってしまう問題です。

プログラムは、不要になったメモリを解放して別の処理で使えるようにします。しかし、解放した場所の情報が内部に残っていると、後から誤って参照してしまうことがあります。

今回の欠陥では、処理が異常終了したときに古いメモリへの参照が残り、後続の処理でその場所を使う場合がありました。これは「Use After Free」と呼ばれる問題で、条件が重なれば深刻な攻撃にも利用され得ます。

細かな名称を覚える必要はありません。PHPがデータを準備したり片づけたりする際の不具合が、外部からサーバーの動作を不正に変える手掛かりになった、と理解すれば十分です。

WordPress本体に欠陥がなくても影響する理由

WordPressの管理画面を厳重に守っていれば、今回の攻撃も防げるのでしょうか。残念ながら、それだけでは防げない構成があります。

WordPressのログイン確認やアクセス制御は、WordPress側のプログラムが動いて初めて行われます。ところがApacheのmod_phpでは、WordPressなどのアプリケーションが動くより前の段階で、認証不要の攻撃が成立する経路が実証されました。

一方、PHP-FPMなど別の実行方式でもリモートコード実行が確認されていますが、攻撃にアプリケーション側の処理が関係するなど条件が異なります。すべてのPHPサイトへ同じ通信を送れば同じように成功するわけではありません。

それでもPHP公式はmod_phpだけでなく、Webリクエストを扱うPHP環境全般へ更新を呼びかけています。WordPress本体の更新状況とは別に、サーバー側のPHPに修正が適用されているか確認する必要があるのです。

脆弱性の深刻さだけでなく、修正版を公表する過程で起きた混乱も、今回の緊急対応を難しくしました。

PHPの脆弱性に関するよくある質問（FAQ）

今回のPHPの脆弱性については、専門的な説明を読んでも「自分が利用しているサービスは大丈夫なのか」「何か対策をする必要があるのか」といった疑問が残るかもしれません。

特に、Webサイトを利用するだけの人と、WordPressなどを自分で運営している人では、確認すべき内容が異なります。ここでは、今回の騒動で気になりやすい疑問をまとめました。

PHPの脆弱性が見つかったサイトでは、個人情報が漏洩しているのですか？

いいえ。PHPに脆弱性が存在することと、実際に個人情報が漏洩したことは別です。

今回の問題では、セキュリティ企業によって実際の環境での悪用が報告されています。しかし、それだけでPHPを利用しているすべてのサイトに侵入が成功し、個人情報が盗まれたとは判断できません。

サービスが一時停止した場合も、被害を防ぐための予防的な対応である可能性があります。自分が利用しているサービスから情報漏洩に関する公式発表が出ているか、確認することが大切です。

ネットショップや会員サイトを利用するだけでも対策が必要ですか？

基本的に、一般の利用者がPHPを更新する必要はありません。今回の脆弱性への直接的な対応は、Webサービスを提供する会社やサーバー管理者が行います。

利用者が確認したいのは、サービスの公式サイトやメールなどで、メンテナンス、情報漏洩、パスワード変更について案内が出ていないかという点です。

運営会社から特別な対応を求められていなければ、今回のニュースだけを理由に、すべてのサービスのパスワードを変更する必要があるとは限りません。

WordPressを最新版に更新すれば、今回の問題は解決しますか？

WordPress本体を最新版にするだけでは、今回のPHPの脆弱性は修正できません。

問題が見つかったのはWordPress本体ではなく、WordPressを動かす基盤であるPHPです。そのため、サーバー側のPHPに必要なセキュリティ修正が適用されているかを確認する必要があります。

WordPressでは、管理画面の「ツール → サイトヘルス → 情報 → サーバー」からPHPのバージョンを確認できます。ただし、サーバー会社が独自の修正を適用している場合もあるため、対応状況は提供元の公式案内と併せて判断してください。

PHPの脆弱性を修正するには、どのバージョンに更新すればいいですか？

今回の2件の重大な脆弱性に対応するため、PHP開発チームは2026年10月21日に次の修正版を公開しました。

• PHP 8.5系：8.5.12
• PHP 8.4系：8.4.27
• PHP 8.3系：8.3.36
• PHP 8.2系：8.2.35

利用している系列に対応した修正版、または今回の修正を含む後続のバージョンを使用することが基本です。

ただし、レンタルサーバー会社などが独自にセキュリティ修正を適用する場合もあります。表示されているバージョン番号だけで未対応と決めつけず、提供元の案内を確認しましょう。

PHPの問題は2024年からわかっていたのに、なぜ2026年まで修正されなかったのですか？

2024年には、今回の脆弱性の一つにつながる問題の兆候が認識されていました。しかし、その段階では重大な攻撃を成立させる具体的な経路が確認されていませんでした。

また、修正方法によっては、これまで正常に動いていたプログラムとの互換性を失ったり、新たな障害を引き起こしたりする恐れがありました。

その後、2026年夏の研究で深刻な攻撃につながることが具体的に示され、修正の優先順位が高まりました。PHP Foundationは、対応が長期化した背景には技術的な難しさだけでなく、開発体制や意思決定上の問題もあったと認めています。

今後もPHPの脆弱性によって、同じようなサービス停止が起きる可能性はありますか？

可能性はあります。PHPに限らず、長年使われているソフトウェアでも、新しい研究によって重大な欠陥が発見されることがあります。

ただし、脆弱性が見つかるたびに必ず大規模なサービス停止が発生するわけではありません。欠陥の深刻さ、攻撃の成立条件、修正版の準備状況、サービスの運用方法などによって対応は異なります。

今回の騒動をきっかけに、PHP開発体制の強化も進められています。重要なのは、欠陥が一切見つからないことを期待するよりも、問題が発見されたときに速やかに修正し、安全に更新できる体制を整えておくことです。

参考リンク・一次資料

この記事は、PHP開発チームやPHP Foundationの公式発表を中心に、WordPress、セキュリティ企業、公的機関などが公開した情報を参考にしています。

脆弱性に関する情報は、研究の進展や攻撃の観測状況によって更新される場合があります。発表当時の経緯を詳しく確認したい人や、自分が管理するサイトの対応状況を調べたい人は、以下の一次資料も参考にしてください。

PHPの脆弱性と修正内容に関する公式情報

• PHP公式サイト｜2026年のセキュリティリリース

  今回の重大な脆弱性に対応するPHPの修正版や、公式のセキュリティ関連情報を確認するための資料です。

• PHP Foundation｜修正までの経緯とセキュリティ体制の課題

  2024年の問題把握、2026年夏の研究報告、修正が難航した理由、公開直前の混乱、PHPの開発体制の課題などについて詳しく説明されています。この記事の経緯を理解するうえで中心となる資料です。

• PHP公式サイト｜サポートされているバージョン

  PHPの各系列について、公式サポート期間やセキュリティサポートの終了予定を確認できます。古いPHPを利用している場合に役立ちます。

WordPressやWebサービスの利用者向け情報

• WordPress.org 日本語｜PHPの重大なセキュリティ更新について

  WordPressサイトへの影響やPHPバージョンの確認方法、ホスティング会社への確認事項などを案内しています。WordPressを運営している人にとって重要な資料です。

• IPA｜PHPの脆弱性に関する注意喚起

  情報処理推進機構（IPA）が公開した国内向けの注意喚起です。影響を受ける可能性のある製品や、利用者が確認すべき事項を調べる際に参考になります。

攻撃の観測状況や技術的な分析

• Palo Alto Networks Unit 42｜PHPの重大な脆弱性に関する分析

  今回の脆弱性に関する脅威分析や、外部公開されたインスタンスの影響可能性、実際の環境における悪用の観測について確認するための資料です。

• Cloudflare｜PHPの脆弱性に対するWAF防御

  正式公開前から実施された防御策や、攻撃通信の観測に関する説明が掲載されています。PHP本体の更新とWAFによる防御の違いを理解するうえでも参考になります。

• Cisco Talos｜PHP本体の2件の重大な脆弱性

  2件の脆弱性の技術的な特徴や、同社が発表時点で確認していた攻撃状況などを解説した資料です。

PHPの普及率に関する統計資料

• W3Techs｜PHPの利用統計

  Webサイトで利用されているサーバー側プログラミング言語としてのPHPの普及率や、利用されているバージョンなどを確認できる統計資料です。数値は更新されるため、記事中の2026年10月21日時点の数値と、現在の表示が異なる場合があります。

なお、参考資料の内容には、それぞれの発表・観測時点による違いがあります。特に攻撃の観測状況については、特定の時点で悪用を確認していなかったという報告と、その後に悪用を観測したという報告が、必ずしも矛盾するわけではありません。

情報の確認時には、発表日や更新日、調査対象、実際に確認された事実の範囲にも注意することが大切です。