# エンバーゴにおける諸問題の調査レポート ## はじめに 2026年10月、PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618 / CVE-2026-109619）の公開をめぐり、PHP Foundationと、合意より早く修正版を公開したChainguardとの間で、エンバーゴ（公開までの秘密保持の取り決め）を破ったか否かの論争が起きた。本稿は、この論争を入口として、エンバーゴという仕組みそのものが抱える問題を、近年の主要事例と当事者の主張から整理するものである。 本稿では、記述を次の三つに区分する。 - **【事実】**：一次情報（当事者の声明、公式文書、公開アーカイブ）または報道で確認できる事項。報道のみに依拠する場合は脚注に「報道」と付記する - **【解釈】**：事実から筆者が読み取った内容 - **【仮説】**：検証を要する見立て 調査の深度は概要レベルである。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 更新履歴 | 日付 | 内容 | |---|---| | 2026-10-23 | 初版作成 | | 2026-10-24 | PHP2Shellの情報をHacker Newsに投稿した人物の事例を追加 | --- ## 1. 「エンバーゴ」とは何か ### 1.1 定義 **【事実】** エンバーゴ（embargo）とは、協調的脆弱性開示（CVD: Coordinated Vulnerability Disclosure）の過程で、脆弱性の情報を限られた関係者の間に留め、公表日を合意して、それまで公開しないとする取り決めである。 CERT/CCのCVDガイドは、エンバーゴの性格を次のように表現している[^1]。 > the embargo is a courtesy offered by the Reporter or Coordinator to the Vendor > > （意訳）エンバーゴは、報告者または調整機関がベンダーに提供する「好意」である。 > > （注）原文では、この一節の前に「拘束力のある別段の合意がない限り」という限定が付いている。 **【事実】** FIRSTの多者間脆弱性調整ガイドラインは、エンバーゴという語を用いるが、正式な定義は置いていない。期間についても固定の日数は定めず、事前の公表や実際の悪用がない限り、ベンダーに「合理的な」期間を与えるべきとし、日程は早い段階で交渉すべきとしている[^2]。 **【解釈】** エンバーゴは、通常は法的な契約ではなく、関係者の自発的な協力によって成り立つ紳士協定である。CERT/CCの「好意」という表現は、拘束力のある合意がない限り、これが権利ではなく、与える側がいつでも撤回し得るものであることを示している。 ### 1.2 目的 **【事実】** エンバーゴの目的は、利用者が修正版を適用できる状態で公表日を迎えることにある。PHP Foundationは、公表前にディストリビューターへ修正を渡しておくことで、利用者が公表と同時に更新できるようになると説明している[^3]。 **【解釈】** 脆弱性の情報が公開された瞬間から、攻撃者と防御者の競争が始まる。エンバーゴは、その号砲が鳴る時点で、防御側だけが先に準備を終えている状態を作るための仕組みである。 ### 1.3 代表的な運用ルール **【事実】** エンバーゴの期間や違反時の扱いは、コミュニティや組織ごとに定められている。 | 主体 | 期間 | 主な規定 | |---|---|---| | Openwall linux-distrosリスト[^4] | 最長14日。7日未満が望ましい | 漏洩させた参加者は、報告者とリストに急いで知らせ、内部調査を行う。修正がすでに公開リポジトリにある問題は一般に公知とみなし、distrosではなくoss-securityに報告する | | Linuxカーネル（ソフトウェアの脆弱性）[^5] | 既定は準備でき次第公開。報告者等の要請があれば、堅牢な修正ができてから最長7日まで延期できる。重大な場合は合意により例外的に14日まで | 公表を遅らせてよい正当な理由は、品質確認と大規模展開の調整に限る | | Linuxカーネル（ハードウェアの脆弱性）[^6] | 固定の上限なし。必要最小限に限る | 違反者は当該案件から即時に除外し、関連メーリングリストから削除する。加えて、今後の案件からも除外する | | Google Project Zero[^7] | 90日。悪用が確認された脆弱性は7日 | 期限内に修正されれば、技術的詳細は修正の30日後に公開する。期限までに修正されなければ、期限で公開する | **【解釈】** 期間の長さは、コミュニティごとに大きく異なる。共通しているのは、いずれも「修正版を出すための時間」に限って秘密保持を認め、それ以外の理由（たとえば学会発表の日程）による延長を嫌う点である。 ### 1.4 法制度との関係 **【事実】** 近年、国家がエンバーゴの「輪」に加わることを求める制度が現れている。 - **中国「網絡産品安全漏洞管理規定」（2021年9月施行）**[^8]：製品提供者は、脆弱性を知ってから2日以内に工業情報化部（MIIT）のプラットフォームへ報告しなければならない。また、脆弱性の発見・収集に従事する組織・個人に対しては、製品提供者が修正を提供する前の公表を原則として禁じ（関係者との協議と当局への報告を経た事前公表の例外手続きがある）、未公開の脆弱性情報を製品提供者以外の国外の組織・個人へ提供することも禁じている。 - **EU サイバーレジリエンス法（CRA）第14条（2026年9月11日適用）**[^9]：製造者は、積極的に悪用されている脆弱性を認知してから24時間以内に早期警告を、ENISAの単一報告プラットフォーム（SRP）を通じて調整役のCSIRTとENISAへ提出しなければならない[^10]。サイバーセキュリティ上の正当な理由がある場合に他のCSIRTへの共有を遅らせる仕組みも用意されており、その条件は委任規則（EU）2026/881で定められた[^11]。 **【事実】** CRAの立法過程では、2023年10月、セキュリティ分野の専門家56人が公開書簡を出し（所属組織名は肩書きとして記載されたもので、組織としての署名ではない）、修正前の脆弱性情報を政府が集めることの危険を指摘した。書簡は、政府が保有する脆弱性情報が漏洩・悪用される危険は「理論上のものではない」と述べている[^12]。 **【解釈】** 従来のエンバーゴは、発見者・ベンダー・ディストリビューターという技術的な当事者の間の取り決めだった。法制度の登場により、「輪」の内側に誰を入れるかを、当事者だけでは決められなくなりつつある。 --- ## 2. 「エンバーゴ」が破られるとどうなるのか ### 2.1 秘密保持の前提が消える **【事実】** CERT/CCのCVDガイドは、情報が漏れた場合には、何が、どのように漏れたかを確認したうえで、公表を前倒しすることを検討すべきとしている[^13]。さらに、悪用の証拠や公開の場での漏洩がある場合、エンバーゴは事実上意味を失い、関係者は直ちにエンバーゴを打ち切って公表する準備をしておくべきとしている[^1]。 **【解釈】** 一人が破れば、残りの全員が「破られた」前提で動かざるを得ない。エンバーゴは、全員が守っている間だけ価値を持つ仕組みである。 ### 2.2 修正そのものが攻撃の手がかりになる **【事実】** 2008年の研究は、Microsoftの5つのパッチを対象に、修正前後のバイナリの差分から、多くの場合数分で攻撃コードを自動生成できることを示した[^14]。PHP Foundationも、Chainguardが修正済みのバイナリを早く公開したことで、攻撃者が修正内容をバイナリから研究できる状態になったと指摘している[^3]。 **【解釈】** 「修正版を一部の人にだけ先に配る」ことは、「脆弱性の在りかを一部の人にだけ先に教える」ことと表裏一体である。修正版の公開は、それ自体が情報の公開になる。 ### 2.3 準備の整っていない者が取り残される **【事実】** CUPSの事例（3.5節）では、公表日が前倒しされたため、ESMを含む全てのUbuntu向けの修正を同時に出すというCanonicalの計画に影響が出た[^15]。 **【解釈】** エンバーゴが破られた時点で、修正版を手元に持っている者と持っていない者の差が、そのまま利用者の危険の差になる。被害は、規模が小さく準備に時間のかかる下流の配布者や、その利用者に偏りやすい。 ### 2.4 信頼が損なわれる **【事実】** Linuxカーネルのハードウェア脆弱性の手続きは、違反者を当該案件から即時に除外するだけでなく、今後の案件からも除外すると定めている[^6]。KRACKの発見者は、OpenBSDの早期修正を認めたことを後に悔やみ、今後OpenBSDへの通知はエンバーゴの終わり近くに行うと表明した[^16]。 **【解釈】** エンバーゴ違反の代償は、その一件の被害に留まらない。次の案件で「輪」に入れてもらえないという形で、長く尾を引く。 --- ## 3. 「エンバーゴ」が破られた事例 ### 3.1 一覧 | 年 | 事例 | 破られ方 | 破った（とされる）側 | |---|---|---|---| | 2017 | KRACK（Wi-Fi WPA2） | 合意の上での早期修正が、事実上の先行公開になった | OpenBSD（発見者の同意あり） | | 2018 | Meltdown / Spectre | 公開されたパッチや報道から推測が広がった | 特定の違反者なし（推測の連鎖） | | 2021 | Log4Shell | 修正が公開リポジトリに載り、その後PoCが公開・流通した | 特定の違反者なし（構造的露出）。国家との摩擦も発生 | | 2024 | CUPS | 調整基盤（VINCE）経由とみられる流出 | 不明 | | 2026 | Dirty Frag（Linuxカーネル） | 公開済みの修正から、第三者が攻撃コードを作った | 第三者（本人は「エンバーゴに参加していない」と主張） | | 2026 | PHP2Shell | CVE番号などの流出、PoC動画の誤公開、修正版の先行公開 | 情報の出所は不明（Hacker Newsで広めた個人は、エンバーゴの存在を知らされていなかった）、Calif（誤公開）、Chainguard（先行公開） | KRACKは「ここ数年」の範囲からはやや古いが、エンバーゴの長さをめぐる論争の原型として取り上げる。 ### 3.2 KRACK（2017年） **【事実】** - 2017-07-15：発見者のMathy Vanhoefが、OpenBSDに脆弱性を通知した。OpenBSDのTheo de Raadtは、暫定の期限に異を唱えた[^16]。 - 2017-08-28：CERT/CCが広くベンダーに通知し、エンバーゴは当初の8月末より延長された[^16]。 - 2017-08-30：OpenBSDは、発見者の同意を得たうえで、詳細を伏せた短い説明（状態遷移の誤りにより古いWPA鍵が再インストールされ得る）を付けて修正を公開した[^18]。 - 2017-10-16：脆弱性が公表された。 ### 3.3 Meltdown / Spectre（2018年） **【事実】** - 2017-06-01：Google Project ZeroがIntel、AMD、ARMに報告した。協調公表日は2018-01-09とされていた[^19]。 - 2017-12-26〜27：AMDの技術者が、AMDのCPUでは問題の対策を有効にしないとするパッチをLinuxカーネルのメーリングリストに投稿した。AMDのCPUは投機的実行で権限外のデータに触れない、という説明が添えられていた[^20]。 - 2018-01-02：The Registerが、伏せられたままのカーネルパッチとAMDの投稿を手がかりに、Intel製CPUの設計上の欠陥として報道した[^21]。 - 2018-01-03：Googleは、公の報道と憶測の広がりで悪用の危険が高まったとして、予定より早く公表した[^19]。同日、Intelも声明を出した[^22]。 - FreeBSDが問題を知らされたのは2017年12月下旬だった[^23]。 ### 3.4 Log4Shell（2021年） **【事実】** - 2021-11-24：Alibaba CloudのChen Zhaojunが、Apacheに脆弱性を報告した[^24][^54]。 - 2021-11-30：修正のプルリクエストが公開の場に出された。保守者は後に、修正が公開されたまま9日間露出していたと振り返っている[^54]。 - 2021-12-01以降：Cloudflareは、公表前から悪用の試行を観測していたと報告している[^26]。 - 2021-12-05：JNDIの利用を制限する修正が、公開のGitHubリポジトリに取り込まれた[^25][^54]。 - 2021-12-09：脆弱性を示唆する投稿がSNSに現れ、PoCが流通した[^27]。 - 2021-12-10：CVE-2021-44228が公表された。ASFは後に、修正版の公開の前日から広く悪用されたと記している[^28]。 - 2021-12-22頃：MIITが、政府への報告が遅れたとして、Alibaba Cloudとの脅威情報共有の協力関係を6か月停止したと報じられた[^29]。 ### 3.5 CUPS（2024年） **【事実】** - 2024-09-05：研究者Simone Margaritelliが、OpenPrintingに脆弱性を報告した。調整はCERT/CCのVINCEを通じて行われた[^30][^31]。 - 2024-09-23：Margaritelliが、全てのGNU/Linuxに影響する認証不要のRCEがあると、詳細を伏せてSNSに投稿した[^31]。 - 2024-09-26：OpenPrintingの開発者が、VINCE上で脆弱性の情報が流出したことを知った[^31]。発見者は、攻撃コードを含む報告書が流出したと説明している[^30]。 - 2024-09-26：発見者とベンダーが合意していた公表日2024-10-06を待たずに、詳細が全面公開された[^31][^32]。 ### 3.6 Dirty Frag（2026年） **【事実】** - 2026-04-29〜30：研究者Hyunwoo KimがLinuxカーネルのセキュリティチームに2件の脆弱性を報告した。修正パッチは、同時に公開のメーリングリスト（netdev）にも投稿された[^33]。 - 2026-05-07：2件のうちESPの修正が、公開の開発ツリー（netdev）に取り込まれた（RxRPCの修正がmainlineに入ったのは05-10）。Kimはlinux-distrosに5日間のエンバーゴで通知したが、同日、無関係の第三者が修正を手がかりに攻撃コードを公開した。Kimは、ディストリビューターの同意を得て全面公開した[^33][^34]。 - 公開時点では、修正版のカーネルもCVE番号も存在しなかった[^34]。 **【事実】** 同時期の2026年4月には、Linuxカーネルの別の脆弱性「Copy Fail」でも、主要なディストリビューターの修正版がないままPoC付きで公表された。Greg Kroah-Hartmanは、容易な攻撃コードの公開を事前に知らせる義務は誰にもなく、カーネルチームも他者に事前に知らせることを認められておらず、事態は関係者全員の手の及ばないところで起きた、という趣旨を述べている[^35]。 ### 3.7 PHP2Shell（2026年） **【事実】** PHP Foundationの公表による経緯は次のとおりである（時刻はUTC）[^3]。 - 2024年：外部監査の指摘を修正する過程で、根本原因の兆候が見つかった。修正方針がまとまらず、対応が停滞した。 - 2026-08-11：Califが、同じ根本原因の無条件RCEを報告した。同日、OpenAIも独立に同じ根本原因を報告した。 - 2026-10-20 15:00頃：CVE番号が、誤った公表日時と深刻度（CVSS 10.0。正しくは9.2）とともに、オンラインフォーラムとSNSで出回った。 - 2026-10-20 19:30：PHPは公表を10-22から10-21に前倒しした。 - 2026-10-20 20:00頃：Califが、PoCの動画を誤って公開した。 - 2026-10-21 07:41：Chainguardが、修正済みのイメージを公開した。協調公表の6時間以上前だった。 - 2026-10-21 14:00：協調公表。 **【事実】** これとは別に、2026-10-20、Hacker Newsに、「信頼できる情報筋」によれば2026-10-22 18:00 CEST にCVSS 10.0のRCE 2件の発表が予定されている、とする投稿があった。投稿には、CVE-2026-109618とCVE-2026-109619の番号が記されていた[^55]。この投稿に対しては、すでにXで拡散している、とする返信もあった[^57]。 **【解釈】** この投稿の内容（CVE番号、実際とは異なる公表日時、実際とは異なるCVSS 10.0）は、PHP Foundationが説明した流出の内容とよく一致する。ただし、それより前にXで拡散していたとの指摘もあり、この投稿が流出の起点であったかは確定できない。 --- ## 4. 「エンバーゴ」を破られた側、破った側それぞれの主張 ### 4.1 KRACK **破った側（OpenBSD）** **【事実】** OpenBSDは当初から期限が長すぎ、利用者を危険にさらすと抗議していた。延長が決まった後も、元の合意どおりに、発見者の同意を得て修正を出した[^17]。Theo de Raadtは、修正を書き上げた開発者が1か月も待たされるのは意欲をそぐ、と述べていた[^16]。 **破られた側（発見者）** **【事実】** Vanhoefは、早期修正を認めたことで、他者が修正から脆弱性を再発見できる状態になったとして、判断を悔やんだ[^16]。 > In hindsight this was a bad decision > > （意訳）振り返れば、これは誤った判断だった。 ### 4.2 Meltdown / Spectre **早く公表した側（Google）** **【事実】** Googleは、既存の公開報道と、報道機関や研究者の間で強まる憶測により悪用の危険が高まったことを、前倒しの理由に挙げた[^19]。 **予定を守ろうとした側（Intel）** **【事実】** Intelは、この問題をIntel固有の欠陥とする報道は誤りであり、他のベンダーと共に、より多くの更新が揃う翌週に公表する予定だったとした[^22]。 > Intel is making this statement today because of the current inaccurate media reports. > > （意訳）Intelが本日この声明を出すのは、現在の不正確な報道のためである。 **輪の外に置かれた側（オープンソースのOS）** **【事実】** OpenBSDのTheo de Raadtは、一部の大企業だけに事前情報が渡された「選択的開示」だと批判した[^36]。 > Everyone below Tier-1 has just gotten screwed. > > （意訳）Tier-1より下の者は皆、ひどい目に遭わされた。 **【事実】** Greg Kroah-Hartmanは、IntelがSUSE、Red Hat、Canonicalを互いに隔離し、各社が互いに話せないまま、それぞれ異なる修正を作ることになったと批判した[^37]。Linuxカーネルは2019年、Meltdown、Spectre、L1TFなど過去の事案を踏まえて、ハードウェア脆弱性のための専用の手続きを定めた[^6]。 ### 4.3 Log4Shell **OSSの開発者側（Apache）** **【事実】** Apacheは、報告者を公式に記録したうえで、公開リポジトリで修正を進めた[^24][^25]。Apacheが報告者や公表の経緯を批判した声明は、確認できなかった。 **報告者側（Alibaba Cloud）** **【事実】** Alibaba Cloudは、業界の慣行に従ってApacheに報告したが、早い段階で深刻さを認識できず、脆弱性情報を適時に共有できなかったと説明した[^38]。 **国家（MIIT）** **【事実】** MIITは、Alibaba Cloudが電気通信の主管部門に速やかに報告しなかったことを問題としたと報じられている[^29]。 **【解釈】** この事例では、「誰が破ったか」の構図が他と逆転している。国家は、エンバーゴの「輪」に自分も速やかに入れるべきだったと主張した。開発者・報告者・国家の三者がそれぞれ別の「正しい開示の順序」を持っていたことになる。 ### 4.4 CUPS **公表した側（発見者）** **【事実】** Margaritelliは、調査には数日しかかからなかったが、調整には22日を要し、その間、開発者から見下すような扱いを受けたと述べた。流出については、VINCEにバックドアか内部の漏洩者がいるか、参加者の審査がないかのいずれかだと批判した[^30]。そのうえで、自身の経験に照らして、と前置きして次のように述べている。 > the responsible disclosure process is broken. > > （意訳）責任ある開示のプロセスは壊れている。 **開発者側（OpenPrinting）** **【事実】** OpenPrintingは、SNSでの予告が脆弱性を過大に宣伝したと反論した。cups-browsedがインターネットに露出していることはまれで、攻撃には利用者が偽のプリンターに印刷する操作が必要だとした。その上で、流出のため、公表を10-06から09-26に早めざるを得なかったと説明した[^31]。Red Hatも、重要度を「Important」（一部は「Moderate」）と評価し、該当するサービスは既定では無効になっているとした[^39]。 **調整機関（CERT/CC）** **【事実】** CERT/CCが流出について公に説明した記録は確認できなかった。 ### 4.5 Dirty Frag **破られた側（発見者）** **【事実】** Kimは、外部要因でエンバーゴが破られたため、ディストリビューターの要請に応じて公開したと説明した[^51]。oss-securityへの投稿では、次のように述べている[^34]。 > Because the embargo has now been broken, no patches or CVEs exist > > （意訳）エンバーゴが破られたため、修正版もCVEもまだ存在しない。 **攻撃コードを公開した側（第三者）** **【事実】** 攻撃コードを公開した研究者は、公開済みの修正コミットから作った「n-day」の攻撃であり、エンバーゴを破ったのではないと主張した。linux-distrosのエンバーゴには関与しておらず、期限も知らなかったという[^40]。 > n-day from public commit, not embargo break > > （意訳）公開済みコミットからのn-dayであり、エンバーゴ破りではない。 **【事実】** Gentooの開発者は、この説明に謝意を示し、修正が攻撃に転用される速さを示す例だと述べた[^41]。なお、発見者自身も、修正を最初に公開のメーリングリストへ投稿していたことを経緯の中で認めている[^33]。 ### 4.6 PHP2Shell **破られた側（PHP Foundation）** **【事実】** PHP Foundationは、Chainguardの先行公開を一方的なエンバーゴ破りとし、次のように述べた[^3]。 > This disregarded weeks of work by many parties toward a coordinated disclosure. > > （意訳）これは、多くの関係者が協調開示に向けて重ねてきた数週間の作業を無視するものだった。 また、公表の時点で機能するエクスプロイトは確認されていなかったとした[^3]。理事のNils Adermannは、この判断を無責任だとして謝罪を求めた[^42]。 **破った側（Chainguard）** **【事実】** CEOのDan Lorencは、Hacker Newsで、実際の攻撃が出始めたことを受けて自ら判断したと説明した[^43]。 > get these out early when exploits hit in the wild > > （意訳）実際の攻撃が出てきたので、早く出すことにした。 Lorencは、自社で容易に脆弱性を再発見し攻撃手法まで作れたことを判断の根拠とし、PHP Foundationとメンテナーに負担をかけたことには遺憾の意を示した[^44]。また、修正済みイメージは誰でも入手できるとして、自社の顧客のための行為だという見方を否定した[^44]。イメージが無償であり今後も無償であることは、本人がHacker Newsで述べている[^43]。Chainguardの開示方針は、悪用が確認された場合などに期限を短縮できると定めているが、これは同社自身の基準であり、PHP側の同意を意味しないとの指摘がある[^45]。 **情報を広めた側（Hacker Newsの投稿者）** **【事実】** 2026-10-20に情報を投稿した人物は、2026-10-22に改めてHacker Newsに投稿し、謝罪した。投稿の時点でエンバーゴの存在を知らず、情報提供者からも、その提供者のさらに提供者からも、エンバーゴはないと聞いていたという。投稿の意図は、自分と同じようにPHPをソースから構築している人々に、更新の緊急性を知らせることだったとしている[^56]。 > At the time of posting, I didn't know about any embargo. > > （意訳）投稿した時点で、私はエンバーゴの存在を何も知らなかった。 **【事実】** 返信の中には、知らされていなかったエンバーゴを破った責任を負えるはずがない、とする擁護があった。この人物はフリーランスのコンサルタントで、関係するどの団体とも提携関係はないとされる[^57]。 **誤公開した側（Calif）** **【事実】** CalifがPoC動画の誤公開について公に説明した記録は、確認できなかった。 --- ## 5. 考察 ### 5.1 「破る」には四つの型がある **【解釈】** 六つの事例を並べると、「エンバーゴが破られた」と一口に言っても、その実態は大きく四つに分かれる。 | 型 | 内容 | 該当事例 | |---|---|---| | ① 漏洩 | 意図せず情報が外に出る | Meltdown（パッチと報道からの推測）、CUPS（調整基盤からの流出）、PHP2Shell（CVE番号の流出、動画の誤公開） | | ② 意図的な前倒し | 自分の判断基準で、合意より早く公開する | KRACK（同意あり）、Meltdown（Googleの前倒し）、PHP2Shell（Chainguard） | | ③ 構造的な露出 | 公開の場で開発する仕組みが、そもそも秘密を保てない | Log4Shell（公開リポジトリの修正）、Dirty Frag（公開メーリングリストの修正） | | ④ 制度との衝突 | 国家が「輪」に入ることを求める | Log4Shell（MIIT） | **【解釈】** ③の型では「破った者」が存在しない。Dirty Frag で攻撃コードを公開した研究者の、参加していない約束は破りようがない、という趣旨の主張は、形式論理としては正しい。Openwall の linux-distros の規則も、修正がすでに公開リポジトリにある問題は一般に公知とみなしている[^4]。つまりこの型では、エンバーゴは破られたのではなく、最初から成立していなかったと見るべきである。オープンソースが公開の場で開発することを本質とする以上、③の型は今後も繰り返し起きると考えられる。 **【解釈】** ①の型でも、情報を公にした者が約束の当事者とは限らない。PHP2Shellで情報をHacker Newsに投稿した人物は、エンバーゴの存在を知らされておらず、伝えられたのはむしろ「エンバーゴはない」という情報だった[^56]。Dirty Frag の研究者と同じく、約束の外にいた者である。この場合、エンバーゴが実際に失われたのは、情報が公開された地点ではなく、情報が輪の内側から外側へ渡る途中で、「エンバーゴの対象である」という表示が失われた地点である。表示が失われた後の受け手には、守るべき約束そのものが見えない。 ### 5.2 対立は「価値」ではなく「事実認識」をめぐって起きている **【解釈】** 破った側と破られた側の主張を並べると、両者は同じ価値、すなわち「利用者を守る」から出発している。対立しているのは価値ではなく、「攻撃者はすでに知っているか」という事実認識である。 - 破った側は、「すでに漏れている」「すでに攻撃が始まっている」「誰でもすぐに再発見できる」と主張する（Google、Chainguard、OpenBSD） - 破られた側は、「まだ機能する攻撃は出ていない」「全員の準備が整うまで待つべきだ」と主張する（Intel、PHP Foundation） **【解釈】** 問題は、この事実が判断の時点ではほとんど検証できないことである。Lorencは、LinkedInの投稿では悪用の報告元や証拠を示していない[^45]。別の場では、他ベンダーの観測や自社のハニーポットでの観測に言及しているが[^52]、第三者が検証できる形にはなっていない。PHP Foundationも機能する攻撃が「確認されなかった」と言えるだけで、どこかで悪用されていた可能性までは否定していない[^3]。検証できない事実を前提に各自が判断すれば、判断は必ず割れる。 **【解釈】** したがって、「どちらが正しかったか」を事後に問うことには限界がある。問うべきは、検証できない状況で誰が判断を下すのかが、事前に決まっていたかどうかである。 **【解釈】** PHP2Shellの情報をHacker Newsに投稿した人物も、同じ構図にある。投稿の意図は、ソースからPHPを構築している利用者に更新の緊急性を知らせることであり[^56]、出発点はやはり「利用者を守る」という価値だった。判断を分けたのは、「エンバーゴはない」という、誤って伝えられた事実認識である。 ### 5.3 「輪」の広さと秘密の強さは両立しない **【解釈】** Meltdown / Spectre では、「輪」を狭く保とうとした結果、オープンソースのOSが外に置かれ、隔離された各社がそれぞれ異なる修正を作った[^37]。一方、CUPSでは、発見者が、多数の関係者が参加する調整基盤から情報が流出したと主張している[^30]。輪を広げれば漏れやすくなり、狭めれば取り残される者が出る。 **【事実】** Lorencは、PHP2Shellの件より前から、エンバーゴが守れるのは、審査して約束で縛れる相手の範囲までだと論じていた[^45]。 **【解釈】** エンバーゴの強さは、参加者のうち最も弱い一点で決まる。参加者が一人増えるたびに、漏洩の可能性は増える。CRA第14条のような当局への報告義務も、この観点から見れば「輪」に新たな参加者を加える仕組みであり、2023年の公開書簡が懸念したのはこの点である[^12]。 **【解釈】** Linuxカーネルのハードウェア脆弱性の手続きは、この両立しない要請への一つの回答である。案件ごとに参加者を決めたうえで、違反者を当該案件から即時に除外し、今後の案件からも除外するという強い規律で秘密を保とうとしている[^6]。 ### 5.4 誰を「身内」にするか **【解釈】** 5.3節の「輪の広さ」の問題をさらに遡ると、そもそも誰をエンバーゴの内側、すなわち「身内」に入れるべきかという問いに行き着く。この問いに統一された基準はない。各指針が示すのは原則までであり、実際の線引きは事例ごとの判断と失敗の積み重ねによって形づくられてきた。 #### 5.4.1 「身内」になり得る四つの層 **【解釈】** 本稿の事例を並べると、エンバーゴの内側に入る候補は、おおむね次の四つの層に分かれる。 | 層 | 入れる理由 | 入れなかった、または入れて失敗した例 | |---|---|---| | ① 修正を作る者（上流の開発者） | いなければ修正版ができない | ―（入れないという選択肢はない） | | ② 修正を配る者（ディストリビューター、下流のベンダー） | 公表と同時に利用者へ修正を届けるため | Meltdown / Spectre：オープンソースのOSが外に置かれ、主要ディストリビューターも互いに隔離された[^36][^37] | | ③ 先回りして守る者（セキュリティベンダー、重要インフラの事業者） | 検知シグネチャや緩和策を公表前に用意するため | Microsoft MAPPからの漏洩（下記）。PHP2Shellでは、重要インフラ事業者向けの緩和策も漏れた可能性がある[^3] | | ④ 当局 | 法律で義務づけられているため | Log4Shell：MIITが報告の遅れを問題にした[^29]。EUでもCRA第14条が当局への報告を義務づけた[^9] | **【事実】** ③の層の代表例が、Microsoftの「MAPP（Microsoft Active Protections Program）」である。これは、セキュリティベンダーに修正前の脆弱性情報を事前に渡し、公表と同時に検知や防御の仕組みを提供できるようにするプログラムである。 - 2012年、Windowsのリモートデスクトップの脆弱性（MS12-020）のPoCが、修正の公開から間もなくネット上に出回った。PoCにはMicrosoftが付けた目印が含まれており、流出がMicrosoftの内部かMAPP経由であることが示唆された。Microsoftはその後、MAPPの参加者だった中国のHangzhou DPTechが守秘義務に違反したと判断し、MAPPから除名した。DPTechを特定した方法は公表されていない。DPTech側の見解は、当時の報道では確認できなかった[^49]。 - 2025年7月、中国と結びつけられたSharePointへの大規模攻撃の後、Microsoftは、一部の中国企業にはMAPPを通じてPoCコードを提供しないと表明した。MAPPから情報が漏れたのではないかという見方が専門家の間で出ていたが、これは推測の段階にとどまる[^50]。 #### 5.4.2 線引きの四つの軸 **【解釈】** 事例から逆算すると、誰を「身内」に入れるかは、次の四つの問いで判断されていると整理できる。 1. **行動できるか**：公表前に情報を得ることで、利用者の被害を実際に減らせる相手か。①と②は明確に該当する。③は、何ができるかによって評価が分かれる 2. **拘束できるか**：守秘を約束させ、違反時に制裁を科せる相手か。Linuxカーネルのハードウェア脆弱性の手続きが、NDAの代わりに覚書を示して参加者にその遵守を誓約させ、違反者を将来にわたって除外するのは、この軸を制度にしたものである[^6] 3. **他の義務と衝突しないか**：その相手が、自国の法律などにより、第三者へ情報を渡す義務を負っていないか 4. **どこまで渡すか**：入れるか入れないかの二択ではなく、渡す情報の細かさや時期を変えられないか **【仮説】** 3の軸について、中国の規定は製品提供者に2日以内の当局への報告を義務づけている[^8]。こうした義務を負う者を輪に入れると、その者に悪意がなくても、法律上エンバーゴを守れない構造になり得る。ただし、Microsoftが2025年の制限の理由をこのように説明したわけではない。これは筆者の見立てである。同じ構造は、CRA第14条の報告義務を負うEU市場向けの製造者にも、程度の差はあれ当てはまる。 **【解釈】** 4の軸について、2025年のMicrosoftの対応として報じられたのは、一部の企業に「PoCは渡さない」という、渡す情報の細かさによる線引きだった[^50]。これは、輪の内と外という二択ではなく、輪の中を何層かに分けるという第三の道の実例と読める。 **【事実】** 一方、Linuxカーネルのハードウェア脆弱性の手続きは、輪の外に対しては、緩和策を公開の場で全員が同時に入手するとし、公開前に一部の者へ先に知らせる仕組みを設けていない。ただし輪の内側では、影響を受けるシリコンベンダーの代表が、カーネルチームに通知したうえで、いつでも自社の対応チームにパッチを渡せる[^6]。 **【解釈】** 両者を比べると、輪の外側に「公開前に知らされる準・身内」の層を設けるかどうかで、設計が対照的である。MAPPは、先回りして守る者に検知や防御を用意させるため、準・身内の層を意図的に設け、渡す情報の細かさで漏洩の危険を抑えようとしている。Linuxカーネルの手続きは、層を増やすこと自体を避け、輪の内側を規律で固めることで秘密を保とうとしている。5.3節で見た「輪の広さと秘密の強さ」のトレードオフに対して、前者は層を増やして情報を絞り、後者は層を増やさずに規律を強める、という異なる答えを出していると読める。 #### 5.4.3 原理的な限界 **【解釈】** ②の層には、原理的に全員を把握できないという限界がある。オープンソースは、誰がどこで再配布し、どの製品に組み込んでいるかを上流が知り得ない。そのため、輪は必ず不完全になる。輪を完全にしようとするよりも、短いエンバーゴと公表後の速やかな配布を組み合わせる方が現実的だという流れ（5.5節）は、この限界からも説明できる。 #### 5.4.4 輪の境界は、情報に付いていなければ守れない **【解釈】** PHP2Shellでは、情報は「提供者の提供者 → 提供者 → 投稿者」と、少なくとも三人を経て輪の外へ伝わり、その途中で「エンバーゴの対象である」という表示を失った[^56]。5.4.2節の四つの軸は、誰を輪に入れるかを決めるためのものである。しかしこの事例は、輪に入れた者がさらに先へ伝えるとき、どこまで伝えてよいかが情報とともに伝わらなければ、輪の境界は守れないことを示している。 **【事実】** こうした共有範囲の表示の仕組みとして、FIRSTの「TLP（Traffic Light Protocol）」がある。2022年8月から有効なバージョン2.0では、情報にRED、AMBER、AMBER+STRICT、GREEN、CLEARのいずれかの表示を付け、受け手は表示が許す範囲でのみ情報を共有できる。TLPに法的な拘束力はない[^58][^59]。 **【解釈】** TLPのような表示は、情報が人から人へ渡るたびに保たれなければ機能しない。PHP2Shellで最初に「エンバーゴはない」と伝えた人物が、どのような条件のもとで情報を受け取っていたのかは、公開情報からは分からない。ただ、表示が一度でも落ちれば、その先の受け手が善意で行動するほど、情報は広がる。輪の境界を守る仕組みは、情報の受け渡しのすべての段で、表示が保たれることを前提にしている。 ### 5.5 AIによる再発見の速さが、エンバーゴの前提を崩しつつある **【事実】** 2026年の事例には、同じ脆弱性が短期間に独立して発見される例が目立つ。 - PHP2Shellでは、CalifとOpenAIが同じ日に同じ根本原因を報告した[^3]。Chainguardも、示唆を受けてAIで再発見したと主張している。ただし、これは本人の主張であり、第三者の検証はない[^45] - Red Hatの暗号チームの開発者は、エンバーゴ期間中に同じ脆弱性の重複報告が届いたことを報告している[^35] **【事実】** これを受けて、エンバーゴの短縮に動く例が出ている。oss-securityでは、他者に再発見される前提でエンバーゴを短くすべきかが議論されている[^46]。CPANのセキュリティグループは、LLMによって発見が速まったことを理由に、既定のエンバーゴを28日から14日に短縮した[^47]。Linuxカーネルの現行の文書も、AIの支援で見つけたバグは公開されたものとして扱う旨を加えている。ただし、その場合も再現コードは公に共有しないとしている[^5]。GNOMEは、2026-08-01以降の報告について公表までの期間を90日から30日に短縮した[^48]。FIRSTの脆弱性調整SIGの共同議長であるArt Manionも、長期のエンバーゴがどれだけリスクを減らすのか考え直す必要がある、と述べている[^44]。 > reconsider the risk reduction value of long coordinated vulnerability disclosure embargoes > > （意訳）長期の協調開示エンバーゴがもたらすリスク低減の価値を再考する（必要がある）。 **【仮説】** エンバーゴの前提は、「秘密を保っている間は、攻撃者は知らない」という想定だった。AIで再発見の速さが上がるほど、この想定は成り立たなくなる。エンバーゴは「秘密を保つ期間」から、「関係者が足並みを揃えるための短い同期の時間」へと、性格を変えていく可能性がある。 **【仮説】** そうなると、希少な資源は「秘密」ではなく「修正する力」になる。PHP2Shellでは、根本原因の兆候が2024年に見つかっていながら、修正方針を決めきれずに停滞した。PHP Foundation自身がこれを「構造的な失敗」と呼び、意思決定の仕組みと資源の不足を原因に挙げている[^3]。エンバーゴをどれだけ厳密に運用しても、修正を作る側の力が足りなければ、守るべき時間そのものが生まれない。 ### 5.6 実務への示唆 **【解釈】** 以上から、脆弱性を受け付ける側（PSIRT）にとって、次の五点が示唆として得られる。 **（1）前倒しの条件と決定者を事前に合意する** 5.2節のとおり、対立の根は、検証できない状況で誰が判断するかが決まっていないことにある。この点で、Dirty Fragの発見者が取った手順は参考になる。発見者は、linux-distrosへの通知の時点で「第三者が攻撃コードを公開したら全面公開する」という条件を事前に合意していた[^33]。実際にその条件が満たされたとき、発見者はディストリビューターの同意を得て直ちに公開した。それでも、公開の経緯を問う声は出ており[^53]、事前合意だけで混乱を防げるわけではない。ただし、公開してよいかどうかをその場で争った記録は見当たらない。協調開示の方針に、前倒しの条件と、その判断を下す者を明記しておくべきである。 **（2）エンバーゴは破れるものとして準備する** エンバーゴを守れるかどうかは、自組織だけでは決められない。予定の公表日より前に、いつでも修正版と告知を出せる状態を整えておくことが、エンバーゴの有無にかかわらず被害を小さくする。 **（3）公開の場の開発と秘密保持の矛盾を自覚する** オープンソースを組み込んだ製品では、上流の修正が公開リポジトリに載った時点で、その脆弱性は公知になったものとして扱う必要がある。上流のエンバーゴ期間を、自社の修正に使える猶予と見なすことはできない。 **（4）「身内」の範囲と渡す情報を層ごとに決めておく** 5.4節のとおり、誰を輪に入れ、何を渡すかは、案件が起きてから考えると判断が遅れる。修正を配る相手、先回りして守る相手、当局のそれぞれについて、平時から「誰に、何を、いつ渡すか」を決めておくべきである。その際、各相手が他者へ情報を渡す義務を負っていないかも確認しておく。 **（5）共有する情報に範囲の表示を付け、受け手がさらに先へ伝える条件も伝える** 5.4.4節のとおり、輪の境界は情報そのものに付いていなければ守れない。事前に情報を渡すときは、TLPなどの表示を付け、受け手がさらに誰に伝えてよいかを明示しておく。口頭やチャットで伝える場合も同じである。 **【解釈】** 悪魔の代弁者として付け加えるなら、エンバーゴの短縮には限界もある。Meltdown / Spectre のように、マイクロコードやファームウェアの更新が必要なハードウェアの脆弱性では、修正に数か月を要する。ソフトウェアの脆弱性ではエンバーゴを短くし、ハードウェアの脆弱性では参加者の規律を強めて一定の期間を確保する、という使い分けが、二者択一ではない現実的な落としどころと考えられる。 ### 5.7 結び **【解釈】** エンバーゴは、関係者の好意と信頼の上に成り立つ、もともと脆い仕組みである。本稿で見た事例の多くは、誰かの悪意によってではなく、検証できない状況での判断の食い違い、表示を失った情報の善意の拡散、公開の場で開発するという構造、そして発見の速さの変化によって破られている。問われているのは「誰が破ったか」よりも、「破れることを前提に、どう備えるか」である。 --- ## 脚注 アクセス日は、脚注1〜54が 2026-10-23、脚注55〜59が 2026-10-24 である。一次情報のページに直接アクセスできなかったものは、その旨と確認経路を付記した。 [^1]: CERT/CC, "The CERT Guide to Coordinated Vulnerability Disclosure", CVD Recipes（"Vendor is unprepared for pending embargo expiration" および "Evidence of exploitation for an embargoed report" の項）. https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/cvd_recipes/ （旧URL https://vuls.cert.org/confluence/x/FIBcAw はサイト移転により到達不可） [^2]: FIRST, "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure" (v1.1). https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1 （PDF：https://www.first.org/global/sigs/vulnerability-coordination/multiparty/FIRST-Multiparty-Vulnerability-Coordination.pdf 。本文の確認は第三者のミラーで行った） [^3]: The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security", 2026-10-21. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ [^4]: Openwall, "distros mailing list". https://oss-security.openwall.org/wiki/mailing-lists/distros [^5]: The Linux Kernel documentation, "Security bugs". https://docs.kernel.org/process/security-bugs.html （現行版を https://www.kernel.org/doc/html/v7.2/process/security-bugs.html で確認） [^6]: The Linux Kernel documentation, "Embargoed hardware issues". https://docs.kernel.org/process/embargoed-hardware-issues.html （ミラーで内容を確認） [^7]: Google Project Zero, "Policy and Disclosure: 2021 Edition", 2021-04. https://projectzero.google/2021/04/policy-and-disclosure-2021-edition.html （旧URL：https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html ） [^8]: 国家互联网信息办公室「工业和信息化部 国家互联网信息办公室 公安部关于印发网络产品安全漏洞管理规定的通知」, 2021-07-13. https://www.cac.gov.cn/2021-07/13/c_1627761607640342.htm [^9]: Regulation (EU) 2024/2847 (Cyber Resilience Act). https://eur-lex.europa.eu/eli/reg/2024/2847/oj [^10]: ENISA, "Single Reporting Platform (SRP) – Frequently Asked Questions". https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions [^11]: Commission Delegated Regulation (EU) 2026/881. https://eur-lex.europa.eu/eli/reg_del/2026/881/oj （書誌情報のみ確認。本文は未確認） [^12]: "Joint letter of experts on CRA and vulnerability disclosure", 2023-10-03. https://www.rstreet.org/wp-content/uploads/2023/10/651c214af2fc7c6d29730d20_Joint-letter-of-experts-on-CRA-and-vulnerability-disclosure-20231003.pdf [^13]: CERT/CC, "The CERT Guide to Coordinated Vulnerability Disclosure", Intentional or Accidental Leaks. https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/leaks/ （2017年版の報告書 CMU/SEI-2017-SR-022 の6.4節にも同旨の記述がある：https://apps.dtic.mil/sti/tr/pdf/AD1046659.pdf 。旧URL https://vuls.cert.org/confluence/x/O4AeAw はサイト移転により到達不可） [^14]: D. Brumley, P. Poosankam, D. Song, J. Zheng, "Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications", IEEE Symposium on Security and Privacy, 2008. https://bitblaze.cs.berkeley.edu/apeg.html （論文：https://users.ece.cmu.edu/~dbrumley/pdf/Brumley%20et%20al._2008_Automatic%20Patch-Based%20Exploit%20Generation%20is%20Possible%20Techniques%20and%20Implications.pdf ） [^15]: Canonical, "CUPS Remote Code Execution Vulnerability fix available", 2024-09-26. https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available [^16]: Mathy Vanhoef, "Key Reinstallation Attacks" FAQ（OpenBSDに関する項）. https://www.krackattacks.com/#openbsd （メーリングリストの転載で内容を確認：https://lists.nycbug.org/pipermail/talk/2017-October/017307.html ） [^17]: Stefan Sperling（OpenBSD開発者）のLobstersへの投稿, 2017-10-16. https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz （転載で内容を確認：https://isopenbsdsecu.re/mitigations/embargoes_handling/ ） [^18]: OpenBSD 6.0 errata 041 / 6.1 errata 027, "net80211_replay", 2017-08-30. https://www.openbsd.org/errata60.html#p041_net80211_replay ／ https://www.openbsd.org/errata61.html#p027_net80211_replay [^19]: Google Security Blog, "Today's CPU vulnerability: what you need to know", 2018-01-03. https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html （報告日は Project Zero の投稿による：https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html ） [^20]: Tom Lendacky, "[PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors", LKML, 2017-12-26. https://lkml.iu.edu/hypermail/linux/kernel/1712.3/00675.html （本人による 2017-12-27 の返信：https://lkml.iu.edu/hypermail/linux/kernel/1712.3/00820.html ） [^21]: The Register, "'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign", 2018-01-02（報道）. https://www.theregister.com/2018/01/02/intel_cpu_design_flaw/ [^22]: Intel, "Intel Holds Investor Call Regarding Security Research Findings", 2018-01-03（同ページに声明本文を収録）. https://www.intc.com/news-events/press-releases/detail/185/intel-holds-investor-call-regarding-security-research [^23]: FreeBSD Project, News Flash, 2018-01-04. https://www.freebsd.org/news/newsflash/#event20180104:01 [^24]: Apache Log4j, "Security". https://logging.apache.org/log4j/2.x/security.html [^25]: apache/logging-log4j2, Pull Request #608 "Restrict LDAP access via JNDI". https://github.com/apache/logging-log4j2/pull/608 [^26]: Cloudflare, "Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration", 2021-12-14. https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns （CEO Matthew Prince のX投稿：https://twitter.com/eastdakota/status/1469800951351427073 ） [^27]: @P0rZ9 のX投稿, 2021-12-09（Internet Archive）. https://web.archive.org/web/20211211082351/https://twitter.com/P0rZ9/status/1468949890571337731 [^28]: The Apache Software Foundation, "Apache Software Foundation Security Report: 2021". https://news.apache.org/foundation/entry/apache-software-foundation-security-report2 [^29]: 21世纪经济报道, 2021-12-23（報道。MIITの原文書は確認できなかった）. https://www.sfccn.com/2021/12-23/zMMDE0MDdfMTY4NzAzMQ.html （同旨の報道：中国日报网, 2021-12-22. https://cn.chinadaily.com.cn/a/202112/22/WS61c2c21aa3107be4979fe588.html ） [^30]: Simone Margaritelli, "Attacking UNIX Systems via CUPS, Part I", 2024-09-26. https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ [^31]: OpenPrinting, "OpenPrinting News Flash: cups-browsed Remote Code Execution vulnerability", 2024-09-29. https://openprinting.github.io/OpenPrinting-News-Flash-cups-browsed-Remote-Code-Execution-vulnerability/ [^32]: Solar Designer, oss-security, 2024-09-26. https://www.openwall.com/lists/oss-security/2024/09/26/5 [^33]: Hyunwoo Kim, "Dirty Frag" write-up. https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md [^34]: Hyunwoo Kim, oss-security, 2026-05-07. https://www.openwall.com/lists/oss-security/2026/05/07/8 （ミラー：https://seclists.org/oss-sec/2026/q2/430 ） [^35]: LWN.net, "LLM-driven security reports disrupt coordinated disclosure", 2026-05-06（報道）. https://lwn.net/Articles/1070698/ [^36]: iTWire, "Handling of CPU bug disclosure 'incredibly bad': OpenBSD's de Raadt", 2018-01（報道）. https://itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html [^37]: eWeek, "Linux Kernel Developer Criticizes Intel for Meltdown, Spectre Response", 2018-08-30（報道）. https://www.eweek.com/de/security/linux-kernel-developer-criticizes-intel-for-meltdown-spectre-response/ [^38]: IT之家, 阿里云声明の報道, 2021-12-23（報道。声明の原文は未確認）. https://www.ithome.com/0/594/373.htm [^39]: Red Hat, "RHSB-2024-002 OpenPrinting cups-browsed and libcupsfilters". https://access.redhat.com/security/vulnerabilities/RHSB-2024-002 [^40]: oss-security, "Copy Fail 2 / Dirty Frag — n-day from public commit, not embargo break", 2026-05-07. https://seclists.org/oss-sec/2026/q2/434 [^41]: Sam James（Gentoo）, oss-security, 2026-05-08. https://seclists.org/oss-sec/2026/q2/447 [^42]: The New Stack, "PHP's security scramble is just a preview: AI is digging up flaws faster than maintainers can fix them", 2026-10（報道）. https://thenewstack.io/php2shell-ai-vulnerabilities-maintainers/ [^43]: Dan Lorenc（Chainguard CEO, アカウント名 dlor）のHacker Newsへのコメント, 2026-10. https://news.ycombinator.com/item?id=50176735 [^44]: TechTarget, "PHP2Shell disclosure unravels after leaks forced early patch drop", 2026-10（報道）. https://www.techtarget.com/cybersecurity/news/366652613/PHP2Shell-disclosure-unravels-after-leaks-forced-early-patch-drop [^45]: Socket, "PHP Foundation Says Chainguard Broke Security Embargo Ahead of Emergency Patches", 2026-10（報道）. https://socket.dev/blog/php-embargo-dispute [^46]: Jeremy Stanley, oss-security, "Coordinated Disclosure in the LLM Age", 2026-04-28. https://seclists.org/oss-sec/2026/q2/250 [^47]: CPAN Security Group, "CPANSec Has Revised Our Default Disclosure Dates", 2026-07-15. https://security.metacpan.org/2026/07/15/revised-disclosure-delay.html [^48]: Michael Catanzaro, "Some changes to GNOME security tracking", 2026-07-20. https://blogs.gnome.org/mcatanzaro/2026/07/20/some-changes-to-gnome-security-tracking/ [^49]: SecurityWeek, "Microsoft Drops Chinese Vendor From MAPP After NDA Violations", 2012-05-04（報道。Microsoftの声明は同記事の引用による）. https://www.securityweek.com/microsoft-drops-chinese-vendor-mapp-after-nda-violations/ [^50]: CSO Online, "Microsoft restricts Chinese firms' access to vulnerability warnings after hacking concerns", 2025-08-21（報道。Microsoftの表明はReutersの報道を引用）. https://www.csoonline.com/article/4043683/microsoft-restricts-chinese-firms-access-to-vulnerability-warnings-after-hacking-concerns.html [^51]: Hyunwoo Kim, "Dirty Frag" README. https://github.com/V4bel/dirtyfrag [^52]: The Register, "PHP blames supply chain security biz Chainguard for putting huge chunks of the web at risk", 2026-10-22（報道）. https://www.theregister.com/security/2026/10/22/php-blames-supply-chain-security-biz-chainguard-for-putting-huge-chunks-of-the-web-at-risk/5304611 [^53]: Sandipan Roy（Red Hat）, oss-security への返信, 2026-05-07. https://seclists.org/oss-sec/2026/q2/432 [^54]: Piotr Karwasz（ASF VP Logging）, "What if Log4Shell were to happen today?", FOSDEM 2025 講演資料. https://fosdem.org/2025/events/attachments/fosdem-2025-6281-what-if-log4shell-were-to-happen-today-/slides/237090/What_if_L_2aUBQo9.pdf [^55]: petecooper, "Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming", Hacker News, 2026-10-20. https://news.ycombinator.com/item?id=50167754 [^56]: petecooper, "Tell HN: I unknowingly broke the PHP RCE embargo. I am sorry", Hacker News, 2026-10-22. https://news.ycombinator.com/item?id=50193416 [^57]: GIGAZINE, 「PHPの脆弱性をHacker Newsにリークした人物が「秘密だと知らなかった」と謝罪」, 2026-10-23（報道）. https://gigazine.net/news/20261023-php-rce-unknowingly/ （Hacker News上の返信：Xでの拡散に関するもの https://news.ycombinator.com/item?id=50175564 、擁護 https://news.ycombinator.com/item?id=50193835 。投稿者の立場について同旨の報道：Tom's Hardware, 2026-10-23. https://www.tomshardware.com/tech-industry/cyber-security/devastated-forum-user-who-accidentally-broke-the-php-news-embargo-comes-clean-user-says-they-were-unaware-of-disclosure-restrictions-move-clearly-backfired-in-a-pretty-wild-fashion ） [^58]: FIRST, "Traffic Light Protocol (TLP): FIRST Standards Definitions and Usage Guidance — Version 2.0". https://www.first.org/tlp （ページは取得できず、脚注59で内容を確認） [^59]: CERT-EU, "New Traffic Light Protocol: New definitions and updated restrictions". https://www.cert.europa.eu/blog/tlp-version-2-primer