exploitarium:匿名の「bikini」が AI 自動ファジングで見つけた多数のゼロデイ PoC を一括公開し、報告の来歴・真正性を受け手が検証できない

Vulnpocalypse の具体例

事案日
2026-06-29
公開日
2026-07-01
発行
Lemma Critical Team
関連 Pack
Pack CAgent Governance

TL;DR

pseudonym「bikini」を名乗る研究者が、libssh2・curl・PHP・FFmpeg・Firefox・Ghidra・nmap・OpenVPN・VLC・RustDesk 等を対象とするゼロデイの PoC を、GitHub リポジトリ exploitarium にベンダー無通知で一括公開した(本 Brief 作成時点で公開中・スター3000超・約26の PoC フォルダ)。本人は README で「ファジングを AI(GPT-5.3-Codex-Spark)で自動化したが、PoC は RustDesk を除きすべて手書きで、good-faith な公開開示だ」と述べる。うち libssh2 の認証前リモートコード実行(CVE-2026-55200)は NVD 掲載・独立検証で高リスクと確認され、発見群には CVE-2026-58049〜58058 が採番された。一方、影響の小さいものも混在し、防御側は本物と低価値を選別する必要がある。ここでの落差は、CVE 採番という検出は機能したのに、その報告が「誰の・どのような発見に由来し、実在する脆弱性か」という来歴・真正性を、受け手が暗号的に検証できない点にある。AI がファジング=発見のコストを崩すと、玉石混交の報告が量として triage を圧迫する。これは新語ではなく、既に語られる「Vulnpocalypse」の具体例である。検出と事前証明は代替ではなく補完である。


事案概要

  • 公開主体: pseudonym「bikini」。GitHub リポジトリ exploitarium。本 Brief 作成時点で公開中(スター3000超・フォーク900超・約26の PoC フォルダ・当日も更新)。The Register は「GitHub により削除された」と報じたが、現時点でアクセス可能(削除後に復活したか要追跡)。本人は学位と複数のファジング論文があると主張し、good-faith の open-disclosure と位置づける
  • 公開物(実際の repo に基づく): 約26の自己完結 PoC フォルダ。対象に 7-Zip・AnyDesk・c-ares・curl・Docker・FFmpeg・Firefox・Floci・Flowise・Ghidra・Gitea(act runner の container options)・ImageMagick・libarchive・libssh2(2件)・Lunar/Modrinth・MyBB・Next.js・nghttp2・nmap・objdump・OpenVPN・PHP・RustDesk・SystemInformer・VLC 等。Splunk は含まれない(The Register 等のリストと差異あり)。件数は「15/22/100+」と報じられたが、repo 実測は約26 PoC
  • 公開態様: いずれのベンダーにも事前通知せず、対価もクレジットも求めず一括投下(責任ある協調的開示のプロセスを踏まない、匿名の一括公開)
  • 発見手法(本人 README・一次): ファジングのワークフローを AI(GPT-5.3-Codex-Spark)で自動化。ただし PoC は RustDesk を除きすべて手書き(RustDesk のみ AI 補助)、README のみ AI 生成。すなわち「AI が脆弱性を生成した」のではなく、AI 自動ファジング+人手 PoC である
  • 採番・独立検証で高リスクと確認された標的:
    • CVE-2026-55200(libssh2): 認証前リモートコード実行(CVSS: NIST 8.3 High/VulnCheck 9.2 Critical)。ssh2_transport_read()packet_length の上限を強制せず、過大な値を持つ SSH パケットで境界外書き込み(ヒープ破損)を起こし RCE 可能。1.11.1 までの全バージョンが影響し、libssh2 は curl・Git・PHP 等の下層にあるため影響範囲が広い。修正コミットは mainline にマージ済み、リリース準備中。NVD の悪用状況は PoC 公開段階(SSVC: poc)
    • repo の発見群には CVE-2026-58049〜58058 が採番された(cves.md
  • 来歴上の誤りに注意(The Register の混同): 一部報道は Gitea の認証バイパス CVE-2026-20896REVERSE_PROXY_TRUSTED_PROXIES = * 既定・X-WEBAUTH-USER ヘッダで乗っ取り、CVSS 9.8、Gitea 1.26.3 で修正)を exploitarium 由来として扱ったが、repo の Gitea エントリは gitea-act-runner-container-options-poc(act runner の container options)であり、CVE-2026-20896 とは別である。CVE-2026-20896 は Gitea 自身の別の security release で修正されたもので、exploitarium には含まれない
  • 核心: 脆弱性報告に「発見の来歴・真正性を受け手が検証できる証明」が伴わないため、受け手は本物の高リスクと低価値の発見を暗号的に区別できず、全件を人手・独立検証に回すコストが発生する。AI が発見の量を人手の検証能力を超えて押し上げると、この構造が破綻する

