［ニュース解説］AIが見つけたPHPの重大脆弱性、OpenAIが示す協調対応の枠組み

2026-10-222026-10-23

はじめに

　OpenAIが2026年10月21日、AIを用いて発見されたPHPの重大な脆弱性への国際的な協調対応について公開しました。本稿では、同社が提案するAI時代の脆弱性対応の枠組みと、メンテナー支援や安全なソフトウェア基盤づくりの取り組みを解説します。

参考記事

タイトル: Patch the Planet: global response coordination as agents uncover critical vulnerabilities
著者: 個人名の記載なし
発行元: OpenAI
発行日: 2026年10月21日
URL: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities

要点

OpenAIは過去2か月にわたり、メンテナーや研究者、セキュリティ企業の連合を主導し、PHPの重大な脆弱性に対応した。Califが「GPT-5.6 Sol」で欠陥を特定し、Wizも独自に発見・報告している。
PHPを利用する組織の最優先事項は修正の適用であり、OpenAIは脆弱な可能性のあるPHPバージョンの特定を助けるチェッカーをCodexのスキルとして公開している。
OpenAIは、上流の修正、影響組織への事前共有、政府との連携、製品横断の更新準備、公開後の展開支援という5段階の対応枠組みを提案している。
メンテナー支援としてCodex for OSSやRust Foundationへの支援を挙げ、防御者向けに10億ドル分の補助付きDaybreakアクセスを拠出するとしている。
安全なソフトウェア基盤づくりの4分野を示し、開示期間や緊急パッチなど4つの論点についてセキュリティコミュニティに意見を求めている。

詳細解説

PHPの重大な脆弱性と対応の概要

　OpenAIによれば、同社は過去2か月にわたり、メンテナー、研究者、セキュリティ企業からなる連合を主導し、PHPの重大な脆弱性への対応を進めてきました。PHPは、Webサイトやウェブアプリケーションの実行に使われるオープンソースのプログラミング言語です。同社の取り組み「Patch the Planet」の一環として、Califが「GPT-5.6 Sol」を用いて重大な欠陥を特定し、Wizも両方の脆弱性を独自に発見・報告しています。修正とリリースを主導したのはPHPのメンテナーで、OpenAIのチームやWiz、Cloudflareなどのパートナーは、開示前に防御策を準備するための調査、技術支援、調整を担いました。

　PHPを利用する組織にとって、現時点の最優先事項は修正の適用です。OpenAIは、運用担当者が脆弱な可能性のあるPHPバージョンを特定し、PHPや各プロバイダーのガイダンスとあわせてどの更新が該当するかを判断できるよう、PHPバージョンチェッカーをCodexのスキルとしてGitHubで公開しています。参考記事にはチェッカーの使い方や出力の詳細は記載されておらず、本稿でも実際には動かしていないため、利用時はリポジトリの説明を確認してください。

　OpenAIは、欠陥の深刻さとPHPの普及度を踏まえ、今回の件を近年でも特に影響の大きいセキュリティ問題の一つと位置づけています。AIはインターネット規模の影響を持つ欠陥を見つけられる一方で、同じ能力が攻撃者による攻撃ツールやエクスプロイト（脆弱性を悪用するプログラム）の迅速な開発にも役立ちうると同社は指摘しています。同社の知る限り、今回はフロンティアAI（最先端のAIモデル）が攻撃者より先に脆弱性を見つけたことで、メンテナーやセキュリティ企業が開示前に修正と防御策を準備できる「Defender’s Window（防御者の猶予期間）」が生まれたとしています。

　なお、参考記事では脆弱性の識別番号（CVE）や影響を受ける具体的なバージョン、技術的な詳細には触れていません。対象範囲は、チェッカーに加えてPHP公式の告知やホスティング事業者の案内で確認するのが確実だと考えられます。また、PHPはWordPressをはじめとする多くのCMS（コンテンツ管理システム）の基盤にもなっているため、自社でPHPのコードを書いていない組織でも、利用中のサーバーやサービスが影響を受ける可能性があります。

