クラウドフレアCEO、PHP2Shellに続く「複数の重大な脆弱性」を把握 AIによる発見加速、今後数カ月の対応増を警告

セキュリティニュース

投稿日時: 更新日時:

クラウドフレアCEO、PHP2Shellに続く「複数の重大な脆弱性」を把握 AIによる発見加速、今後数カ月の対応増を警告

米Cloudflareの最高経営責任者(CEO)、Matthew Prince(マシュー・プリンス)氏は2026年10月22日(米国時間)、ロイター通信の取材に対し、インターネットの基盤を支える別の重要ソフトウェアにも複数の深刻な脆弱性が存在することを把握していると明らかにしました。AIによるソフトウェア解析が、長年見過ごされてきた欠陥の発見を加速させており、今後数カ月は対応が相次ぐとの見通しを示しています。ロイターは23日付で発言を報じました。

直前の10月21日には、PHPの重大脆弱性「PHP2Shell」(CVE-2026-109618/CVE-2026-109619)の修正版が公開され、各国の企業や公共機関が緊急対応に追われました。一方、AIを活用した脆弱性の発見に関わったOpenAIも同日、すでに見つけた別の重大な脆弱性について修正作業を進めており、同様の発見が今後数カ月で急増すると予測しています。

現段階でPrince氏が把握する未公表の脆弱性について、製品名、CVE番号、影響バージョン、公表予定日などは示されていません。「PHP2Shell以上の深刻度」と確認されたわけでもありません。企業にとっては、特定製品の速報を待つだけでなく、重要システムの稼働バージョンと更新手順をすぐ確認できる運用へ切り替えることが課題になります。

Cloudflare CEOの発言と米国の周辺情報

  • 2026年10月23日、ロイター通信がCloudflareのMatthew Prince CEOへのインタビューを報道。
  • Prince氏は、ほかの重要ソフトウェアに存在する複数の深刻な脆弱性を把握していると説明。
  • 今後数カ月にわたり、AIが従来発見されなかった弱点を明らかにし、脆弱性対応が相次ぐとの見通しを示した。
  • 同氏は、向こう数年間、毎週のようにセキュリティ上の非常事態に直面する感覚になる可能性があると語った。
  • OpenAIも10月21日、すでに発見して修正に取り組んでいる複数の重大な脆弱性があると公式に説明。
  • 未公表案件の対象ソフトウェア、具体的な深刻度、修正版の公開日は明らかにされていない。
  • PHP2Shell、BrotliのHTTP2Shell、Plex2Shellなどは既に公表された別個の問題であり、Prince氏が言及した未公表案件だと確認されたものではない。
項目 確認できた内容
発言者 Cloudflare CEO Matthew Prince氏
発言日 2026年10月22日(米国時間)
報道日 2026年10月23日(ロイター)
把握している問題 別の重要ソフトウェアに存在する複数の深刻な脆弱性
今後の見通し AIによる発見が進み、数カ月にわたって対応が増える可能性
具体的な対象・CVE 未公表
「PHP2Shell以上」という比較 発言原文からは断定できない

「毎週のように危機が訪れる」 Cloudflare CEOが見据える今後の数年間

Prince氏はロイターに対し、重要ソフトウェアの別の部分に深刻な脆弱性が複数残っていることを認識していると述べました。さらに、今後数年間は毎週のように重大な問題が表面化する時期になるとの見通しを示しました。

これは、名前の分かっている特定の脆弱性について、公表日を予告した発言ではありません。ソフトウェアの広範な解析によって、これまで修正されずに残っていた弱点が続々と判明する可能性を指摘したものです。

脆弱性の存在を発見しても、公開に先立って影響範囲を特定し、開発者が修正し、配布事業者や利用企業が更新の準備を進める必要があります。対象が広く使われるOSSや通信基盤であれば、一つの修正が複数の製品・サービスの更新につながります。

