PHP2Shell、協調的脆弱性開示の弱点を浮き彫りに

広く使われているプログラミング言語PHPで見つかった2件の重大な脆弱性は、企業に大きな衝撃を与えました。その影響を本当に理解するには、まだ時間がかかりそうです。ただ、あまり知られていない話題の一つが、脆弱性の開示をめぐる問題です。

PHP Foundationによると、複数の組織が、この重大な脆弱性と緩和策の詳細を協調して公開することで合意していました。ところが、サイバーセキュリティ企業のChainguardが、このエンバーゴを「一方的に」破りました。このためPHPプロジェクトはパッチの公開を前倒しせざるを得ませんでした。さらに攻撃者は、バイナリ形式の修正を解析し、防御側がシステムを更新する前に、エクスプロイトの概念実証コード（PoC）を作成できたといいます。

しかし、AWSやCloudflareなどは、実際の攻撃は開示の数時間前、場合によっては数日前に始まっていたと主張しています。

一部の推計では、PHP2Shellと総称される、深刻度9.2のこれらのバグを悪用しようとする試みは、すでに数百万件に上ります。政府機関を含む多くの組織が、Webサイトを完全にオフラインにする対応を取りました。

「率直に言って、脆弱性そのものより、開示をめぐる経緯のほうが興味深いと言えます」と、Dickson ResearchのFrank Dickson氏は語ります。「エンバーゴは重要です。しかし今回は、守り通すことがほぼ不可能でした」

混乱した開示

CVE-2026-109618とCVE-2026-109619を悪用されると、攻撃者にリモートコード実行（RCE）攻撃を仕掛けられる恐れがあります。

PHP Foundationは、CVE-2026-109618の原因となるメモリ不足（OOM）問題の最初の兆候を、委託先の一人が2024年の時点で見つけていたと認めています。ただし、当時は「具体的な攻撃経路」は見つからず、「明確な影響」のある他の問題に隠れて、この脆弱性への懸念は後回しになっていたといいます。

この問題の本格的な調査が行われたのは、2026年7月30日でした。PHP FoundationがPHPプロジェクトをOpenAIのPatch the Planetプログラムに参加させた後のことです。Calif、OpenAI、Google CloudのWizの研究者らが「OOM問題の影響の全容を明らかに」し、修正が最優先課題となりました。

研究者がパッチを開発すると、Chainguardを含むディストリビューターは事前にそれを受け取りました。これは、利用者が「脆弱性が開示された瞬間に」更新できるようにするためだったと、同財団は説明しています。エンバーゴは10月22日14時（UTC）に設定されました。

同財団によると、この協調的な開示は、エンバーゴ解除の2日前までは順調に進んでいるように見えました。10月20日の15時（UTC）ごろ、2件のCVE IDがオンライン上で出回り始めました。ただし、技術的な詳細は漏れていませんでした。PHPプロジェクトは事前告知を前倒しし、19時30分（UTC）に公開しました。あわせて、修正版のリリースも10月22日14時（UTC）から10月21日14時（UTC）に早めました。

事前告知の前倒しにより、サイバーセキュリティ企業のCalifは、多数のターゲットに対するPoCエクスプロイトの動画を「誤って」公開してしまいました。この動画では、脆弱性に関する「限定的な」詳細も明らかになりました。動画はその後削除されましたが、すでにソーシャルメディア上で拡散し始めていました。

続いて10月21日の7時41分（UTC）、Chainguardが修正を含むビルド済みイメージを公開しました。これは合意されたリリース時刻のおよそ6時間前にあたります。PHP Foundationは、この行為が「協調的な開示に向けた多くの関係者による数週間の取り組みを無視するもの」だったと批判しています。

事前公開から18時間後の10月21日14時（UTC）、PHPプロジェクトはパッチを公開しました。当初の予定より24時間早い公開です。

同財団によると、ディストリビューターはまだ修正のパッケージ化を進めている最中でした。そのため、これ以上早くリリースすれば、多くの利用者が簡単に更新できなくなるところでした。「リリースを1日前倒しすることが、迅速な対応、準備期間の確保、そして脆弱性の開示時に全員が簡単に更新できる手段の用意という点で、最善の妥協策でした」

