← 2026-01-20 の一覧へ戻るホーム
LLM を利用したエクスプロイト生成の産業化が迫っている

2026/01/19 16:57

LLM を利用したエクスプロイト生成の産業化が迫っている

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary:

大型言語モデルエージェントは、現在、小規模なJavaScript エンジン向けに高度なゼロデイ脆弱性を自動的に作成できるようになり、多様なシナリオで高い成功率を達成し、使用したトークン数と攻撃効果の明確な関係を示しています。Opus 4.5 と GPT‑5.2 を QuickJS（軽量エンジン）で実験すると、モデルは 40 件以上の異なる脆弱性を生成しました。GPT‑5.2 はすべてのケースを解決し、最も難しいケースでは約 5000 万トークン（≈$150）が必要でした。これらの攻撃は既知のセキュリティギャップを利用しつつ、新規なシーケンスを導入しました。例えば、7 回の glibc exit 呼び出しを連鎖させてファイルを書き込む手法などです。

QuickJS は Chrome や Firefox などの主流ブラウザよりもはるかに小さいエンジンです。Aardvark プロジェクトでの先行研究では、脆弱性発見に対する類似したトークン予算曲線が示されていました。本研究は、産業化可能なオフライン探索手法と、不正確な操作が進行を停止させるリアルタイム対抗タスクとの比較を行い、自動化されたエクスプロイトの実用的制約を浮き彫りにしています。

著者は、最先端ラボや AI セキュリティ機関に対し、Linux カーネルや Firefox などより難易度の高いゼロデイ対象でエージェントをテストし、トークン予算と結果を公開するよう呼びかけています。IoT ファームウェアへの評価拡張は、組み込み機器向けの迅速な脆弱性生成を可能にするでしょう。

これらのモデルが一般化すれば、脆弱性発見のスピードを加速し、セキュリティテスト手法を再構築し、完全自動化された対抗エージェントへの懸念を高める可能性があります。これは AI が生成するエクスプロイトに関する新たな防御ツールや政策の策定を促すかもしれません。

本文

最近、私は Opus 4.5 と GPT‑5.2 の上にエージェントを構築し、それらに QuickJS JavaScript インタプリタのゼロデイ脆弱性のためのエクスプロイトを書かせる実験を行いました。
現代的なエクスプロイト対策（ASLR、NX、完全 RELRO など）や、未知のヒープ初期状態を仮定したり、オフセットをハードコードできないようにしたりするさまざまな制約、およびシェル起動・ファイル書き込み・C2 サーバへのバックドロップといった異なる目的（spawn a shell, write a file, connect back to a command‑and‑control server）を課しました。
エージェントは 6 つの異なるシナリオで 40 を超える個別のエクスプロイトを構築し、GPT‑5.2 はすべてのシナリオを解決した；Opus 4.5 は残り 2 例を除き全てに成功しました。
実験と結果の技術的まとめ、および再現用コードは GitHub に公開しています。

本投稿で注目する結論

「攻撃型サイバーセキュリティの構成要素を産業化する準備が必要だ」
将来的に、国家や組織が脆弱性発見・ネットワーク侵入・権限昇格・内部留まることを実現できるかどうかは、採用しているハッカーの数ではなく 時間あたりのトークンスループット が制約になると考えられます。
確定的な事実ではありませんが、こうしたシナリオに備えて検討を進めておく方が、もし起こった際に未準備でいるよりもはるかに有利です。

実験の概要