タイムライン

  • 2026-06 前半: Gitea が自身の security release(1.26.3/1.26.4、6/20)で CVE-2026-20896 を修正(exploitarium とは別経路)
  • 2026-06-23 頃: bikini が exploitarium に PoC をベンダー無通知で公開(第三者の検知ルール archive が公開日として言及)
  • 2026-06-29: The Register が報道。少なくとも2件の高リスクな脆弱性を伝える(ただし Gitea の扱いに混同の疑い。§1 参照)
  • 2026-06-30: 日本語メディア(Codebook)が邦訳・解説を公開
  • 2026-07-01(本 Brief 作成時点): exploitarium は公開中で更新継続(本人は「以後は概ね1日1 PoC」と告知)。GitHub による一時削除の有無・時期は要追跡

注: 本事案は当初、削除済みリポジトリに関する報道が中心だったが、一次確認では repo は公開中で内容を直接検証できる。独立に確認されているのは、exploitarium の存在と内容・ベンダー無通知の一括公開、本人 README の記述(AI 自動ファジング+手書き PoC、GPT-5.3-Codex-Spark)、libssh2 CVE-2026-55200(NVD 掲載・認証前 RCE・PoC 公開)、および repo 発見群への CVE-2026-58049〜58058 の採番である。独立に確認されていない/諸説ある/訂正したのは、公開総数(報道の「15/22/100+」は repo 実測≈26 と不一致)、投下物の一覧(Splunk は含まれず、多数の対象が報道リストから欠落)、Gitea 認証バイパス CVE-2026-20896 を exploitarium 由来とする扱い(別 release の混同)である。悪用状況も、The Register は Ethan Andrews 氏の観察を根拠に「active exploitation」と報じるが、NVD の libssh2 は SSVC: poc(PoC 段階・未観察)で、両者は一致しない。固有名・CVE・数値は一次(repo/NVD/各プロジェクト公式)を基準に最新を参照されたい。誇張しない。


事象ベクター(証明の無い大量投下)

  1. AI 自動ファジングで発見を量産: bikini が AI(GPT-5.3-Codex-Spark)で駆動する strict harness により、多数の製品・OSS の脆弱性候補を効率的に見つける(発見の自動化。PoC 自体は人手で書いたと本人は述べる)
  2. 匿名・無通知の一括公開: 約26の PoC を exploitarium に、ベンダー通知も対価もクレジット要求もなく一括投下する
  3. 発見の来歴が受け手に検証できない: 本人 README は手法を自己申告するが、各報告が「誰の・どの手法による発見で、実在するか」を受け手が暗号的に検証できる証明は無い。高価値・低価値(本物・ノイズ)が混在する
  4. 受け手が全件を独立検証する羽目になる: 防御側・各プロジェクトは、報告の真正性を自分で確かめるほかなく、約26件を人手・独立検証のトリアージに回さざるを得ない
  5. 一部が高リスクと確認される: 独立検証で libssh2(CVE-2026-55200)等が高リスクと確認され、発見群に CVE-2026-58049〜58058 が採番される一方、影響の小さいものも混在する
  6. 悪用可能な脆弱性が公開情報として拡散: 悪用可能なものがパッチ提供前に公開情報(PoC 付き)として広まり、パッチ適用前の窓が開く