OpenAIも「すでに見つけた複数の重大な脆弱性」を公表 AIによる解析が転機に

この警告を裏付ける動きとして、OpenAIは10月21日付の「Patch the Planet」に関する公式発表で、PHP2Shellはすでに発見して修正を進めている複数の重大な脆弱性の一部だと説明しました。今後数カ月で同様の発見が大幅に増えるとも予測しています。

PHP2Shellでは、CalifがOpenAIのAIモデルを利用して問題を発見し、Wizも独立した調査で脆弱性を報告しました。PHP開発チームが修正版を開発し、Cloudflareなどの関係者が公開前に防御策を準備しました。脆弱性を見つけるAIだけでなく、開発者、研究機関、クラウド事業者による事前調整が行われた事例です。詳細は、セキュリティ対策LabのPHP2ShellのAIによる発見と公開前の共同防御に関する記事で紹介しています。

米VulnCheckも2026年5月の分析で、複数の主要ソフトウェア開発元におけるCVEの公表数が前年同期比で大幅に増加していると報告しています。ただし、同社は増加分をすべてAIによるものと断定しておらず、こうした傾向が継続するかも評価段階としています。

一方、発見件数が増えることと実際の侵害が同じ割合で増えることは別です。ロイターの取材では、curlの開発者Daniel Stenberg氏らが、AIの発見する欠陥には攻撃への転用が難しいものもあると指摘しています。公開されるCVEの数だけで緊急度を判断するのではなく、悪用状況、公開範囲、攻撃成立条件を評価する必要があります。

PHP2Shell、HTTP2Shell、Plex2Shell すでに表面化した脆弱性が示す共通点

10月には、異なる製品群で重大な欠陥の公表と修正が相次ぎました。これらは個別の脆弱性であり、同じ原因によるものではありません。共通するのは、企業が直接管理していない依存ソフトウェアやサービスにも、修正作業が波及する点です。

公表済みの問題 主な影響・経緯 企業が確認する対象
PHP2Shell(CVE-2026-109618/CVE-2026-109619) PHP本体に存在する重大な欠陥。10月21日に修正版を公開。 Webサーバーや業務アプリで稼働するPHP、ホスティング事業者の対応
HTTP2Shell/Brotli(CVE-2026-111497) Brotliデコーダの境界外書き込み。10月21日のNode.jsセキュリティ更新でも修正対象となった。 Node.js、Brotliライブラリ、圧縮処理を含む依存コンポーネント
Plex2Shell(CVE-2026-96652ほか) Plex Media Serverの脆弱性を連鎖して悪用。Plexが実際の攻撃を公表し、CISAもKEVに追加。 外部公開されたPlexサーバーの更新と侵害調査

PHP2Shellの修正版と国内サービスの対応状況は、PHPの稼働環境を点検する際の参照先となります。また、Plex2Shellの悪用確認と米CISAの対応では、修正版がすでに提供されていても未更新の公開システムで被害が広がる問題を扱っています。

PHPについては10月23日にも追加の注意喚起がありました。PHP開発チームは、特定のセッション処理設定が組み合わさる場合にリモートコード実行につながり得る「CVE-2026-115560」を案内しました。10月21日に公開されたPHP2Shell修正版でもこの問題は解消されておらず、次の通常リリースで修正する予定です。ただし、発生には通常とは異なる複数の設定・コード条件が必要で、PHP2Shellと同じ範囲のシステムに直ちに危険が及ぶという意味ではありません。PHP側は暫定措置として、必要に応じて session.upload_progress.enabled=0 とするよう勧めています。

AIによる発見が加速しても、修正・検証を行う人員は急には増えない

脆弱性が次々と発見されると、修正プログラムを用意する開発者にも負荷がかかります。PHP FoundationのElizabeth Barron事務局長は10月23日のロイターの取材で、同財団の常勤職員は自身1人、ほかに主として非常勤の請負スタッフが14人いると説明しました。PHPへのコード変更提案は前年の約2倍に増えているものの、対応する開発者数は同じ比率では増えていないとしています。

