全体の一行要約
- LLMプロンプトとソースコードのバンドルを組み合わせた低コストなパイプラインで、Django と FastAPI（Starlette）における denial-of-service 脆弱性3件を発見（CVE-2025-64458、CVE-2025-64460、CVE-2025-62727）
要約
- DEF CON LiveCTF と DARPA AIxCC で上位チームが LLM を使ってバイナリを攻略し、新規 0-day まで見つけるのを見て、実際の offensive research 分野でも LLM が人間より高い効率を示しうると感じた
- AIxCC 参加チーム（Team Atlanta、Theori）の GitHub アーカイブと RoboDuck の設計を詳しく調べる中で、「ファジングの代わりに LLM でバグを探す」アプローチを脆弱性発掘ワークフローに移植できると感じた
- Django、DRF、Python で複数のセキュリティ問題を報告してきた中で蓄積したコンテキストを活かし、LLM を使って Django フレームワークで denial-of-service 系の新規脆弱性を見つけることを明確な第一目標に据えた
- バイナリ解析やパッチ作成までをすべて自動化する AIxCC 参加モデルとは異なり、スクリプトベースの Django を対象に「脆弱そうなコードセグメント候補をかき集める段階」だけを自動化し、コストを数ドル水準に抑える構成を設計した
- LLM に「Django でセキュリティ脆弱性を探すセキュリティリサーチャー」という役割を与え、DoS の例となる CVE diff、
<tips> 制約条件、出力フォーマット例をまとめた長文プロンプトを作成し、不必要なパッチ提案を防ぎ、誤検知率を下げる方向でプロンプトを設計した
- Django のソースコードは同じディレクトリごとに XML でバンドルし、40K トークン以下に分割して GPT-5 に渡した。こうしてフレームワーク全体を一巡しても、実行コストがおよそ 5 ドル程度に収まるようにした
- ワークフローで見つかった false-positive な候補を検討していく中で、何年も見落とされていた脆弱なパターンを発見することもあった。妥当性の判断過程でも、セキュリティ問題の root cause の説明や PoC 作成などで優れた能力を示した
- その後は OpenAI API の代わりに Codex CLI に AGENTS.md プロンプトを渡して Django のソースを能動的に調べさせたところ、HttpResponseRedirectBase の URL hostname 処理における O(n²) DoS 脆弱性を発見し、CVE-2025-64458 として登録された
- 同じプロンプトを FastAPI（正確には Starlette）にも適用したところ、FileResponse の Range ヘッダー統合ロジックが正規表現ベースの O(n²) 処理により ReDoS を引き起こしうることが判明し、CVE-2025-62727 として公開、Snyk 基準で CVSS 8.7（High）と評価された
5件のコメント
行動力がすごいですね.. 素晴らしいです
外部発表資料に引用できるほど良い事例ですね。保存しておこうと思います。
> 資本の観点から見ると、繊細で長いプロンプトが必要な高コンテキスト作業であるほど、代替の時期はどうしても遅くならざるを得ないと思います。
この部分も素晴らしいインサイトだと思います。
私も関心はあったものの、実際に深く取り組んだことはなかったのですが、この記事は動機とインサイトの両方を与えてくれます。良い記事としておすすめします。
要約を見て抱いた先入観（煽り気味なタイトルだし……）より、記事の内容はずっと良かったですね。興味のある方には原文を読むことをおすすめします。