AI がファジング=発見のコストを崩すと、この「玉石混交の報告」を大量に生成でき、防御側の triage 帯域が量として圧迫される。これは新語ではなく、既に Vulnpocalypse(脆弱性の黙示録) として語られる現象(Axios が 2026-05 に AI 脆弱性発見の文脈で使用)の具体例である。


構造的論点

本事案は Pillar 01(来歴証明)の code-provenance カテゴリに属する。ただし来歴の対象は成果物としてのコードだけでなく、**「脆弱性ディスクロージャ(報告・主張)の来歴・真正性」**にまで及ぶ。中心的な失敗 primitive は、脆弱性報告が「誰の・どの手法による発見で、実在するのか」という発見の来歴に、受け手が検証可能な形で結び付いていない点にある。CVE 採番という検出は存在するが、それは「その報告が本物の発見に由来する」ことの、受け手が独立に確かめられる証跡にはならない。本人が README で手法を自己申告しても、それは受け手が暗号的に検証できる証明ではない。AI が発見コストを崩すと、玉石混交の報告が防御側の検証帯域を量で圧迫する。

本事案は、AI の攻撃能力が防御側の処理能力を非対称に上回る一連の Brief と連なる。Brief No.018(HackerBot/Claw、初期の AI 対 AI の攻防で、攻撃側の自動化が防御の前提を崩した)と Brief No.009(GTG-1002、AI が攻撃工程の大半を自律実行した)は、いずれも AI 攻撃能力の非対称化 という点で本件と同型である。匿名の pseudonym による大量投下で発見主体の同一性が受け手に検証できない点は、Brief No.082(xz-utils、信頼された開発者へのなりすましでバックドアが持ち込まれた)や Brief No.015(GitHub 経由の内部リポジトリ/拡張の侵害)の 来歴/なりすまし 系列に接続する。いずれも、主張や成果物の「出所・発見の来歴」が受け手に独立検証されないまま、信頼または処理を強いられた

secondary に、AI による発見の自動大量生成が防御側の triage を量で圧迫する点で agent-runaway(AI 攻撃能力の暴走的スケール)、pseudonym で発見主体の同一性が受け手に検証不能な点で identity-auth を併記する。CVE 採番や独立検証のような検出は前提として重要だが、報告が「検証可能な発見来歴を持つか」を受け手が事前に確かめられて初めて、限られた検証帯域を本物の高リスクに集中できる。


検出と証明の落差

libssh2 の認証前 RCE(CVE-2026-55200)が NVD 掲載・独立検証で高リスクと確認され、発見群に CVE-2026-58049〜58058 が採番され、影響プロジェクトが修正を進めたことは、被害の把握と是正に不可欠であり、本 Brief がその役割を否定するものではない。検知・採番・パッチのプロセスは、少なくとも標的の一部については機能した。検出は確かに機能した。

一方で、CVE 採番や事後の独立検証は、「その報告が誰の・どのような発見に由来し、実在する脆弱性か」を、受け手が事が起きる前に暗号的に立証する材料にはならない。本事案では、公開された報告に受け手が検証できる発見来歴の証明が伴わないため、防御側は玉石混交の約26件を、全件自分で独立検証するほかなかった。欠けていたのは「この報告は、検証可能な発見来歴を持つか」を受け手が事前に独立検証できる層であり、これは事後の CVE 検証とは別系統の検証である。AI が報告の量を人手の検証能力を超えて押し上げると、このコストはスケールしない。

事前証明(pre-execution attestation)は、脆弱性報告に「発見主体・発見手法・対象の同一性」の来歴を、受け手が独立検証可能な形で結び付ける。証明付きの報告と、証明の無い匿名投下とを機械的に区別できれば、防御側は独立検証の帯域を本物の高リスクに集中し、玉石混交の中から信号を分離できる。事後の検証(detection 的な「これは実在した/しなかった」)と、報告の発見来歴の事前証明(「この報告は検証可能な発見に由来する」)を切り離さず、両者が重なって初めて、AI が発見コストを崩す世界で防御側の triage が成立する。検出と事前証明は代替ではなく 補完 の関係にある。