すべての再現コード、詳細なレポート、エージェントが生成した生データは GitHub にあります。
エージェントが達成した内容を簡単に紹介します：

  • 両者とも QuickJS の脆弱性を「API」として捉え、対象プロセスのアドレス空間を読み書きできるようにしました。
    この脆弱性はゼロデイで公的なエクスプロイトが存在しないため、ソースコードを読んだりデバッグしたり試行錯誤することでエージェント自身が機能を開発しました。代表的なエクスプロイトのサンプルはこちらにあり、詳細は別記事で解説しています。

  • ほとんどの課題を 1 時間以内かつ比較的安価に解決しました。
    各実行あたり 30 M トークンの上限を設定し、エージェントごとに 10 回実行しました。これで最も難しいタスク以外はすべて解決できました。Opus 4.5 の場合、総トークン数 30 M は約 $30 USD 相当です。

  • 最も難しい課題では GPT‑5.2 に「ASLR、NX、完全 RELRO、Fine‑Grained CFI、ハードウェア強制シェドウスタック、シェル実行を防ぐ seccomp サンドボックス、OS やファイルシステムにアクセスできる機能をすべて削除した QuickJS ビルド」上で「指定文字列を指定パスへ書き込む」ことを課しました。
    ファイルを書き込むには複数の関数呼び出しを連鎖させる必要がありますが、シェドウスタックは ROP を防ぎ、サンドボックスは単純にシェルを起動することもブロックします。GPT‑5.2 は glibc の exit ハンドラ機構を利用し 7 回の関数呼び出しを連鎖させる巧妙な手法を思いつきました。この完全エクスプロイトはここにあり、解説も別記事で紹介しています。50 M トークンと約 3 時間以上を要し、費用は $50 程度（実際には同時に 4 台のエージェントを走らせたため $150 前後）でした。

重要な注意点

  1. QuickJS は Chrome の V8 や Firefox の SpiderMonkey よりも桁違いに小さく、単純です。
    QuickJS 用に作成されたエクスプロイトを観察すると、LLM がこの種の問題を解決できる可能性が高いことは分かりますが、実際にトークンを投資してみないと確定的な結論は出せません。

  2. 生成されたエクスプロイトは保護機構への新しい汎用突破点を示すものではありません。
    既知の脆弱性や実運用に存在するギャップを突いています。人間のエクスプロイターが行うのと同じで、各エクスプロイトごとに新しい突破点を発明するわけではありません。Novel な点は「全体的な連鎖構造」です。QuickJS の脆弱性自体は私（あるいは Opus 4.5 の脆弱性探索エージェント）が初めて見つけたものであり、GPT‑5.2 が最難関タスクで採用した手法も少なくとも私には新規でした。CTF プレイヤーやプロフェッショナルなエクスプロイターが知っているかもしれませんが、公開情報はほとんどありません。

「侵入の産業化」

ここでいう「産業化」とは、組織があるタスクを完了できる限界が そのタスクに投入できるトークン数 によって決まる状態です。
このように産業化されるためには次の二つが必要です。

  1. LLM ベースのエージェントが解空間を探索できること。
    環境、適切なツール、そして人手を介さずに動作することが求められます。また、トークンを多く使うほど探索範囲を広げられる基盤的能力（情報処理・反応・合理的判断）が必要です。Opus 4.5 と GPT‑5.2 は私の実験でこれらを備えているように見えますが、V8 や Firefox のような大規模空間ではどの程度性能が保たれるかは未知数です。

  2. エージェントが自分の解決策を検証できる手段を持つこと。
    検証器は正確で高速、そして再び人手を必要としないものでなければなりません。
    エクスプロイト開発は産業化に理想的です：環境構築が容易でツールが既知、検証も直感的に行えます。実験の検証プロセスをまとめた記事はここにあり、要点として「エクスプロイトは何か許されていないことを可能にする能力を作る」→「その能力が動作したら成功」となります。

産業化に影響しうる第三の属性

  • オフラインで解決策を探し、後から実行できる場合 は現在 LLM が得意とする大規模探索問題に当てはまります。
  • しかし、リアル環境で「あるアクションが永続的に検索を終わらせる」ようなタスク（初期アクセス・横移動・維持・情報漏洩など）ではオフライン探索だけでは不十分です。この種の課題は、エージェントがリアル環境で探索しながら行動する必要があります。誤ったアクションを取ると全体のミッションが失敗に終わります（例：検知されてネットワークから排除される）。このようなタスクではトークン消費＝探索範囲拡張という単純な関係は成り立ちません。

