エンバーゴが破られたのは

エンバーゴとは

エンバーゴ（embargo）とは、脆弱性の詳細と修正版のリリースを、事前に合意した「協調公開の日時」まで、全員が内密に保つという約束です。これが重要な理由はたとえば「PoCコード、つまり実際に攻撃が成立した攻撃コードが巷に出回ったら」を想像すると分かりやすく。

何故そんな約束が必要なのか？

攻撃コードが出回ったとき、大体居るんです。「俺もやってみよー」って言う人。
そうした模倣犯が大量に出る中「パッチがありません」とか言われたらどうしますか？対処の仕様がないということになりませんか？

また、パッチは出たけどテストできてないとします。そのパッチがもしも他のセキュリティホールを産んだらどうします？セキュリティ侵害リスクは下がるどころか上がるかもしれません。なので、そうした手法の開示をするより前に、修正パッチは出来上がってなければなりません。そして、その修正パッチの品質は「オレオレ基準」ではなく、「ちゃんと公的に近しいレベルで認められたモノ」じゃないといけません。エンバーゴというのが重要視されるのはまさにそうしたところにあります。

その他、配布箇所を分散させることでネットワーク帯域の集中を避けるような施策など、私自身良く分かってないところの調整事が沢山あるかもしれません。正義のヒーローが一人でなんかすれば良いという話じゃないのです。

が、今回はこれが破られたことにより、セキュリティリスクが大いなる不安を持って全世界に晒されることになり、しかもRCE系の問題だったことが重なって阿鼻叫喚地獄絵図が日本のみならず全世界で晒されることになったわけで。

正直、このブログ自宅系サーバとかじゃなくて、マネージド型のサービスを選択して本当に良かったと思いました。

結局漏洩者ってだれやねん？

で、事が済んだ後のこの話。X.comで特定の3アカウントが晒されてこちらも阿鼻叫喚地獄絵図のよう相を呈しているのですが、私も当初は「けしからん」とらしくないことを思いましたが、どうも事はそんなに単純ではなさそうです。こういうことこそエージェントAI使って調べたら良かったんじゃなかろうかということで、我が家のQwen3.8-Flash-Nextさんに調べてもらいました。すると、色々事情が複雑なことが分かりました。

ぶっちゃけこういうことのようです。

漏洩は単一の起点がありません。調整公開予定（10月22日）の2日前にあたる2026年10月20日、同日中に複数の場所同時にエンバーゴが壊れました。最初の流出は匿名のHacker News投稿で、その人物は未特定です。[S19]

時系列を表にしてもらったところ、以下のような内容だったようです。それぞれの文末に [S**] って記述がありますが、これは最後に転載しているソース情報を示しています。これも正確性は完全には保証できませんが、少なくとも Jから始まるとある者ではなさそうです。

時刻・主体	公開された内容	非難の性質
10/20 匿名Hacker News投稿（「信頼できる情報源」と付記、削除済み）	脆弱性の存在、CVE番号、CVSS 10.0という誤った深刻度、誤った公開時刻。スクリーンショットがXとMastodonに到達 [S19][S33]	最初の流出源。投稿者不明。PHPは名前を挙げていない [S30]
同時刻、PHP2Shellツールのスクリーンショット＋短い攻撃動画	露出はadvisoryと共に流れ、動画も同じく投稿→削除 [S19]	出所未確認。発見者側の内部資料が漏れた可能性を示唆するが、資料は断定していない
10/20 watchTowr（CEO Benjamin Harris）がX上で公開確認	「本来は木曜11時ETまで待つはずだった」と述べ、脆弱性が実在することを承認、両CVE番号を掲載。CVE-2026-109618を再現したと説明 [S19][S20][S21][S22]	噂を実行可能な情報に変えたと批判された。一方で詳細は公開せず、再現のみと説明 [S30]
10/21 07:41 UTC Chainguard	協調公開（14:00 UTC）の6時間以上前に修正済みコンテナイメージを単独公開。バイナリの修正内容が誰でも検証可能になった [S25][S23]	PHPメンテナがブログで明確に非難。CEO Dan Lorencはタイムラインを否定せず、脆弱性の漏洩は否定 [S23][S24]

このあたり、PHP Foundationがリリースした https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ でも述べられており、裏付けはできてるようです。（以下はリリース記事の和訳：Powered By Plamo翻訳）

リークと公開の中断
これらの脆弱性の協調的な公開は、対象のリリース日の2日前までは順調に進んでいました。