防御者への支援とAI時代の対応枠組みの提案

　OpenAIは、防御者がこうしたAIの能力を活用できるよう、「Daybreak for Frontline Defenders」を通じて、補助付きのDaybreakアクセスに10億ドルを拠出するとしています。対象は、セキュリティのリソースが限られる中で重要なサービスを守っている組織です。

　また同社は、今回の脆弱性は、すでに発見して修正を進めている複数の重大な脆弱性の一部であり、今後数か月で同様の発見が急増すると見込んでいます。こうした経験をもとに、広く使われているソフトウェアの重大な脆弱性に対応するための、AI時代に適したアプローチを提案し、セキュリティコミュニティに改善への協力を呼びかけています。この枠組みは、同社のモデル、セキュリティの専門知識、メンテナーを結びつけて発見を防御につなげ、AIの能力向上に合わせて拡張できる対応体制を目指しています。

　脆弱性の発見者が開発元と調整し、修正の準備が整ってから公表する慣行は、一般に「協調された脆弱性開示（CVD: Coordinated Vulnerability Disclosure）」と呼ばれます。本稿としては、今回の提案はその考え方を土台にしつつ、AIによって発見のペースが上がることを前提に、関与する組織の範囲や情報共有の段取りを体系化しようとするものと読んでいます。発見が増えるほど修正を受け止めるメンテナー側の負荷が課題になると考えられ、後述のメンテナー支援もその文脈に位置づけられていると思います。

協調対応が必要になる理由

　OpenAIによれば、修正を実際に使われる状態にするには、古いリリース向けへの修正の適用、プロバイダー側の緩和策の準備、多数の組織にまたがるシステム更新が必要になることがあります。発見される脆弱性が増えるなかで関係チームが素早く動けるよう、繰り返し使えるプロセスが役立つとしています。

　Patch the Planetを通じて、同社はPHPの対応にセキュリティの専門知識とモデルへのアクセスを提供し、メンテナーや研究パートナーと協力して修正のテストやガイダンスの準備を行いました。影響を受けるシステムの保護についてインフラ事業者と調整し、政府のサイバー機関とも連携して、重要な組織にガイダンスが届くよう支援しています。同社は、これらがメンテナー主導の対応を支え、他の防御者の準備を助けたと説明しています。

　研究者がメンテナーと直接協力して調査と修正を進められる発見もあります。一方で、多くの製品に影響する場合や、ディストリビューター（ソフトウェアを再配布する事業者）やサービス事業者が更新と防御策を準備する時間を必要とする場合には、より広い対応が必要になります。OpenAIは、フロンティアAIの能力が広く利用可能なAIの能力からそれほど先行していない場合、この準備時間は不足しうると指摘しています。こうしたケースで、提案された枠組みは、誰を関与させるかをメンテナーが見極め、作業を調整する助けになるとされています。

　本稿としては、この「準備時間の不足」という指摘が枠組み全体の重要な前提だと受け止めています。同等の能力を持つAIが広く普及すれば、攻撃側も同じ脆弱性を短期間で見つけられる可能性があり、防御者の猶予期間は長く続かないという見方もできると思います。

対応の5段階

　OpenAIは、対応が次の5つの段階で構成されうると整理しています。