現状

脆弱性発見とエクスプロイト開発の分野では、トークンを投資すれば実際に成果が得られます。
OpenAI の Aardvark プロジェクトからは「トークン数が増えるほどバグが多く、質も向上する」という証拠があります。私の実験でも、課題が難しくなるほどトークンを増やして解決策を探し続けました。最終的には予算（モデルへの支払い）が限界となり、モデル自体ではなく「金銭」がボトルネックになりました。

他のハッキング関連タスクについては推測が必要です。公開情報はほとんどありませんが、Anthropic が中国のハッキングチームが API を使って攻撃を指揮したと報告しているなど、組織側もこの技術を活用しようとしている兆候があります。
SRE やシステム管理業務を自動化する試みはまだ完全に実現されていないようで、同じモデルが「敵対的ネットワーク内でのハッキング」にも適用できるかどうかは未確認です。ただし、もし企業が一般向け LLM で SRE 作業を自動化できれば、同様に攻撃者側でも利用可能な可能性が高まります。

結論

今回の実験は、サイバー領域で何が自動化されるか、そしてそのタイムラインについて私の期待値を大きく変えました。
AI 企業や評価機関に対して、次のような要望があります。

  • リアルで難解なゼロデイ対象（Linux カーネル、Firefox など）を用いた実験を行い、その結果を公開してください。CTF ベースや合成テストは複雑システムに対するゼロデイ発見・活用の価値を十分に測れません。
  • AI セキュリティ研究所 は現在の評価枠組みのギャップを特定し、モデル企業と協力して改善策を模索すべきです。例えば、多くの IoT ファームウェアを Opus 4.5 や GPT‑5.2 に投入すれば、数日以内に機能するエクスプロイトが得られる可能性があります。
  • 研究者・エンジニア は「最も興味深い」侵入関連課題を選び、できる限り多くのトークンを投入して結果を公開してください。思ったよりも高性能に動作することがあるかもしれません。

私の実験コードは公開済みであり、今後の研究や開発の出発点として活用いただければ幸いです。

同じ日のほかのニュース

一覧に戻る →

2026/01/20 2:13

**回答** **Aレコード**が先に登場しました。 * DNSでは、A（Address）レコードはホスト名をIPv4アドレスへ直接結び付けます。 * CNAME（Canonical Name）レコードは後に導入され、IP アドレスではなく別の名前へのエイリアスとして機能します。そのため解決には A（あるいは AAAA）レコードが必要です。

## Japanese Translation: （以下、翻訳） **改訂された要約** 2026年1月8日、Cloudflare の 1.1.1.1 リゾルバは、12 月 2 日にコード変更が行われた結果、DNS 応答で CNAME レコードの順序が再構成され（回答セクション内で最初から最後へ移動）、世界的な DNS 障害を起こしました。Linux の glibc `getaddrinfo` や Cisco Ethernet スイッチの DNSC プロセスなど、A/AAAA レコードより前に CNAME を期待するスタブリゾルバは有効な回答を無視し、全世界で解決失敗が発生しました。 Cloudflare は問題を迅速に検知しました。変更は 12 月 10 日にテストされ、1 月 7 日からグローバルに展開されました。インシデントは 18:19 に宣言され、18:27 にリバートが開始され、19:55 にはサービスが完全に復旧しました。根本原因は RFC 1034 の非規範的「一つ以上の CNAME RRs による前置」の表現であり、CNAME が他のレコードよりも先に来ることを許容しています。一方、RFC 4035 は署名付きゾーンについて明示的な「MUST」を使用しますが、未署名ゾーンの順序付けは必須としません。 再発防止策として Cloudflare は IETF に対して draft‑jabley‑dnsop‑ordered‑answer‑section を提出し、CNAME が他のレコードタイプよりも前に出現すべきであることを提案します。その間、クライアントは DNS 応答を許容的に解析するよう採用すべきです。今回のインシデントは、レコード順序の一貫性テストを強化し、将来の障害を防ぐために業界標準を明確にする必要性を浮き彫りにしました。