ChainguardのCEOであるDan Lorenc氏は、同財団の批判に反論しました。実際に悪用されている証拠をつかんだうえで、開示プロセスのガイドラインに従って公開したと述べています。「この判断は、私たちが独自に脆弱性を発見してエクスプロイトを構築するのがいかに容易だったか、今後公開される脆弱性と修正についてすでにどれだけの情報が出回っていたか、そして実環境での悪用に関して共有された証拠に基づくものです」と、同氏はLinkedInへの投稿で書いています。 

実際、CloudflareのCEOであるMatthew Prince氏は、同社が公開発表の10時間前に、PHP2Shellを悪用しようとする「数千件」の試みを確認したと述べています。その数は「発表後45分で数万件、2時間以内に数十万件、そして今では数百万件」に跳ね上がったといいます。

また、AWSは、公開の4日前にあたる10月17日に、少なくとも1件の悪用の試みがあったと主張しています。AWSのCISOであるCJ Moses氏によると、この試みは商用の匿名化ネットワークに関連するIPアドレスから行われており、脅威アクターによる攻撃だったことがうかがえます。ただし、「このアクターが開示前にどうやってエクスプロイトの情報を入手したのかは、依然として不明」だということです。

秘密の保持は難しい、それでも正しい手法

複数の情報漏えいがあったように見えるものの、それがChainguardの免罪符にはならないと、Dickson氏は指摘します。同社が修正を早期に受け取ったのには理由があります。それを早く公開したことで、他のPHP利用者が待たされている間、攻撃者に解析材料を与えてしまったというのです。

「エンバーゴが防御側を守れるのは、他の誰かが同じバグを見つけるまでです」と同氏は述べ、修正が待機状態に置かれる期間が長いほど、保護の猶予は短くなると付け加えました。「パッチを事前に受け取る関係者が増えるたびに、秘密が漏れる経路も一つ増えます」

とはいえ、協調的な開示は依然として正しい手法であり、より厳格に運用する必要があるだけだと、同氏は語ります。具体的には、猶予期間を短くし、事前に受け取る関係者を減らし、修正そのものが秘密であることを明確に認識することです。「パッチは宝の地図です」と同氏は表現しました。

結局のところ、「秘密を守るのは難しい」と、Beauceron SecurityのCEOであるDavid Shipley氏は言います。「知る人が増え、期間が長くなるほど、何かが漏れる可能性は高まります」

同氏によれば、AIエージェントが登場し、脆弱性の仕組みについて少し知識があれば、「ツールをソフトウェアに向けるだけで解明できてしまう」ため、これは今や大きな問題です。

AI時代の責任

PHP2Shellの影響は、Log4Jと同様に、今後何年も続くとShipley氏は述べています。最大規模のオンライン拠点に現れた後、やがてIoTデバイスなどにも波及していくといいます。

防御側は、自社のソフトウェア資産と依存関係を把握しておく必要があります。その助けになるのが、ソフトウェア部品表（SBOM）です。「簡単な解決策ではありません。しかし、対応の成否を分けるのは、ITとサイバーセキュリティの地道な基礎作業です」とShipley氏は語ります。

企業には、製品メーカーの責任とAIツール提供者の責任も必要です。「この脆弱性の大量発生（vulnpocalypse）はAIのせいではありません」と同氏は言います。数十年にわたり、市場の動機づけは「まず出荷し、後で直す」「素早く動き、壊す」という方向にあったからです。

出荷は遅くても安全性を優先してきた企業は、そうしなかった企業に市場で打ちのめされてきました。後者は「技術的負債とセキュリティ負債を積み上げながら、目新しいものを次々と世に出した」とShipley氏は指摘します。特にAIの時代には、この動機づけを変える必要があります。

Dickson氏は、セキュリティチームに次のような対応を勧めています。ベンダー内部のものを含め、あらゆるランタイムがどこにあるかを把握すること。サービスをオフラインにする権限を誰が持つかを事前に決め、その判断を「危機の中で議論するのではなく、冷静なときに下せる」ようにしておくこと。想定外のプロセス実行やWebサーバー上の新規ファイルといった挙動に基づく検知に投資すること。特定のCVEのシグネチャは、ゼロデイの当日には存在しないからです。

「Chainguardはフライングをしましたが、競争はすでに始まっていました」とDickson氏は語ります。「エンバーゴは今も守る価値があります。ただ、CISOは、アドバイザリの公開前に悪用が始まることを前提に計画を立てるべきです。今ではそれが現実だからです」

この記事はもともとInfoWorldに掲載されました。