Exploitariumは、GitHub上で公開されている脆弱性研究とPoCの統合アーカイブです。READMEは、自分の公開PoCと脆弱性調査メモをまとめたものだと説明し、過去の単独リポジトリをフォルダとして保存し、新しい調査は自己完結したフォルダとして追加すると書いています。対象名の一覧には、7-Zip、c-ares、Docker、FFmpeg、Firefox、libssh2、Redis、VLCなど、広く使われるプロジェクトが並びます。(GitHub, README)
このリポジトリが気になるのは、PoCが多いからだけではありません。READMEには、ファジングのワークフローにAIを使ったこと、PoC自体は主に手で書いたこと、README群はAIで整形したことが書かれています。つまり、脆弱性探索、コード、説明文、公開場所が一つのGitHubリポジトリに寄せられている。そこに、いまのセキュリティ研究の速さと危うさがそのまま出ています。
アーカイブとしては整理されている
Exploitariumの構成は、雑にファイルを投げ込んだだけの置き場ではありません。READMEのContentsにはフォルダ名、由来、tracked entriesが表で並び、旧単独リポジトリから移したものについては、Gitのtreeやblob IDを使って内容の一致を確認したと説明されています。12個の旧リポジトリ、96件のtracked entriesについて不一致なし、という記述もあります。(README)
ただ、整理されていることと、公開の仕方が安全であることは別です。リポジトリ自身は「悪用するな」と書いていますが、PoCは本来、検証者、ベンダー、利用者、調整者が同じ時間軸で読めるとは限りません。修正前の利用者が先に危険へ晒されるなら、きれいなREADMEは防波堤になりません。
報道は、未検証の主張として扱っている
The Registerは、匿名の研究者が複数の製品・OSSプロジェクトにまたがるゼロデイ脆弱性のエクスプロイトコードと書き込みを、事前の通知なしに公開したと報じています。同記事は、少なくとも2件がすでに攻撃に使われているとも書いていますが、同時に、コードが動作するか、主張が正しいかは検証していないと明記しています。(The Register)
ここは読み落としたくないところです。公開リポジトリ、強いタイトル、具体的な対象名が揃うと、それだけで「確認済みの危機」に見えます。でも、脆弱性情報は再現性、影響範囲、修正状況、回避策が揃って初めて運用判断に使えます。未検証のPoC集は、警報であると同時にノイズにもなります。
CVDは、公開前後の交通整理まで含む
CERT/CCのCVDガイドは、協調的脆弱性開示を、発見者から情報を集め、関係者間で共有を調整し、脆弱性と緩和策を公表するプロセスとして説明しています。FIRSTのmulti-party CVDガイドも、OSS、サプライチェーン、複数ベンダーが絡む場面では、二者間の報告だけでは足りないと見ています。(CERT/CC, FIRST)
Exploitariumは、このプロセスの外側にある公開です。研究成果を隠せと言いたいわけではありません。けれど、PoC、対象名、AI支援の作業速度、GitHubの拡散力が重なると、開示は「知る権利」だけでは済まなくなります。読む側に必要なのは、PoCをすぐ動かす反射ではなく、ベンダーの修正状況、CVEやアドバイザリ、影響する構成、緩和策を切り分ける目線です。
Exploitariumを見るなら、攻撃手順のカタログとしてではなく、協調のない公開がどこで危険に変わるかを考える材料として扱うのがよさそうです。脆弱性情報は早いほどいい、とは限りません。誰が直せるのか、誰が先に知るべきか、利用者が何を判断できる状態で公開されるのか。そこを抜かすと、研究の熱はすぐに別の火種になります。