AIが発見や検証を支援しても、修正の安全性、互換性、性能への影響を判断する工程は残ります。企業側でも、パッチを受け取ってから本番へ反映するまでには、依存アプリケーションのテスト、委託先との調整、システム停止の承認などが必要です。次々と脆弱性が公表される局面では、この作業を都度ゼロから組み立てない体制が対応速度を左右します。

情シスが今確認したいこと 重要システムの把握と更新計画を先に整える

未公表の脆弱性について製品を推測して対策することはできません。企業が事前に進められるのは、脆弱性が明らかになった際に、自社への影響を速やかに判定し、必要な更新を実施できる状態を作ることです。

1.事業上重要なシステムと外部公開資産を把握する

販売・受発注・決済・顧客対応・認証など、停止すると業務に直接影響するサービスを優先して一覧化します。担当部門、委託先、クラウドやホスティング事業者、インターネット公開の有無、代替運用の可否をひも付けます。自社サーバーだけでなく、委託先が保守するWebサイトや管理画面も対象です。

2.稼働バージョンと依存コンポーネントを確認する

OS、Webサーバー、PHP、Node.jsなどのランタイム、ライブラリ、プロキシ、コンテナイメージの実際の稼働バージョンを記録します。製品名だけではBrotliのような内部ライブラリの影響を見落とすため、ソフトウェア構成情報を管理するSBOM(ソフトウェア部品表)の活用も選択肢です。パッケージ名の表示バージョンだけでなく、OSやディストリビューションが修正をバックポートしているかも確認します。

3.緊急度を判定してアップデートスケジュールを組む

すべての更新を同じ順番で処理するのではなく、外部公開の有無、悪用が確認されているか、攻撃成立条件、扱うデータ、停止時の事業影響を基に優先順位を決めます。緊急更新に加え、検証開始日時、変更承認、作業担当者、メンテナンス時間、ロールバック条件、完了確認まで日程に落とし込みます。実悪用があり危険度の高い外部公開システムは、定例更新を待たず臨時対応を検討します。判断方法は脆弱性管理とパッチ適用の優先順位付けでも解説しています。

4.すぐに更新できないシステムの暫定措置を決める

ベンダーからの修正版提供待ち、互換性の問題、24時間稼働が必要な業務などで更新が遅れる場合は、不要な外部公開の停止、管理画面の接続元制限、WAF・IPSの緩和策、監視強化を検討します。ただし、WAFが有効であっても、未修正のソフトウェアに残る脆弱性そのものがなくなるわけではありません。

5.更新だけでなく、停止・復旧判断を事業部門と共有する

重大な脆弱性が公開されても直ちに修正できない場合、公開サービスを一時停止するか、制限付きで稼働を続けるか判断が必要です。事前にバックアップの復元手順、代替の受発注方法、顧客への案内、復旧の優先順位を決め、机上演習などで検証します。脆弱性への対応と事業継続を一体で考えるサイバーレジリエンスの整備が、緊急パッチの頻発する局面で事業停止時間を抑えるための備えになります。

発見数だけでなく、修正が行き渡る速度が問われる

Prince氏の警告は、具体的な新しいCVEの公表ではなく、広く使われるソフトウェアに残る欠陥がAIによって次々と顕在化する可能性を示したものです。OpenAIの公式発表も、未公表の重大な脆弱性について修正・調整が進んでいることを示しています。

脆弱性の名称が発表されてから、保有資産を探し始める運用では対応が間に合わない場合があります。企業側で先に決めておくのは、どのシステムが重要か、誰が稼働バージョンを確認するか、どの条件なら緊急更新するか、更新できない場合に誰がサービス停止を判断するかという点です。これらを把握できていれば、次の重大脆弱性の公表時にも対象の特定から修正までを短い手順で進められます。

出典・関連資料