PHP脆弱性問題は“また起こる” 事件の裏にあったエンジニアの根深い課題：2024年に既に兆候があった

多くの日本企業を混乱の渦に巻き込んだPHP脆弱性問題。深夜のアップデート対応に追われた担当者もいることだろう。この問題はなぜ起きたのか。その背景には一朝一夕ではいかない開発者全体に関わる根深い課題があった。

[有限会社オングス,田渕聖人，＠IT]

　PHPの開発元であるThe PHP Groupは2026年10月21日（現地時間、以下同）、認証なしのリモートコード実行（RCE）につながる重大な脆弱（ぜいじゃく）性「CVE-2026-109618」と「CVE-2026-109619」の2件を修正したPHPのセキュリティアップデートを公開した。

　修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35。Web要求を処理するPHP環境全般に影響するため、利用者に速やかな更新を求めている。サポート終了（EOL）している8.1系以下にも最小限のソースコードバックポートが提供されている。

　同事案は高市早苗首相の公式「X」（旧Twitter）で注意喚起が発表されるなど災害やテロと同様の緊急性を持って呼び掛けられており、日本でも多くの企業が深夜帯でのアップデート対応に動いていた。

　今回の事案はなぜここまでの混乱に発展したのだろうか。The PHP Groupの発表から、脆弱性自体の危険性に加え、問題の兆候を2024年に把握していながら修正に時間を要した背景、公開直前に発生した情報流出なども明らかになった。

　1件目の「CVE-2026-109618」は、メモリ不足時の処理に起因する脆弱性だ。PHPのメモリ使用量が設定値「memory_limit」に達した際、初期化途中の内部データが残り、後続処理で誤って利用されることでメモリ破壊が発生する。

　Apacheの「mod_php」環境では、アプリケーションコードが実行される前に攻撃を誘発でき、標準設定で遠隔コード実行が実証された。PHP-FPMでも、アプリケーションの処理経路を通じた遠隔コード実行が確認されている。

　2件目の「CVE-2026-109619」は、致命的エラーが発生した後に古い内部状態が残る問題だ。後続のリクエストで、解放済みメモリを参照する可能性がある。メモリの誤使用やワーカーの異常終了が確認され、Apacheのmod_phpで動作する実アプリケーションを対象に、遠隔コード実行も実証された。

　いずれもメモリ管理やエラー処理といったPHPの基幹部分に関わる。修正には互換性の維持や性能への影響、外部拡張との整合性などの課題があり対応が難航した。

放置された脆弱性が生んだ未曾有の混乱　問題の兆候は2024年

　実はこの脆弱性は昨日今日に見つかった問題ではない。問題の発端は2024年にさかのぼる。その裏には開発者コミュニティーを巡る根深い問題と、もはや言うまでもないAIの発展が関係していた。

　The PHP Groupは2024年に外部セキュリティ監査を実施した。その指摘事項を修正する過程で、同組織が契約したPHPコア開発者が今回の「CVE-2026-109618」につながるメモリ不足時の問題の兆候を発見した。

　兆候が発見されたものの、当時は具体的な攻撃経路が確認されておらず、他の明確な問題への対応が優先されていた。修正案についても、後方互換性の喪失やサービス妨害のリスク、外部拡張への変更要求など、それぞれに課題があった。The PHP Groupによると、同団体は当初合意形成を重視していたが、複数の修正案から方針を決められず、対応が停滞したという。

　転機になったのは2026年7月30日に始まったセキュリティ企業Califによる監査だ。同年8月11日、同企業研究者の「Ryan A」が、2024年に兆候が見つかっていた問題と同じ根本原因によるリモートコード実行を報告した。同日にはOpenAIも独立して同じ原因を指摘。その後、Wizが同年8月24日に別の攻撃経路を報告し、OpenAIも同年9月18日に追加の経路を報告した。

　これらの調査によって問題の深刻さが明らかになり、The PHP Groupは2026年8月11日以降、修正を最優先事項として対応した。

