ハクソク

世界を動かす技術を、日本語で。

「Claude Mythos Preview」を用いたFirefoxの強化

2026年5月8日原文(hacks.mozilla.org)

概要

  • FirefoxはAIモデル（Claude Mythos Preview等）を活用し、過去最多の潜在的セキュリティバグを特定・修正
  • AI活用の手法、発見内容、他プロジェクトへのアドバイスを詳細解説
  • AIモデルとハーネス技術の進化により、実用的なバグ発見が大幅向上
  • 発見バグの一部を公開し、ソフトウェア防御強化の重要性を強調
  • 今後も継続的な改善とAI活用によるセキュリティ強化を推進

FirefoxにおけるAI活用によるセキュリティバグ発見と修正の詳細

  • Claude Mythos Preview などのAIモデルを活用し、 Firefox の潜在的なセキュリティバグを大量に発見・修正
  • 以前はAI生成のバグ報告は誤報が多く、プロジェクト管理者に負担を強いる傾向
    • LLMによる「問題」の指摘が容易だが、対応には多大な労力
  • モデルの能力向上と活用技術の進化により、短期間で状況が一変
    • モデルの高性能化
    • モデル運用技術（指示、スケーリング、ノイズ除去）の大幅改善
  • 通常は修正後しばらく詳細非公開だが、今回は特例として一部バグ報告を公開
    • 多様なブラウザサブシステムから抜粋
    • サンドボックス脱出等、高度な脆弱性も含む
  • 公開したバグ例（一部抜粋）
    • JIT最適化によりWebAssembly GC構造体の初期化が省略され、任意読み書き可能な偽オブジェクト生成
    • <legend>要素の15年越しのバグ（再帰スタック、エッジケースの組み合わせ）
    • IPC競合によるIndexedDB参照カウント操作でUAF（Use After Free）発生
    • NaN値がJSオブジェクトポインタに偽装されサンドボックス脱出
    • イベントループやGCを組み合わせた<object>属性セッターのUAF
    • WebTransportの証明書ハッシュ大量送信による競合とUAF
    • glibc DNS呼び出しの再現によるバッファオーバーリード等
    • 20年越しのXSLTハッシュテーブル再ハッシュ問題
    • カラーピッカー操作でのコールバックUAF
    • RLBoxサンドボックスの検証ロジック抜け穴
    • rowspan=0のHTMLテーブルでの16ビットビットフィールドオーバーフロー
  • これらの多くはサンドボックス脱出であり、完全なFirefox侵害には他のバグとの連携が必要
    • サンドボックス内で攻撃者制御のコード実行を前提
  • AIモデルによるバグ発見はファジングでは困難な領域にも有効
  • モデルが発見できなかった脆弱性も重要
    • 例：プロトタイプ汚染によるサンドボックス脱出を設計変更で根本対策

モデル活用のハードニングパイプライン構築

  • 過去数年にわたり、LLMによるコード監査を内部実験
    • GPT 4やSonnet 3.5等を活用
    • 誤検知率が高く大規模運用は困難だった
  • エージェント型ハーネスの導入で状況が一変
    • 実際にテストケースを生成・実行し、バグ仮説を動的検証
  • Anthropicからの初期報告修正後、自社ファジング基盤上にハーネスを構築
    • Claude Opus 4.6を用いたサンドボックス脱出探索
    • 複雑なマルチプロセスコードでも未知の脆弱性を多数発見
  • プロセス監督から始め、徐々にVM並列化・自動化
    • 各ファイル単位でバグ探索・報告を自動実行
  • 発見だけでなく、バグ管理・重複排除・トリアージ・修正まで一貫対応
    • パイプラインはプロジェクトごとに最適化が必要
    • エンジニアとの密なフィードバックループで改善
  • パイプライン構築後はモデルの入れ替えも容易
    • Claude Mythos Preview等の新モデル導入で効果向上
    • 150リリースで271件、他バージョンでも追加修正
  • チーム全体で100人以上が貢献
    • パッチ作成・レビュー、パイプライン構築・運用、リリース管理

ソフトウェア開発者への提言

  • どのプロジェクトでも、現代的なモデルとハーネスを活用すれば即座にバグ発見・堅牢化が可能
  • シンプルなプロンプトから開始し、観察・反復で最適化
  • 本質は「このコードにバグがあるか、テストケースを作って発見して」というサイクル
  • 現状は人判断＋自動信号で重点領域を選定してスキャン
  • 近い将来、CIシステムに分析統合し、パッチ単位での自動スキャンも計画
  • モデルは柔軟で、パッチスキャンも十分有効と期待
  • 今こそ協力してインターネット全体のセキュリティ強化を推進

FAQ：よくある質問

  • 「271件」との発表と、実際のCVE数が異なる理由
    • 内部報告バグは「ロールアップ」CVEとしてまとめて登録
    • 公式リポジトリのyamlがCVEの正規記録
    • 外部報告や他手法による発見分も含め、4月は合計423件を修正
    • Anthropic Frontier Red teamからの個別CVEも3件
  • セキュリティ評価（critical, high, moderate, low）の意味
    • sec-critical/sec-high：通常の利用で引き起こせる深刻な脆弱性
    • sec-moderate：複雑な手順が必要な場合
    • sec-low：ユーザー被害の少ないバグ
    • Firefox 150の271件は、180件がsec-high、80件がsec-moderate、11件がsec-low
  • sec-high/criticalと実際の攻撃可能性の違い
    • 多くの場合、単一バグではFirefox完全侵害は不可
    • 多層サンドボックス・OS保護（ASLR等）で防御
    • sec-highはクラッシュ症状等で判定し、実際のエクスプロイト構築は行わない
    • 誤判定リスクを下げ、脆弱性発見・修正にリソース集中

