- Opus 4.5とGPT-5.2ベースのエージェントがQuickJSのゼロデイ脆弱性を利用し、6つのシナリオで40件以上のエクスプロイトを生成
- GPT-5.2はすべての課題を解決し、Opus 4.5は2件を除くすべての課題を解決して、自律的なコード分析・デバッグ・エクスプロイトチェーン構成能力を示した
- 実験結果は、エクスプロイト開発が人間ハッカーの数ではなくトークン処理量によって制約される可能性を示している
- 脆弱性検出とエクスプロイト生成は、すでにトークン投入量に比例して成果が増加する段階に到達
- 今後はサイバー攻撃の自動化とセキュリティ評価体系の再整備の必要性が強調される
実験概要
- Opus 4.5とGPT-5.2を用いて、QuickJS JavaScriptインタプリタのゼロデイ脆弱性を対象としたエクスプロイト生成実験を実施
- 各種エクスプロイト緩和技法（ASLR, NX, RELRO, CFI, シャドースタック, seccomp など）を適用
- エージェントはシェル生成、ファイル書き込み、C2接続など複数の目標を達成
- GPT-5.2はすべてのシナリオを解決し、Opus 4.5は2件を除くすべての課題を解決
- 各実行は最大3,000万トークン制限、約30ドルのコスト
- 最も難しい課題では5,000万トークン、約3時間、50ドルのコストで解決
- GPT-5.2はseccompサンドボックスとシャドースタックが有効な環境で、glibcのexitハンドラチェーンを利用した7段階の関数呼び出しによりファイル書き込みエクスプロイトを完成
実験の限界
- QuickJSは実際のブラウザエンジンより規模と複雑さがはるかに小さいため、結果の一般化には限界がある
- 生成されたエクスプロイトは、保護技法そのものの新たな脆弱性を発見したものではなく、既知のデプロイ上の弱点を利用している
- QuickJSの脆弱性自体は新たに発見されたものであり、GPT-5.2の解決方法は従来文書化されていない新しいチェーン構成と評価される
侵入の産業化
- 「産業化」とは、組織の攻撃能力が人員数ではなくトークン処理量によって決まる状態を意味する
- そのために必要な条件は2つ
- LLMベースのエージェントが環境内を自律的に探索できること
- 正確で高速な検証システムが存在すること
- エクスプロイト開発は、こうした条件を満たす理想的な事例
- 環境構築が容易で、検証手順が明確
- 例: シェル生成エクスプロイトの場合、ポートリスナーを通じて接続成功の可否を検証できる
- 一方で、リアルタイム相互作用が必要な侵入・権限昇格・持続的アクセス維持・データ窃取などは産業化がより難しい
- 実環境での誤った挙動が検知につながる可能性があるため
現在の段階
- 脆弱性検出とエクスプロイト開発は、すでにトークン投入量に比例して成果が増加
- OpenAIのAardvarkプロジェクトでも同様の傾向が確認されている
- 実験でも限界は予算であり、モデル性能ではなかった
- 実ネットワーク内でのハッキング自動化はまだ不確実
- Anthropicの報告によれば、中国のハッキングチームがAPIを利用して攻撃を試みた事例が存在
- しかし完全自動化された**SRE（サイト信頼性エンジニアリング）**エージェントが商用化された事例はない
- SRE自動化が成功すれば、敵対的ネットワーク内での自動化ハッキングも可能になる可能性が高い
結論と提言
- 今回の実験は、サイバー領域における自動化可能性の範囲と時期に関する認識を変える
- 現在のモデル評価方式（CTF、旧式脆弱性、合成データ）は、実際のゼロデイ攻撃能力を測定するには不適切
- フロンティア研究所とAIセキュリティ機関は、実際のゼロデイ対象（例: Linuxカーネル、Firefox）に対する評価を行うべき
- 「X億トークンを使ってY件のエクスプロイトを生成した」という形式の公開報告が必要
- IoTファームウェアなど実機を対象にした評価も必要
- Opus 4.5やGPT-5.2ベースのエージェントにより、1週間以内に実用的なエクスプロイトを生成できる可能性が示された
- 研究者とエンジニアには、自ら実験を行い、結果を公開することが推奨される
- 実験用コードとデータはGitHubリポジトリで公開されている
1件のコメント
Hacker Newsのコメント
GPT‑5.2に最も難しい課題として、ディスク上の特定のパスに文字列を書き込む方法を見つけさせた。
ASLR、実行不可メモリ、full RELRO、細粒度CFI、ハードウェアshadow‑stack、seccompサンドボックスなど、あらゆる保護が有効なQuickJS環境だった。
GPT‑5.2はglibcのexit handlerチェーンを利用し、7段階の関数呼び出しで問題を解決した。本当に驚くべき結果だった
実際のエクスプロイトの大半は「脆弱性を見つける（難しい）」の後に「役に立たない緩和策を何層も突破する（面倒だが可能）」という順序で進む。
確率的な緩和策は確率的な攻撃には効くが、攻撃者は意図的に弱点を探し出す
将来、なぜもっと早くWASMへ移行しなかったのか後悔することになりそうだ。
それまでは、古いスタック上書き問題にしがみつきながら、ハードウェア緩和策を継ぎはぎしていくのだろう
これが自分の仕事なのでよく分かるが、だんだん無力感が強くなっている
Use‑After‑Freeでlibcポインタをリークするような話だ。
Rustならかなり難しくなるだろうが、libc呼び出しが多ければ完全防御は難しい
GPT‑5.2のエクスプロイトは緩和策そのものを新たに破ったのではなく、既知の実装上の隙を使ったものだ。
人間のハッカーも同じで、緩和策自体を新しく破るわけではない。
ただ、CTF分野ではLLMがすでにワンショットでpwn問題を解くケースが増えている。
こうした進歩によって不完全な緩和実装が崩れ、形式的エクスプロイトモデリングの研究が促進されそうだ
セキュリティ研究者の立場から見ると、LLMが作ったread/write primitive APIは既存APIを単純に再構成した程度だ。
新技術というより、CTF向けのおもちゃバイナリに近い。
ただし最新のOpenAIモデルは実際のエクスプロイトコードを生成したがらない傾向があるので、プロンプト回避が使われたのか気になる
著者は興味深い点を突いているが、私はそこまで心配していない。
こうしたツールは防御側でも対称的に活用できる。
CI段階で「LLM Red Team」を回すように、自動セキュリティテストを追加できるはずだ
攻撃者は一度成功すればよいが、防御側は常に成功しなければならない。
現在のモデルはpass@x性能がmaj@xより20〜30%高い。
それでもRed vs Blueループを回せば、セキュリティ水準は改善するだろう
攻撃者はたった1つの失敗を見つければよく、防御側はすべてを防がなければならない
例: Google Project ZeroのBig Sleepプロジェクト
関連脆弱性の一覧はここで見られる
攻撃者は1つのバグを見つけるだけで武器化できるが、防御側はすべてのバグを見つけなければならない。
「any vs all」の非対称構造だ
結局、LLM企業だけが真の勝者となって、両陣営にトークンを売ることになる
Codex 5.2が最も複雑なエクスプロイトを見つけた点は興味深い。
私も主にOpus 4.5を使っているが、Codex 5.2のExtra High thinkingモードは確かに強力だ。
LLMの進歩が鈍化したという話は信じていない。むしろ課題が難しすぎるようになって、体感しにくくなっただけだ
ログはこのリポジトリで確認できる
それぞれスタイルが異なる
商業的価値がなくなるまで公開されない
QuickJSはもともと未修正の脆弱性が多いおもちゃプロジェクトだ。
curlのような実戦的ターゲットでのエクスプロイトの方が面白いだろう
LLMが優れたエクスプロイトを書くという主張と、役に立たないバグレポートを出すという主張が共存している。
両方とも本当なのだろうか?
LLMの品質はユーザープロンプトと解釈能力によって変わる。
専門家が選別的に活用すれば、優れた結果を得られる
自動生成されたレポートはメンテナに大きな負担をかける
単に「このプログラムの脆弱性を見つけて」と言うとでたらめが多いが、
テストループと環境を提供すれば、反復的に改善して本当に動く結果を出す
一方、バグレポートは曖昧で評価が難しい
たとえば100ドルの中に、50ドル相当の本物の問題1件と、0.01ドル相当の偽レポート5000件が混ざっていると、
本物のダイヤモンドを見つけるのが難しくなる
サンドボックスの説明が曖昧だったので、最初は疑わしく感じた。
著者のリポジトリを見ると、目標は「
/tmp/pwnedにPWNEDという文字列を書き込むこと」だった。つまり、サンドボックス脱出ではなく単なるファイル書き込み制限だった
OOB R/W primitive APIを作らせた件も、すでに何千もあるGitHub上の例を再利用した程度だ
「今後、国家や組織のハッキング能力はハッカーの人数ではなくトークン処理量で決まる」という言葉が印象的だった。
ソフトウェア開発の参入障壁とハッキングの参入障壁が同時に下がるのは、爆発的な組み合わせだ。
今やセキュリティガードレールと検証可能性を備えた新しいプラットフォームが必要だ。
非専門家が作ったコードに依存するには危険すぎる