上流の脆弱性を検証し、修正する: メンテナー、研究者、不可欠な技術パートナーが発見内容を確認し、影響を評価したうえで、修正を開発・テストします。この過程には、フロンティアモデルを使った敵対的テスト（パッチを回避する方法や、関連する脆弱性の変種を探す試験）も含まれます。
影響を受ける組織に対応の時間を与える: 防御策の準備のためにどの組織が事前情報を必要とするかを検討する枠組みをOpenAIが提案し、誰を関与させるかはメンテナーが決めます。OpenAIは連絡、情報共有の合意、チーム間の調整を支援します。たとえば、ディストリビューターは古いリリース向けに修正を適用し、ホスティング事業者は緩和策をテストし、セキュリティ企業はWAF（Webアプリケーションファイアウォール）のルールを含む検知・防止策を準備するといった動きが想定されています。
政府パートナーと連携して重要システムを守る: 政府機関は、より広い対応の調整や、重要インフラなど不可欠なサービスを担う組織にセキュリティガイダンスを届けるうえで欠かせない役割を果たします。PHPの件では、OpenAIはパートナーと協力し、ホワイトハウスのSuper Intelligence Force、国家サイバー長官室（ONCD）、サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）を含む米国政府の複数の部門や、国際的なパートナーと連携しました。
影響を受ける製品全体で更新を準備する: 修正、ガイダンス、開示計画が固まってきた段階で、メンテナーはディストリビューター、ホスティング・サービス事業者、対応チーム、運用者を追加で巻き込み、更新の準備やカバーできていない範囲への対処を進められます。
パッチ公開後にガイダンスを公表し、展開を支援する: 公開ガイダンスは、自組織の影響範囲の評価、正式な更新や暫定的な緩和策の入手、修正が実際に稼働しているかの確認に役立ちます。運用者が更新を展開し、支援が必要な箇所を報告する間も対応は続きます。

　段階2の例に挙がっているWAFは、Webアプリケーションへの通信を検査し、攻撃パターンに一致するものを遮断する仕組みです。アプリケーション本体を更新できるまでの間をつなぐ手段として使われることが多く、パッチ適用までの現実的な選択肢の一つと考えられます。ただし、WAFのルールは想定した攻撃パターンを前提にしているため、根本的な修正の代わりにはならない点に注意が必要だと思います。

情報共有の基準と開示タイミングの見直し

　提案された枠組みでは、組織の防御上の役割（自社システムや顧客の保護を含む）、対応に必要な時間、機密情報を扱う能力を考慮します。同等の組織には同じ基準を適用し、開示前に誰を関与させるかはメンテナーが決めるとされています。

　各参加者には、防御作業に必要な情報が渡されます。その内容は、侵害の痕跡（IoC: Indicators of Compromise）を含むネットワークログから、より機密性の高い、実際に動作する概念実証（PoC: Proof of Concept）エクスプロイトまで幅があります。限られた詳細からでも脆弱性が推測されうるため、OpenAIは共有に伴うリスクと、それによって可能になる防御の効果を比較衡量するとしています。

　枠組みに沿って動くチームは、メンテナーと協力して防御者に準備時間を与えつつ、次のような状況ではタイムラインを見直すとしています。

実環境で脆弱性が実際に悪用されている場合
情報が漏えいした場合
公開されたパッチから脆弱性の内容が読み取れてしまう場合
修正の停滞によってユーザーへのリスクが高まっている場合

　公開パッチの差分を解析して脆弱性の箇所を割り出す手法は、一般に「パッチ解析（パッチディフィング）」として知られています。本稿としては、AIによってこうした解析も速くなる可能性があり、パッチ公開から攻撃までの時間が短くなることを見越して、事前準備の段取りを重視していると読んでいます。

運用者向けのガイダンスと優先順位付け

　Patch the Planetのウェブサイトには、公開された開示情報とガイダンスが集約されており、運用者が影響を受けるシステムを特定し、適切な更新を見つけ、更新後のソフトウェアが正しく動作しているかを確認できるようになっています。PHPについては、メンテナーによる公式のパッチとアップグレード手順、パートナーの技術調査へ案内しています。ガイダンスは、暫定的な緩和策、プロバイダーや専門家に相談するタイミング、バックアップと復旧も扱っています。OpenAIは、暫定的な防御策はリスクを下げられるものの、その限界や運用上のトレードオフを明確に示すとしています。

　運用者は、CISAの優先順位付けと修正に関するガイダンスを使い、露出状況、悪用状況、想定される影響に基づいて、どれだけ迅速に対応するかを評価できます。対応の選択肢として、参考記事は次の3つを挙げています。