著者紹介

  • Brian Grinstead：Firefox Distinguished Engineer
  • Christian Holler：Firefox Tech Lead & Principal Engineer（@mozdeco）
  • Frederik Braun：Firefox Application Securityチームマネージャー、Sanitizer API等の標準化にも貢献

参考URL

Hackerたちの意見

LLMがバグを見つけて直すのがすごく上手くなって、Firefoxのエンジニアが新機能の追加に専念できる日が来るといいな。これは皮肉じゃないよ。Firefoxはもっと使われるべきだと思う。周りのほとんどの人は「Chromeの方がほとんどのことをうまくやるから」って理由で使ってないし、Firefoxは他のブラウザのロードマップには勝てないんだよね。

└

Firefoxはもっと使われるべきだね。 まったく同意だよ。どのサイトで買い物するかを、Firefoxで動くかどうかで選ぶこともあるし、サポートに「対応してない」とか「機能がうまく動いてない」ってたまに連絡することもある。たぶん何も変わらないけど、ブラウザを少しでも意識してもらうためにできることだと思ってる。

└

Firefoxはもっと使われるべきだね。 問題の一部は、バグ修正をやめると、Mr. Robotみたいなことを始めることだよね… ただのウェブブラウザが欲しいのに。ポケットやAIなんて誰も求めてないよ。もしAIを使ってバグを全部直すなら、彼らは他に何をするの？ 様々な言語との構文互換性を維持することだけ？ またブラウザをゴミに戻すだけだよ。

└

Chromeは99%以上のユースケースで意味のある点で良くないよ。俺は開発者だけど、過去10年くらいFFをuBlock Originだけで使ってる。妻も同じで、俺がいろいろ説明したら、インターネット体験がどれだけ違うか理解してくれたから、彼女もそれがメインブラウザになった。だから、「ここにクソみたいなアンダードッグがあるけど、独占は悪いから使って」みたいな議論はやめてほしい。俺が試した中では、全てにおいて一流の体験なんだ。モバイルではそれが3倍になるし、最高のモバイル体験だよ。

元のソース: https://news.ycombinator.com/item?id=48051079 これは、公開されたBugzillaのレポートのサンプルを実際にリストアップしているから、より良いんだ。この話題は以前も議論されたけど（2週間前に36件のコメント: https://news.ycombinator.com/item?id=47885042）、バグレポートが公開される部分は新しい情報だね。

もう一度言うけど、これは重要だよ：バグはバグだ。「潜在的な脆弱性」もバグだ。脆弱性は、概念実証や他の実質的な証拠でセキュリティに影響があることが確認できる。言葉は大事だし、バグも大事。大量のバグを修正することは、昔から重要で、実際に行われてきたことなんだ。それ自体がすごいことだから、十分だと思うよ。Mythosは271の脆弱性のためのPoCを書いて、セキュリティに影響があるコードパスの到達性を示したわけじゃない。Mythosは271の有効なバグを見つけたんだ。それで十分だよ。

└

君の定義にはちょっと混乱したけど、Mozillaが271の、えっと、ものをこう分けたんだ： > 追加のコンテキストとして、バグの緊急度を示すために、セキュリティの重大度評価をクリティカルからローまで適用しているよ： > * sec-criticalとsec-highは、通常のユーザーの行動で引き起こされる脆弱性に割り当てられる。ウェブページをブラウジングするような行動だね。技術的には違いはないけど、sec-criticalバグは公開されているか、実際に悪用されていることが知られている問題に予約されている。 > * sec-moderateは、通常はsec-highと評価されるはずの脆弱性に割り当てられるけど、被害者からの異常で複雑な手順を必要とするもの。 > * sec-lowは、煩わしいけどユーザーに害を及ぼすことはないバグに割り当てられる（例えば、安全なクラッシュ）。 > Firefoxのために発表した271のバグのうち、150はsec-high、80はsec-moderate、11はsec-lowだった。Mozillaはsec-highでも「脆弱性」という用語を使っているけど、その下で実際の悪用とは同じ意味ではないと言っている。定義のページでは、sec-lowも「脆弱性」として分類されている [2]。言葉は道具で、集合的な意味からその有用性を得るものだ。君がどこでその意味論を得たのか、Mozillaと一致するのか、違うのか興味があるな。

└

Mythosは、メモリ安全でない動作を示す全てのバグに対してPoCを書いたんだ（例えば、use-after-freeやバッファオーバーランなど）。私たちにとっては、これがセキュリティ脆弱性と見なすのに十分な証拠なんだ、他に示されない限りはね。これは常にそうだったし（ファジングバグにも）。

└

Mythosは脆弱性のために271のPoCを書かなかったけど、君が言いたいのは「エクスプロイト」ってことかな？

└

これは、優先順位を決める必要がある場所ではどこでも真実じゃないよ。

└

Claudeは、もし自分がそのコードを持っていると思えば、見つけた脆弱性に対してPoC（Proof of Concept）エクスプロイトを生成することができるし、実際にそうするだろうってことは覚えておいてもいいかも。これについての唯一の情報源は自分の経験だけで、証拠は共有できないけどね。

彼らはほんの数件のチケットしかリンクしてないから、実際に271の異なるものを見たときにその洞察が当てはまらないかもしれないけど、私が調べたものは全部、厄介なバグを含むC++コードだったよ。Firefoxは複数の言語で書かれていて、C++はそのうちの約25%だけど、これらの問題はすべてC++に関わっているみたいだね。

Hacker Newsで議論の続きを見る