PHP重大脆弱性「php2shell」をAIで発見、OpenAI・Wiz・Cloudflareが公開前の防御に協力 PHP Foundationは開示過程の混乱も説明

セキュリティニュース

投稿日時: 更新日時:

PHP重大脆弱性「php2shell」をAIで発見、OpenAI・Wiz・Cloudflareが公開前の防御に協力 PHP Foundationは開示過程の混乱も説明

OpenAIは2026年10月21日、PHPの重大な脆弱性2件への対応で、AIを活用した発見から修正、公開前の防御準備まで、複数のセキュリティ企業やPHP開発者と連携した経緯を公表しました。セキュリティ企業CalifがOpenAIの「GPT-5.6 Sol」を使って重大な問題を発見し、Wizも独立した調査で2件の脆弱性を特定。PHPのメンテナーが修正版を開発し、Cloudflareなどのインフラ事業者が事前に対策を準備していました。

対象は「php2shell」と呼ばれるCVE-2026-109618とCVE-2026-109619です。脆弱性の発見と対応をめぐっては、PHP Foundationが2024年に問題の兆候を把握していたことや、正式公開直前に一部の情報が流出したことも明らかになっています。今回の焦点は脆弱性そのものの技術的な説明ではなく、AIによる調査と事前防御がどのように機能したのかという点にあります。

AIによる発見と共同対処のサマリー

  • OpenAIは10月21日、オープンソースのセキュリティ支援構想「Patch the Planet」によるPHP対応の経緯を公表。
  • Califは「GPT-5.6 Sol」を使い、PHPの重大なリモートコード実行(RCE)につながる問題を報告。
  • Wizは独立して調査を進め、Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを使用したと説明。
  • PHP開発チームが修正とリリースを主導し、OpenAIや研究者が検証・調整を支援。
  • Cloudflareは脆弱性の正式公開前に、無料・有料プラン向けWAFの防御策を既定で展開。
  • 2026年10月21日、PHP 8.5.12、8.4.27、8.3.36、8.2.35が公開。
  • PHP Foundationは2024年の段階で問題の兆候を把握していた一方、修正方法の技術的な難しさと体制上の問題で対応が停滞していたと説明。
  • 公開直前には識別子の拡散、実証動画の誤公開、事前提供した修正済みイメージの早期配布が発生。
項目 内容
公表日 2026年10月21日
主な発表主体 OpenAI、PHP Foundation、Wiz、Cloudflare
対象 PHP本体の脆弱性「php2shell」
識別番号 CVE-2026-109618、CVE-2026-109619
深刻度 両方ともCVSS v4.0 9.2(Critical)
発見・調査に用いたAI GPT-5.6 Sol、Gemini 4 Argon、Wiz Atlasなど
修正を主導 PHP開発チーム、PHP Foundation
公開前防御 WAFルール、検知策、プロバイダー向けの対策準備
修正版 PHP 8.5.12、8.4.27、8.3.36、8.2.35

CalifとWizが別々に脆弱性を発見、PHP開発チームが修正

OpenAIの説明によると、Califは「Patch the Planet」の取り組みでGPT-5.6 Solを用いてPHPの重大な脆弱性を発見しました。PHP Foundationの報告では、CalifのPHP調査は7月30日に始まり、8月11日に研究者が認証不要のリモートコード実行につながる問題を報告しています。同日、OpenAIも同じ根本原因を独立して報告しました。

一方、Wizは8月19日に最初の脆弱性を発見し、8月24日にPHPセキュリティチームへ報告したとしています。Wizは調査・検証に自社のWiz Atlas、GoogleのGemini 4 Argon、OpenAIのGPT-5.6 Solを利用。とりわけGemini 4 Argonが脆弱性の特定や修正内容の検証に寄与したと説明しました。したがって、今回の研究成果を単一のAIモデルや一社だけに帰属させることはできません。

さらにPHP Foundationは、2024年の外部セキュリティ監査の後、PHP開発者がメモリ不足時の処理に関する問題の兆候をすでに見つけていたことを公表しています。当時は具体的な悪用経路が確認できず、修正に伴う互換性や性能への影響について判断が難航していました。2026年のAI支援調査で実際の攻撃につながる経路が示され、問題の深刻さが明確になったことが対応加速の契機となりました。

OpenAIの「Patch the Planet」、発見だけでなく公開前の防御準備を調整