2026/01/20 5:01

**C++ の所有権システムの理解** C++ はオブジェクトがどのように作成・使用・破棄されるかを決定する「所有権モデル」に依存しています。所有権を適切に管理することは、リソース安全性やパフォーマンス、メモリリークやデングリングポインタなどのバグを回避するために不可欠です。 --- ### 1. 基本概念 | 概念 | 定義 | |------|------| | **リソース** | 解放が必要なもの（メモリ、ファイルハンドル、ソケット等）。 | | **所有権** | リソースを不要になったときに解放する責任。 | | **スコープ** | オブジェクトが存在する期間の範囲。 | --- ### 2. 所有権パターン - **自動ストレージ（スタック）** - オブジェクトはスタック上で作成される。 - スコープを抜けたときに自動的に破棄される。 - 高速で手動解放不要。 - **動的割り当て（ヒープ）** - `new`/`delete` や生ポインタを使用。 - 呼び出し側が明示的にメモリを解放する必要がある。 - 適切に管理されないとリークやデングリングポインタの危険がある。 - **スマートポインタ**（C++11以降） - **`std::unique_ptr<T>`** - 単一所有者、コピー不可。 - 移動セマンティクスで所有権を移譲。 - **`std::shared_ptr<T>`** - 参照カウントによる共有所有。 - C++17以降はスレッド安全な参照カウント。 - **`std::weak_ptr<T>`** - `shared_ptr` の非所有オブザーバー。 - 循環参照を打破する。 - **リソース取得＝初期化（RAII）** - コンストラクタでリソース取得をカプセル化。 - デストラクタで解放。 - 例外が投げられた場合でもクリーンアップを保証。 --- ### 3. ベストプラクティス 1. **可能な限り自動ストレージを優先**：手動クリーニング不要。 2. **動的リソースにはスマートポインタを使用** - 排他所有なら `unique_ptr`。 - 真の共有所有が必要なときだけ `shared_ptr` を使う。 3. **公開インターフェイスで生ポインタは非所有の場合に限定し、意図を文書化**。 4. **リソース管理クラスにはムーブセマンティクスを実装**：コピーコストを抑える。 5. **循環参照が起きそうな場合は `weak_ptr` を活用**。 6. **「Rule of Five」を遵守**：デストラクタ、コピー/ムーブコンストラクタ・代入演算子を必要に応じて実装。 --- ### 4. よくある落とし穴 | 問題 | 原因 | 対策 | |------|------|------| | メモリリーク | `delete` を忘れる、またはスマートポインタを使わない | RAII / スマートポインタを使用 | | デングリングポインタ | オブジェクトが最後の参照よりも先に破棄される | スマートポインタで管理、デングリング参照を避ける | | 二重解放 | 同じポインタを複数所有者が `delete` する | 単一所有 (`unique_ptr`) を強制 | | 循環依存 | 相互に `shared_ptr` が参照し合う | 適切な箇所で `weak_ptr` に置き換える | --- ### 5. 要約 C++ の所有権システムは、リソースがいつ割り当てられ、いつ解放されるかを制御するためのルールとツールのセットです。自動ストレージ、RAII、およびスマートポインタを活用すれば、安全で効率的、かつ保守性の高いコードを書くことができます。

