いつも使っているWebサービスに、突然「緊急メンテナンス」のお知らせが出る。その理由が「PHPの脆弱性」だと言われても、PHPを知らなければ、何が起きたのか分かりにくいですよね。
2026年10月21日、PHPの重大な脆弱性2件を修正する更新が公開されました。どうして、一つのソフトウェアの問題が、別々のサービスの停止につながるのでしょうか。
この記事では、Webの裏側の仕組みから、「止めることで守る」という運営判断までを整理します。
情報確認:2026年10月23日(日本時間)。時点によって修正版・攻撃観測・勧告は変わります。個別システムの判断には、PHP公式と利用中の製品・サーバー提供元の最新情報を確認してください。
PHPの脆弱性をめぐって何が起きたのか
PHP公式は10月21日、認証なしで遠隔コード実行につながり得る2件の問題と、修正版を公表しました。利用者のログイン処理に到達する前でも問題になり得るため、Web向けにPHPを動かす環境には迅速な更新が求められています。PHP公式のセキュリティ告知
国内でも、京急プレミアポイントはセキュリティ更新に伴うメンテナンスを告知し、IRISはTOKYO PRIMEのフォームを予防的措置として一時停止すると発表しました。いずれも10月21日の告知の例です。現在の提供状況は各社のお知らせをご確認ください。
ここで大切なのは、サービスが止まったことだけでは、攻撃や情報漏えいが起きたとは言えないことです。悪用される前に危険を減らすため、先に止める場合もあります。
そもそもPHPとは? Webの裏側で働くもの
PHPは、Webサービスのサーバー側の処理などを書くためのプログラミング言語です。そのプログラムを実行するソフトウェアも、一般にPHPと呼びます。
例えば会員ページでは、ブラウザから届いた要求を受け、ログイン情報を確認し、必要ならデータベースから情報を取り出して、表示用のHTMLなどを返します。こうした裏側の仕事をPHPのプログラムが担当できます。

ざっくり分けると、HTMLは画面の構造、CSSは見た目、ブラウザのJavaScriptは操作に応じた動きなどを担当します。PHPはサーバー側で処理します。JavaScriptがサーバー側で使われる場合もありますが、ここでは画面側との役割の違いを押さえれば十分です。
PHP本体と、PHPで作られたアプリは別
WordPressはPHPを使うアプリケーションの一例です。しかし「WordPressのプラグインに弱点がある」という話と、「PHPの実行環境そのものに弱点がある」という話は、問題のある場所が違います。
今回は後者です。アプリの仕事が違っていても、その下で同じ種類の実行環境を使っていれば、複数の運営者が対応を迫られます。

逆に、PHPやWordPressを使っているという情報だけで、すでに侵害されているとは判断できません。修正の適用状況、構成、外部からの到達性などを確認する必要があります。
「脆弱性」は、攻撃に利用され得る弱点
ソフトウェアの不具合のうち、情報を盗む、不正な処理を動かすといった行為につながり得る弱点を「脆弱性」と呼びます。
普段は正しく動いていても、特殊な入力やエラーが重なったときだけ、想定していない動作をすることがあります。今回の問題も、メモリという作業用の領域をどう管理し、エラー後にどう片づけるかに関係しています。
遠隔コード実行(RCE)が重大な理由
RCEはRemote Code Execution、遠隔コード実行の略です。離れた場所からの入力によって、本来意図しないコードを対象側で動かせてしまうことを指します。
成功すれば、その処理が持つ権限の範囲で、情報へのアクセスや改ざん、サービス妨害などにつながり得ます。ただし「サーバー上で何でも無制限にできる」という意味ではありません。成立条件、プロセスの権限、サーバー構成、他の防御策によって影響は変わります。
それでも、外部から届く要求を処理する部分で起きるRCEは重大です。PHP公式は今回、特定の構成だけを安全と決めつけず、Web要求を処理するPHP環境を広くリスクの対象としています。PHP公式
今回の2件は、どこに問題があったのか
CVE番号は、脆弱性を取り違えずに追跡するための識別番号です。今回は次の2件です。
CVE-2026-109618:メモリ不足で、準備途中の状態が残る
内部データを準備している途中でメモリ不足が起きると、処理が中断され、完成していない状態が残る場合があります。それを後片づけの処理が正しいデータだと扱ってしまうことが、メモリの破損や遠隔コード実行につながります。PHPの技術勧告:OOM corruption
CVE-2026-109619:片づけた領域への参照が残る
ある要求の処理が終わり、メモリを解放した後も、その場所を指す内部状態が残る場合があります。同じ処理担当が次の要求を受けた際、古い状態を使うことで問題が起きます。使い終わって解放したメモリを再び扱ってしまう、use-after-free型の問題です。具体的な成立条件は内部状態や構成によって異なります。PHPの技術勧告:stale global state
似た話に見えますが、前者は「準備途中の状態」、後者は「寿命を過ぎた状態」が残る問題、と分けると理解しやすくなります。
修正版はどれ?
| PHPの系列 | 修正前の対象範囲※ | 10月21日の修正版 |
|---|---|---|
| 8.2 | 8.2.35未満 | 8.2.35 |
| 8.3 | 8.3.36未満 | 8.3.36 |
| 8.4 | 8.4.27未満 | 8.4.27 |
| 8.5 | 8.5.12未満 | 8.5.12 |
※各系列内の上流PHPのバージョン範囲。2件の技術勧告に基づきます。8.1以前も対象外という意味ではありません。本家のサポートは終了しており、提供元の修正や対応版への移行を確認する必要があります。配布元が古い番号のパッケージへ修正を取り込む「バックポート」もあるため、番号だけで適用済みか判断せず、提供元の告知を確認してください。
なぜ、サービスを止めることがあるのか
修正が反映されるまでサービスを外部に公開し続ければ、その間も弱点に触れられる可能性があります。そこで、影響範囲を調べ、必要なら受付を止めたり、外部から接続できないようにしたりしてから作業します。