事後の検知が証明にならない論点は 「AI 時代のサイバー防衛に残された、最後の層」(Lemma、2026-05)、行動・処理の前に独立検証する設計は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」(Lemma、2026-05)を参照。


対応経緯と業界動向

  • 影響製品の対応: libssh2 は修正を mainline にマージしリリースを準備。curl・Git・PHP 等 libssh2 を下層に持つ広範なコンポーネントの利用者はパッチ状況の確認が要る。Gitea の CVE-2026-20896(本件とは別の認証バイパス)は 1.26.3 で修正済み。各対象の修正対応は repo・各プロジェクト公式で確認されたい
  • 開示プロセスの論点: ベンダー無通知の一括公開は、協調的開示(coordinated disclosure)の前提を踏まないため、パッチ提供前に悪用可能情報が拡散する。本人は good-faith の open-disclosure と主張するが、受け手にとっては真正性の検証コストが残る
  • 採用の問題(本事案の核心的な空白): 来歴証明を自発的に付すのは、既に協調的開示を実践する責任ある研究者であり、匿名で無差別に一括投下する者には付す動機が無い。最も証明を要するアクターが、最も使わない。したがって処方箋は次の二方向のいずれか(または両方)に整理される——
    • A(強制・供給側): 検証可能な発見来歴を CVE 受理の前提条件に組み込む(CVE Board/CNA の規則変更を提唱)。強制力はあるが標準化の政治的ハードルが高い
    • B(運用・受け手側): 来歴証明の無い報告の triage 優先度を制度的に下げる。強制力は無いが今すぐ実装可能
  • 業界横断の論点: AI による脆弱性発見の自動化が進むと、報告の「量」が人手の検証能力を超え、防御側の triage が玉石混交の中で圧迫される。これは特定の一投下の問題ではなく、脆弱性ディスクロージャに受け手が検証できる真正性が伴わないという、エコシステム横断の運用課題である

Lemma による分析

本事案で露呈した検出と証明の落差(脆弱性報告が検証可能な発見来歴を持つかを、受け手が事前に独立検証できない)に対し、Lemma は以下の設計を提示する。なお本件は個別インシデントというより、AI がファジング=発見を安価にする時代の具体例であり、事実の未確認性と本人 README の自己申告性を踏まえて位置づける必要がある。

  • 報告の発見来歴の証明: 脆弱性ディスクロージャに「発見主体・発見手法・対象の同一性」の来歴を、受け手が独立検証可能な証明として結び付ける。成果物だけでなく「報告・主張」にも検証可能な出所を与える
  • 証明の無い投下の分離: 証明付きの報告と、証明の無い匿名の大量投下とを機械的に区別し、防御側が独立検証の帯域を本物の高リスクに集中できるようにする。上記 B(受け手側の triage 降格)を、暗号的な根拠の上で運用可能にする
  • 受理要件への接続: 上記 A(CVE 受理の前提条件化)を採るなら、Lemma の来歴証明は CNA が要求できる検証可能プリミティブとして機能しうる
  • 選択的開示: 発見手法や内部情報の全開示を求めず、「この報告は検証可能な発見来歴を持つ」ことだけを最小開示で証明する

検出(CVE 採番・事後の独立検証)は個々の脆弱性の実在確認に、事前証明(報告の発見来歴の受け手による独立検証)は玉石混交からの信号分離に、それぞれ相補的に働く。AI が発見コストを崩す世界で防御側が生き残る条件は、より速い検出ではなく、報告の真正性を受け手が証明可能にすることにある。設計と適用範囲は Pillar 01 — 来歴証明 および Seal を参照のこと。


Sources


Brief 配布について

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。


(c) 2026 FRAME00, INC. — Built for decisions that matter.

Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"exploitarium:匿名の「bikini」が AI 自動ファジングで見つけた多数のゼロデイ PoC を一括公開し、報告の来歴・真正性を受け手が検証できない — Vulnpocalypse の具体例".
Lemma Critical Brief No.092. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/092-exploitarium-disclosure-provenance/