緊急のパッチ適用
即時の緩和策
計画的な更新

　これらとあわせて、必要に応じてフォレンジックトリアージ（システムがすでに侵害されていないかを見極める初期調査）を行います。状況の変化に応じて優先順位を見直し、恒久的な修正への明確な道筋を持つことが求められるとしています。

　社内でPHPが動いているシステムを把握できていない場合は、まず資産の棚卸しから始める必要があると考えられます。外部に公開しているWebサーバーだけでなく、委託先が管理しているサイトや、ホスティングサービス上のサイトも確認対象に含めるのが現実的だと思います。

メンテナーへの支援と投資

　OpenAIは、国際的な協調はソフトウェアを保守する人々にかかっていると述べています。多くのプロジェクトは、日常的な開発と並行してセキュリティ報告を確認する少人数のチームで運営されています。こうしたチームには、次の作業への支援が必要だとしています。

新しい問題と重複報告の切り分け
影響の評価
サポート対象の各リリースにまたがる修正のテスト

　同社はこれらの作業を、資金、高性能なモデルへのアクセス、実地のエンジニアリング支援で後押しするとしています。また、強力なAIの能力が業界全体で進歩しており、脆弱性の発見、システムの監視、脅威への対応でAIが果たす役割は今後大きくなると見込んでいます。そのうえで、防御者がその能力を活用できるよう、モデル、ツール、パートナーシップへの投資を進めているとしています。

　具体的な投資として、Codex for OSSを通じたすべてのメンテナー向けのサブスクリプションや、メンテナーと技術的作業のためのRust Foundationなどへの直接支援が挙げられています。各プロジェクトは自ら優先順位を決め、再利用可能なテストやセキュリティワークフローによって、今後の発見に対応する負担を減らせるとしています。オープンソースプロジェクトは、Patch the Planetへの応募ページから申し込み、実地の支援を受けることもできます。

　オープンソースの保守が少人数に依存しているという課題は、以前からたびたび指摘されてきました。AIによる発見が増えれば報告の件数も増えると考えられ、報告を受ける側の処理能力を高める支援は、発見の加速とセットで必要になるという見方もできると思います。

悪用防止とのバランス

　OpenAIは、悪用の可能性を減らすため、Daybreak向けに追加のブロック用分類器（有害な利用を判定して遮断する仕組み）を調整しているとしています。悪用を防ぐための安全策が正当なセキュリティ作業まで妨げることもあり、難しいトレードオフを伴うと同社は認めています。高性能なモデルへの幅広いアクセスと、悪用への効果的な防御はどちらも重要であり、防御者が脆弱性を発見・修正するために必要な能力を保ちつつ、有害な利用を抑えることを目指すとしています。能力の進歩や、ツールの使われ方から得られる学びをもとに、このバランスを今後も調整していく方針です。

　脆弱性の発見とエクスプロイトの作成は技術的に近い作業であり、同じ技術が防御にも攻撃にも使える「デュアルユース」の典型と言えます。本稿としては、分類器による制限が実際の防御業務にどの程度影響するかは、今後の運用状況や追加情報を見て判断する必要があると考えています。

より安全なソフトウェア基盤づくり

　OpenAIは、モデルの能力が高まるにつれ、個々の脆弱性の発見と修正を超えた機会が広がるとしています。エンジニアが最初からより安全なソフトウェアを構築できるよう支援したいとし、広く使われるコンポーネントを改善すれば、多くの製品やサービスでバグを防いだり、その影響を抑えたりできると述べています。AIが既存コードの理解、変更の準備、テストの作成を助け、メンテナーやセキュリティ専門家が、その変更によってユーザーが依存している挙動が保たれているかを確認するという役割分担です。同社が機会として挙げる分野は次の4つです。