OpenAIは、今回の対応で研究者・メンテナー・クラウド事業者・セキュリティ企業などが約2カ月間連携したと説明しています。発見した脆弱性を公開するだけではなく、PHP側が修正を検証する時間と、配布元やホスティング事業者が対策を準備する時間を確保することが目的でした。

同社が提示した対応の考え方は、①上流ソフトウェアの問題を検証・修正する、②影響を受ける関係者に必要な範囲で事前共有する、③政府機関とも協力して重要システムを保護する、④配布先製品の更新を準備する、⑤公開後の適用状況まで支援する、というものです。OpenAIは米国のCISAや国家サイバーディレクター室(ONCD)などにも連絡したとしています。

ただし、これはOpenAIが提案した協調開示の枠組みであり、すべての関係者や利用者に対して公開前の保護が保証されたという意味ではありません。実際の修正・公開の判断はPHPのメンテナーが担いました。

Cloudflareは公開前にWAF防御を展開、攻撃通信も観測

Cloudflareは10月21日、PHPの問題に対応するWAF保護をすべての対象プランで既定有効にしたと発表しました。展開時刻は同日3時2分(UTC)、日本時間では12時2分で、脆弱性の正式公開より約9時間早いタイミングでした。

今回の対策では、リクエスト内容だけで攻撃と通常通信を見分けることが難しいため、HTTPリクエストとオリジンサーバーのレスポンスの両方を使う「full transaction detection」を導入したと説明しています。Cloudflareは防御ルールを回避しようとする攻撃通信を観測したとも公表しました。

もっとも、WAFは悪用の一部を防ぐための追加防御であり、PHP本体の欠陥を取り除くものではありません。CloudflareとPHP開発チームは、修正版の適用が必要だと明示しています。

公開直前の情報流出で修正日を前倒し 協調開示には課題も

PHP Foundationの説明によると、10月20日15時ごろ(UTC、日本時間21日0時ごろ)、2件のCVE番号がオンライン上で拡散されました。その段階では技術的な詳細は流出していませんでしたが、PHP側は当初予定していた10月22日14時(UTC)から、10月21日14時(UTC、日本時間23時)へ修正版の公開を1日前倒ししました。

さらに、事前告知を受けてCalifが攻撃の実証動画を誤って公開し、削除後もコピーが広まりました。PHP Foundationは、これが実証コードの開発を加速させたと説明しています。また、事前に修正を受け取っていたChainguardが、取り決められた公開時刻より6時間以上早く修正済みコンテナイメージを公開したことも問題視しています。

この一連の出来事は、公開前に防御側へ情報を共有する利点と、共有先が増えることに伴う情報管理の難しさを示しています。なおPHP Foundationは、正式公開時点で機能する悪用コードを自らは確認していなかったと説明しています。一方でCloudflareは攻撃を試みる通信を観測しており、攻撃の試行と実際の侵害成立は分けて判断する必要があります。

AIが「攻撃者より先に発見」したとのOpenAIの見解

OpenAIは、自社が把握する範囲では先端AIが攻撃者に先んじて脆弱性を見つけたとし、修正や防御を準備する期間を「Defender’s Window(防御側の猶予期間)」と位置付けました。同時に、同じAIの能力が攻撃者による悪用コードの開発を容易にする可能性にも言及しています。

今回の事例では、長期間存在していた複雑な問題について、AIによる検証が現実的な攻撃経路の発見を助けました。しかし最終的な修正はPHPメンテナーによる判断・開発・テストに依存しており、脆弱性の発見能力だけでは利用者保護は完結しません。PHP Foundationは、AIによる報告件数の増加に伴い、重複や再現できない報告を選別する人手も必要になっているとしています。

PHP利用企業が確認したいこと

企業の情報システム部門は、AIによる発見経緯と実際の更新対応を分けて考える必要があります。まず管理対象のPHP実行環境を洗い出し、対応版の適用状況、ホスティング事業者の更新計画、アップデート後の稼働確認を記録します。WebアプリケーションやWordPress本体の更新だけではPHPランタイムの修正に代わりません。

PHP公式は完全な回避策はなく更新が唯一の安全な選択肢だと説明しています。対応すべきバージョン、影響条件、事業者側の保護措置は、PHP2Shellの脆弱性と修正版に関する既報で整理しています。

また、今後AIによる脆弱性報告が増えた場合に備え、CSIRTはベンダー告知と公開前情報の扱い、修正の優先順位、緊急変更時の承認経路を整理しておく必要があります。WAFによる緊急保護の有無も記録し、適用済みパッチの代替として扱わない運用が必要です。

出典