　脆弱性調査には、Anthropicの「Claude Mythos」やOpenAIの「Daybreak Red」などのAIツールも活用された。AIによる報告の検証や攻撃コードの再現性確認などを通じて調査を支援する一方、報告の評価や修正の判断は人間が担う。

　The PHP Groupによると、2026年7月以降に公開したCVEは15件に上る。また、無効な報告や重複報告、再現できない報告も100件以上処理したという。

混乱は必然だった？　公開直前に発生した“大ポカ”

　こうして同脆弱性の報告に向けて動いていたThe PHP Groupだったが、公開を巡ってもトラブルに見舞われた。当初、2026年10月22日14時（UTC）に修正版を公開する予定だったが、前日の20日15時ごろ、CVE番号や誤った公開時刻、CVSSスコアを10.0とする情報がオンラインフォーラムやSNSで流通した。実際のCVSSスコアは9.2で、当初は技術的な詳細の流出は確認されていなかった。

　そのためThe PHP Groupは事前告知を前倒しし、正式公開も2026年10月21日14時（UTC）に変更した。脆弱性の情報が広がる中、利用者が修正版を入手できるよう準備時間を確保する必要があったためだ。

　ただここで問題が生じる。脆弱性を報告したCalifがエクスプロイトの実証動画を誤って公開したのだ。動画には複数の対象に対して攻撃の実証コードが動作する様子が含まれ、削除後もコピーがSNSなどで流通した。

　さらに2026年10月21日7時41分（UTC）には、セキュリティ企業Chainguardが正式公開前に修正済みイメージを公開した。The PHP Groupは、事前に修正を受け取った配布事業者が解禁前に公開したことで、他の利用者が更新できるようになる前に攻撃者が修正内容を分析できる状態になったと説明している。

　The PHP Groupはこのような背景から、緊急のアップデート対応に迫られることになった。当然、これを受けて日本のエンジニアも徹夜で対応することになったわけだ。

　ほとんど人災のように感じるこの事案だが、深掘りをすると根が深い。一つは脆弱性の増加に関する問題だ。高性能なAIによって次々と脆弱性が見つかる昨今、報告される脆弱性の数に対して、その対応に当たる人材の数は明らかに足りていない。OSSの開発者コミュニティーのメンテナーに対して適切な報酬が支払われていない問題も解決する兆しは見えない。

　実際、The PHP Groupも報告の増加に対応するために、継続的なリソースと資金の確保が課題となっていると説明している。この状態が続くとPHPのセキュリティ維持にも限界が生じるだろう。これまで善意のコミュニティーにフリーライドしてきた企業や公共機関の協力は必要不可欠だろう。

　もう一つは発見された脆弱性を巡る対応だ。今回の脆弱性は2024年段階で見つかっていたものの、悪用難易度の難しさという観点から放置されてきた。しかしAIの登場によって複数の脆弱性を緻密に組み合わせることが可能になり、悪用の難易度は低下している。もはや放置していい脆弱性など存在しないのかもしれない。

　なお、同グループは対応の停滞を組織上の失敗と認め、複雑な問題を早期に経営層に引き上げ、迅速に判断できるよう手続きの見直しを進めている。

PHP脆弱性問題は始まりに過ぎない？　根本治療しない限り事件は起こる

　記者は今回の一連の流れを見て、高市首相の「X」での注意喚起には意義があったと感じている。通常「PHP」という言葉を見たことも聞いたこともないであろう経営者に事態の深刻性を正確に伝えつつ、現場エンジニアのアップデート対応の説得材料にも使用できるからだ。ただでさえアップデートの影響によるサービス停止は許容されないケースが多い。こうした公の発信で「緊急性の高い対応である」という空気感を作れたのは大きいだろう。

　本稿執筆時点で実際にこの脆弱性を悪用した企業を狙った攻撃は確認されていない。ただし、情報公開後に攻撃コードが開発・流通する可能性を踏まえ、速やかな更新が求められる。また、問題の真因が解消しない限りは同じような問題はこの先何度でも発生するだろう。