最初から安全なコード: コーディングモデルは、開発者がより安全なデフォルト設定を選び、セキュリティライブラリを正しく使い、危険なパターンを書いている最中に検出するのを助けられます。開発段階で脆弱性を防げれば、メンテナーやユーザーにとって緊急修正が減ります。
メモリ安全なソフトウェア: 重要なコンポーネントをメモリ安全な言語に移行すれば、よくあるメモリエラーの類型を排除できます。AIは、挙動と互換性を確かめるテストや専門家のレビューと組み合わせて、移行作業を支援できます。
形式検証: 数学的な証明によって、重要なコンポーネントが、明示された前提のもとで指定されたセキュリティ特性を満たすことを示せます。広く使われるコンポーネントに適用すれば、それに依存するサービスや重要インフラ全体で、特定の類型の脆弱性を排除できる可能性があります。
より強力な隔離: システムには、まだ見つかっていない、あるいは修正されていない脆弱性への備えも必要です。信頼できないファイル、画像、メディアを処理するソフトウェアを厳しく制限されたサンドボックス（隔離された実行環境）で動かせば、侵害された場合の被害を抑えられます。AIは、広く使われるサンドボックス技術のテストと強化を助け、多くのアプリケーションの防御向上につなげられます。

　メモリ安全な言語とは、Rustのように、バッファオーバーフローなどメモリ管理に起因する誤りを言語の仕組みで防ぎやすくした言語を指します。前述のRust Foundationへの支援も、この方向性と関係していると読めます。一方で、大規模なコードベースの言語移行や形式検証には相応の工数と専門知識が必要であり、AIの支援があっても段階的な取り組みになると考えられます。

枠組みの改善に向けた意見募集

　OpenAIは、メンテナー、研究者、対応チーム、プロバイダー、運用者がこのアプローチを実用的なものにできるよう、内容を公開したと説明しています。どこで役立つか、どこで遅延や負担を生みうるか、何を見落としているかを知りたいとし、過去の開示事例が特に有用だとしています。同社が特に関心を寄せている論点は次の4つです。

開示期間: メンテナー、運用者、防御者が信頼できる修正を準備し、展開するにはどれだけの時間が必要か。一部のユーザーを他より早く守れる場合も含め、どのような根拠があれば開示を前倒しするのが妥当か。
緊急パッチ: 政府やその他の運用者が、管理権限を失った後に、自ら所有する、または管理を認められているシステムへパッチを当てるために脆弱性を利用してよい場面はあるのか。あるとすれば、どのような安全策が必要か。OpenAIは、既知の脆弱性をインターネット全体で常時スキャンし、検出時にサイト所有者へ通知するか、システムにパッチを当てるという最終形も想定しうるとしています。
早期通知: 有効な防御行動をとるために事前の警告を必要とするのは誰か（見落とされがちな防御者を含む）。段階的な通知が、より広いグループへの一斉通知より有効なのはどのような場合か。通知範囲の広さと漏えいリスクをどう比較衡量するか。
デフォルトで安全なソフトウェアパッケージ: 上流の修正を待つ間に下流のパッケージの脆弱性を特定・修正したり、セキュリティ更新が終了した古いバージョンへ修正をバックポート（新しい版の修正を古い版に移植すること）したりするには、どう支援できるか。適時のアップグレードが難しい場合に、こうしたパッケージを信頼できる選択肢にするには、どのようなテストと保守が必要か。

　また、アプローチをレビューし、前提を問い直し、抜けを指摘できる独立したセキュリティ専門家の推薦も歓迎するとしています。寄せられた意見は対応の改善と支援の優先順位付けに活用されるとされ、OpenAIのフィードバックフォームから送ることができます。

　本稿としては、4つの論点のうち「緊急パッチ」は特に判断が分かれるテーマだと考えています。管理権限を失ったシステムに対して脆弱性を利用してパッチを当てる行為は、目的が防御であっても法的・倫理的な課題を伴いうるため、OpenAIも安全策のあり方を含めて問いかけているものと読めます。