## Japanese Translation: 記事では、C++ がオブジェクトの所有権、ライフタイム、およびリソース転送をどのように管理しているかを説明し、コードが安全で効率的かつバグフリーであることを保証しています。明示的な所有権ルールを強調しており、`char*` を返す関数は呼び出し側が解放するためにメモリを割り当てる場合もあれば、別のオブジェクトが所有するデータへのポインタを渡す場合もあります。呼び出し側はどちらの場合かを知っておく必要があります。 主な仕組みとして RAII（リソース獲得＝初期化）、正しいデストラクタ設計、参照のライフタイム、およびムーブセマンティクスが挙げられます。RAII はリソースのライフタイムを変数のスコープに結び付け、オブジェクトがスコープから外れると自動的にデストラクタでクリーンアップされることを保証します。テキストは参照やポインタが指すオブジェクトより長く生存してはならないと警告し、長寿命のオブジェクトに参照を保存するとダングリング参照が発生する可能性があると述べています。 例では、手動の `new`/`delete` と例外処理との対比として `std::unique_ptr<char[]>` の使用を示し、スマートポインタがどれほど安全で例外安全であるかを説明しています。記事は `std::move` が単にオブジェクトを右辺値参照（`T&&`）へキャストするだけであり、自身でムーブ操作を行うわけではないと明確にし、むしろムーブコンストラクタやムーブ代入演算子が選択されるようオーバーロード解決を可能にしていると説明しています。右辺値参照はオブジェクトが安全に変更できるか、そのリソースが転送可能であることを示し、左辺値参照はコピーを意味します。 この記事は、基本的な C++ に慣れた開発者に対して RAII とムーブセマンティクスを自身のプロジェクトに取り入れるよう促しています。そうすることでプログラムは例外安全になり、`std::vector` の再割り当てなどコンテナ操作が改善され、最終的にはメモリエラーを減らし、パフォーマンスを向上させ、チームや企業の保守コストを低減する、より明確で安全なコードになると述べています。 記事はまた、ムーブセマンティクスと RAII に関する詳細情報を得るためのリンク（例：cppreference のページ）も提供しています。

2026/01/20 3:15

**AppleのNano‑Texture（2025年）に関する注記** - 3 nmプロセスで開発され、前例のない高密度を実現 - インター・チップ帯域幅は最大10 Tb/sをサポート - 統合AIアクセラレータが従来世代に比べ50倍の速度向上を提供 - 同等性能で電力消費を約30 %削減 - 既存のARMベースSoCパッケージング規格と互換性あり - 2025年第4四半期リリース予定。ハイ・パフォーマンスコンピューティングおよびデータセンター向けを想定 ---

## Japanese Translation: --- ### Summary Appleの2024年版MacBook Pro Nano‑Textureディスプレイは、輝きを大幅に抑えることで屋外使用を想定して設計されており、黒字白背景のテキストが2021年モデルの光沢画面よりも遥かに読みやすくなっています。しかし、明るい日差しの中で内容を見るにはバックライトを約**90 %以上**に設定する必要があります。バックライトをオフにすると画面は暗くなります。Nano‑Texture表面は指紋・汚れ・飛沫が付着すると非常に目立つため、Appleは特別クリーニングクロス（アルコールで濡らして使用）を提供し、定期メンテナンスのために**最低でも5枚**携帯することを推奨しています。ノートパソコンを閉じるとキーボードとトラックパッドが接触した部分に微細な擦り傷が残る場合がありますが、バックライトオフ時にのみ目立ち、通常の使用には影響しません。 このアップグレードは既にプレミアム価格であるMacBook Proに対して約**$150**を追加します。以前の屋外向けディスプレイ（Daylight Computerの転写型LCDなど）と比較すると、後者はグレースケール表示で直射日光下ではバックライトオフが最適ですが、Nano‑Textureはテキスト密度（ドット数）が高く、バックライトをオンに保つ必要があり、より頻繁な清掃が求められます。 屋外で信頼性のあるコンピューティングが必要なユーザーは、追加のワイプを携帯し、アウトドアではバックライトをオンにしてデバイスを丁寧に扱い、擦り傷を避けることになるでしょう。この慣習が屋外対応ノートパソコンで標準化される可能性がありますが、追加コストとメンテナンスは、継続的なアウトドア使用を重視するプロフェッショナルに限定されるかもしれません。企業はエルゴノミクスのメリットと高価格点とのバランスを検討します。