ENISAなどの共同声明も、外部公開システムを優先した更新と、すぐに修正できない場合の隔離の検討を促しています。
もちろん、停止にも利用者への影響があります。無停止で更新できる構成もあり、止める範囲や時間は環境ごとの判断です。「停止したから被害があった」「停止しないから安全を軽視した」と、告知だけで決めつけることはできません。
パッチが公開されても、対応はそこで終わらない
パッチは、不具合や弱点を直すための修正です。提供された修正版が、すべてのサービスへ自動的に届いて適用されるわけではありません。
運営者は、使っている環境と提供元の修正版を確認し、必要な互換性確認やテストを行い、更新を反映します。必要なプロセスの再起動などを経て、修正が有効になったことと、サービスが正常に動くことを確認します。
PHPはアプリ、Webサーバー、OS、ライブラリなどと組み合わさって動くためです。確認は重要ですが、長く放置してよい理由にはなりません。今回の公式推奨は、速やかに修正版を適用することです。自分でサーバーを管理していない場合も、契約している提供元の案内が手がかりになります。PHP公式/IPAの対策情報
AIは発見や修正にどう関わったのか
OpenAIの発表によると、セキュリティ企業CalifはGPT-5.6 Solを使って重大な問題を特定し、Wizも独立して2件を発見・報告しました。修正とリリースを主導したのはPHPのメンテナで、複数の組織が研究、検証、調整を支えています。OpenAIの発表
PHP Foundationによれば、メモリ不足の問題の兆候は、2024年の外部監査への対応中にすでに見つかっていました。2026年8月のCalifの研究者Ryan Aからの報告や、OpenAIの独立した報告、Wizなどからの報告によって、遠隔コード実行につながる影響が明確になったという経緯があります。PHP Foundationの説明
つまり、AIがゼロから全部を自律的に見つけ、直し、公開したという話ではありません。同財団は、報告の検証などにAIを使う一方、判断とパッチ作業には人が関わっていると説明しています。
攻撃は確認された? 事実と考察を分ける
確認できる事実
IPAの10月21日の事前注意喚起は、発信時点でIPAが今回の2件を悪用した攻撃を確認したものではない、と明記しています。その後、10月22日に修正版と対策を案内する続報が公開されました。更新や移行を終えるまで脆弱な状態を放置せず、必要に応じてアクセス制限や一時停止を判断するよう求めています。
この記述を「現在も世界中で攻撃が一件もない」と読み替えることはできません。また、研究者が攻撃可能性を実証したことと、実サービスで攻撃被害が起きたことも別です。本稿で参照した発表だけから、大規模な攻撃被害が発生したとは判断していません。
ここからは考察:見つける速さと、直す力
AIは、大量のコードの確認、異常な入力を試すテスト(ファジング)の支援、問題が悪用につながるかの検証、修正案の確認を速める可能性があります。
一方、攻撃側にも利用され得ます。今回の話から考えられるのは「AIが弱点を増やした」というより、既存の弱点を見つける速さや規模が変わる可能性です。見つけた後の検証、修正、配布、利用側への適用まで進める体制も、ますます重要になりそうです。
普段は見えない、Webの共通基盤
ゲーム、買い物、ブログ、企業や行政のサイト。画面も目的も違うサービスが、裏側では同じソフトウェアを使っていることがあります。今回のPHPの問題は、その見えにくい土台が表に現れた例です。
共通の仕組みがあるから、サービスを一からすべて作らずに済みます。その一方で、土台に弱点が見つかれば、多くの場所で対応が必要になります。
まとめ
PHPはWebの裏側を支える実行環境の一つです。2026年10月21日には、遠隔コード実行につながり得る重大な脆弱性2件の修正版が公開されました。
複数のサービスが止まるのは、共通の土台に対応が必要になるためです。停止は攻撃被害とは限らず、悪用を防ぐための予防措置でもあります。修正版の公開後も、各運営者による適用と確認が欠かせません。
「PHPに問題があった」というニュースも、Webの裏側と更新の流れを知ると、なぜ緊急メンテナンスが必要になるのかが少し見えやすくなります。

コメント