Anthropicのリサーチ・サイエンティストNicholas Carlini氏は、[un]prompted AIセキュリティカンファレンスで、2003年以降存在していたNFSドライバのヒープバッファオーバーフローを含む、Linuxカーネルに存在するリモートから悪用可能な複数のセキュリティ脆弱性を、Claude Codeを使用して発見したと報告した。このバグはその後パッチ適用済であり、Carlini氏はこれまでのところ合計5件のLinuxカーネル脆弱性を特定済で、さらに人手による検証を待つ数百件の潜在的なクラッシュが残っている。
Michael Lynch氏はCarlini氏のカンファレンス講演に基づき、検出内容の詳細分析を書いた。この検出内容が注目に値する理由はバグの古さだけでなく、それを発見するためにClaude Codeがほとんど人間の関与を必要としなかった点にある。Carlini氏は、Linuxカーネル内のすべてのソースファイルを順に処理する単純なbashスクリプトを使用し、ファイルごとにClaude Codeへキャプチャー・ザ・フラッグ競技に参加していると伝え、脆弱性を探すよう指示した。カスタムツールはなく、1ファイルずつモデルのバイアスをかける以外に特別なプロンプトも使用していない。
# Iterate over all files in the source tree. find . -type f -print0 | while IFS= read -r -d '' file; do # Tell Claude Code to look for vulnerabilities in each file. claude --verbose --dangerously-skip-permissions --print "You are playing in a CTF. Find a vulnerability. hint: look at $file Write the most serious one to the /output dir" done NFS脆弱性そのものは複雑なプロトコル詳細仕様の理解を要するものであった。この攻撃ではLinux NFSサーバーに対して協調動作する2つのNFSクライアントを用いる。クライアントAは異常に長いが仕様上は合法な、1024バイトのowner IDでファイルロックを取得する。続いてクライアントBが同じロックを取得しようとして拒否されると、サーバーはowner IDを含む拒否応答を生成する。問題はサーバーの応答バッファが112バイトしかないにもかかわらず、拒否メッセージ全体は1056バイトに達する点にある。カーネルは112バイトのバッファに1056バイトを書き込み、攻撃者に上書きしたカーネルメモリの制御を与えてしまう。このバグはgitそのものより前にさかのぼる2003年のコミットで導入されたものである。
実務者にとってモデルの進化がおそらく本件でもっとも重要な部分である。Carlini氏は以前のモデルで同様の結果を再現しようと試みたが、8か月前にリリースされたOpus 4.1および6か月前にリリースされたSonnet 4.5では、Opus 4.6が発見したもののごく一部しか検出できなかった。数か月間でこの能力の飛躍は、AI支援による脆弱性発見が日常的になるまでの猶予が急速に縮まっていることを示唆している。
これは別の側面からLinuxカーネルメンテナが観測している状況とも一致する。検出事項について議論するRedditスレッドでシェアされたように、もっともシニアなLinuxカーネルメンテナ Greg Kroah-Hartman氏がこの変化について述べた：
1か月前に何かが起き、すっかり世界が変わりました。今では本物のレポートが届いています……すべてのオープンソースセキュリティチームが今まさにこれに直面しています。
別のカーネルメンテナWilly Tarreau氏もLWNでこれを裏付け、カーネルセキュリティリストへの報告が週2～3件から1日5～10件へと増加し、その大半が現在では正確であると述べている。
誤検知の問題は依然として未解決である。Carlini氏は検証する時間がとれない「数百件のクラッシュ」があり、未検証の検出事項を意図的にカーネルメンテナに送らないようしている。Hacker News上で、Lynch氏（ブログ記事の著者）は自身がClaude Opus 4.6を用いて類似の作業を行った経験では、誤検知率は20％未満であると述べている。
Redisの開発者Salvatore Sanfilippo氏は同じHacker Newsスレッドで、検証ステップはますますモデル自身が担うようになってきているとコメントしている：
バグは多くの場合、後工程でLLM自身によりフィルタリングされます。第二のパイプラインがクラッシュ／異常動作／エクスプロイトをいかなる形でも再現できない場合、誤検知の多くは人間の精査に到達する前に排除されます。
脆弱性研究にキャリアの大半を費やしてきたセキュリティ研究者Thomas Ptacek氏は、Hacker News上でLLMベースの脆弱性発見は根本的に異なるツールのカテゴリであると主張した：
単純化して言えば、LLMエージェントによる脆弱性発見はファジングと静的解析の両方のスーパーセットです。
Ptacek氏は静的解析ツールが高コストな人間によるトリアージを必要な仮説的なバグを大量に生成し、ファザーはコンテキストなしにバグを発見し、数か月間未解決のままとなるクラッシュ報告を生成すると説明した。これに対しLLMエージェントはコードベース全体にわたり再帰的に仮説を生成し、確認ステップを実行し、信頼度を算出し、入力経路や攻撃プリミティブを明示することで検出事項をコンテキスト内に配置する。
デュアルユースの懸念は両方のディスカッションスレッドで繰り返し提起された。あるRedditコメンターが投稿した：
AIが人間の監査者が見逃した23年前の潜在的なLinuxの脆弱性を見つけられるなら、同じ能力を持つ敵対者はそのプロセスを大規模にターゲットに対して実行できます。
Carlini氏が確認した5件のLinuxカーネル脆弱性はNFS、io_uring、futex、ksmbdにまたがっており、いずれも現在は安定版ツリーにカーネルコミットが取り込まれている。[un]promptedでの講演はYouTubeで視聴可能である。