10月20日（火）15:00 UTC頃、2つのCVE IDがオンラインフォーラムやSNSで拡散され始めました。それらには誤ったリリース時刻と、10.0という誤ったCVSSスコア（実際のスコアは9.2）が添えられていました。技術的な詳細は漏洩していませんでした。これを受けて、PHPプロジェクトは事前告知を前倒しし、19:30 UTCに公開しました。また、リリース日を10月22日 14:00 UTCから10月21日 14:00 UTCへと変更しました。ディストリビューターがまだ修正プログラムをパッケージ化していたため、即座にリリースすると、多くのユーザーが容易にアップデートできない状況に陥る恐れがありました。リリースを1日前倒しすることは、迅速な対応、準備時間の確保、そして脆弱性公開時に誰もがシンプルなアップデート経路を確保できることの、最善の妥協点でした。

情報漏洩と20:00 UTC頃の事前告知の結果、問題を報告したセキュリティ企業の一つであるCalifが、誤って動画を公開してしまいました。その動画には、複数のターゲットに対して動作する概念実証（PoC）が映っており、脆弱性に関する限定的ながらもいくつかの追加詳細が明らかになっていました。削除された動画のコピーがその後すぐにSNSで拡散され始めました。この動画がさまざまなPoC（エクスプロイテーション概念実証）の開発を加速させ、その結果、10月21日にさらなる拡散を招きました。

2023年10月20日 23:00 UTC頃から一部の重要インフラプロバイダーに提供し始めた緩和策に関するアドバイスも、漏洩した可能性があります。PHPセキュリティチームは、漏洩後に出現したPoCを綿密に監視・調査しましたが、公開・公表時点で動作するエクスプロイトは特定できませんでした。

10月21日 07:41 UTC、協調的な公開の6時間以上前に、Chainguardが一方的にエンバーゴを解除し、修正を含むビルドイメージを公開しました。他のディストリビューターと同様に、Chainguardは事前にパッチを受け取っていたため、ユーザーは脆弱性が公表された瞬間にアップデートすることができました。これにより、他のすべてのPHPユーザーが依然として公開を待っていた一方で、攻撃者はバイナリ形式で修正内容を調査することが可能となりました。これは、協調的な公開に向けて多くの関係者が数週間にわたって積み重ねてきた努力を無視するものでした。

つまり、脆弱性の検証コードが直接的に出たわけでなく、出所不明なHacker Newsの記事を見て焦った各関係者がそれに対して何とかしようとして行動した結果、結果的に「脆弱性検証コードの元になる情報まで出しちゃった」という解釈があってそうに見えました。

そしてPHP Foundationの非難の矛先は、「PoCコードの元」を公開しちゃったChainguard社に向けられていたようです。で、実際にその検証を組み立ててみた一人が今世界中から非難を受けてるとある者であり、その後は以下の流れになるのかなと言う感じのようです。

10/21 パッチ数時間前、とある者がPoCを公開。コードは成立せず、作者は自ら理論を撤回。[S26]
Florian Roth氏（Phoenix Security経由）はCVSS 10.0（PHP公式は9.2）と「PHP 5.4以降」を伝達。PHP 6は存在せず、advisoryが修正対象とするのは8.2〜8.5のみ。未検証のエクスプロイトバンドルを伝達した。[S19]
PHPはこれらの流出を理由に公開を1日前倒しし、10月20日19:30 UTCに事前告知を前倒しで出しました。[S19][S33]

なお、この脆弱性を突いた攻撃それ自体は情報リーク以前の段階で既に発生してたようで、AWSのハニーポットが既にその形跡を観測してたようです。

AWSのハニポットは10月17日（公開4日前）に、複数プロバイダで匿名化されたPHP2Shell悪用試行を観測。複数アクターが異なる目的で試行した可能性が示唆されています。[S27][S28]
攻撃者がどう情報を入手したかはAWS側でも不明とされています。[S27]
これは「公開漏洩」より前に情報が外部に存在したことを意味し、公開漏洩の主体と攻撃者を同一視する根拠は資料にありません。

私自身色眼鏡でものを見てるなぁと痛感させられまして、まことに恥じ入るところいっぱいでございます。いやなさけなや。もっと多面的に物事は見るべきと言う事を痛感した次第です。

ただ、とある者の行動が賞賛されるべきものではないことも確かです。ただ、全ての原因というわけでもありません。本当に脆弱性を突いてくる輩というのは、我々がそうした情報に気づくずっと前から恐らくは気づいて実行し、色々なところに問題を起こしてるのだろうと考えられます。

特に私たちも非常に高性能なAIモデルを手元に置くことができるようになり、その中には今回のようなことをする人がやっぱり居ます。今後、人間を基準にしたセキュリティポリシーではなく、また別の基準が必要になってくるんだろうなーと感じた次第です。