巧妙だが危険なメモリの欠陥が、セキュリティ研究者に発見されるまで6カ月にわたってFirefoxにひそかに組み込まれ、1億8000万人を超えるユーザーに影響を及ぼしていた。
この脆弱性により、攻撃者はメモリを破壊し、不正なWebAssemblyペイロードを通じて任意のコードを実行できる可能性があった。
「Aisleの自律型AIシステムは、WebAssemblyのセキュリティを詳しく分析する中で、この巧妙な境界条件の脆弱性を発見しました。これにより、およそ1億8000万人のFirefoxユーザーに重大なメモリ安全性リスクがあることが明らかになりました」と、AISLEの創業者兼チーフサイエンティストであるStanislav Fort氏は述べた。
同氏はさらに、「Mozillaは迅速に修正プログラムをリリースしました。現代のブラウザーは、現存するプラットフォームの中でも最も安全で、厳密に設計されたものの一つです。今回の発見は、世界中のユーザーを守るために、AIを活用した継続的なセキュリティ研究が重要であることを示しています」と付け加えた。
Firefoxユーザーを危険にさらした、隠れたコードエラー
この脆弱性（CVE-2025-13016）の核心にあるのは、FirefoxのWebAssemblyガベージコレクション（GC）実装、具体的にはStableWasmArrayObjectElementsクラスに存在する、微妙なポインター演算のミスだ。ポインター型が一致していなかったため、インライン配列データが誤ってコピーされていた。
この脆弱なコードは、コピーするデータ量の計算にバイト単位のポインター（uint8_t*）を使用していたが、コピー先はuint16_t型のバッファーだった。
テンプレートが16ビット値用にインスタンス化されると、std::copy()はバイト単位の範囲をバイト数ではなく、型付き要素の数として解釈した。
その結果、N個の16ビット要素を格納するはずのバッファーに、実際には2N個の要素が書き込まれ、スタックメモリを超過して隣接するデータ構造が破壊された。
この問題は、2つ目の欠陥によってさらに悪化した。コピー操作が正しいメモリ位置から読み取っていなかったのだ。
配列のデータ領域専用のポインターを使う代わりに、コードはinlineStorage()からデータを取得していた。ここは内部オブジェクトメタデータから始まる領域だ。
つまり、バッファーに最初にコピーされたバイトは配列の内容ではなく、WebAssemblyオブジェクト自体の構造情報だった。このため予測不能性が増し、破壊されたメモリが攻撃時に悪用される可能性も高まる。
攻撃者がこのFirefoxのバグを悪用するために必要な条件
Firefoxのすべての実行経路がこの欠陥のあるルーチンに到達するわけではない。そのため、この脆弱性は長期間発見されなかった。
この問題が発生するのは、WebAssembly配列を処理するために使われる、GCが有効な低速のフォールバック経路にFirefoxが移行した場合だけだ。具体的には、配列を文字列に変換する際に発生する。
典型的な処理では、まずWebAssemblyコードが配列を操作する。例えばchar16_t配列などだ。
その後Firefoxは、ガベージコレクションを回避するよう設計された高速経路の処理を使って、その配列を文字列に変換しようとする。
しかし、メモリ圧迫など特定の条件によって高速経路が失敗すると、ブラウザーはGCが許可されたフォールバックルーチンに移行する。
このフォールバック処理の中で、Firefoxは脆弱性のあるStableWasmArrayObjectElementsコンストラクターを呼び出す。これが欠陥のあるコピー操作を実行し、最終的にスタックをオーバーフローさせて隣接するメモリを破壊する。
実際の攻撃シナリオでは、攻撃者が悪意のあるWebAssemblyモジュールを意図的に作成し、この処理の流れを自分に有利なように操作できる。
特定のサイズの配列を作成し、意図的にブラウザーをメモリ圧迫の状態にしてガベージコレクションを強制し、配列から文字列への変換処理を繰り返し実行することで、攻撃者はFirefoxを脆弱なフォールバック経路に確実に誘導できる。
これにより、メモリ破壊の結果をスタック上の任意の標的に向けられる、制御された環境が生まれる。
Firefoxの脆弱性に対する緩和策
組織は、最新のFirefoxパッチを適用するとともに、攻撃者のアクセスを制限し、悪用の可能性を封じ込め、ブラウザーのセキュリティを強化する多層防御策を追加で実装することで、脆弱性への露出を抑えられる。
- Firefox 145以降を優先的に導入する（またはESR 140.5以降）すべてのシステムに適用し、組織全体でバージョンの準拠状況を確認する。
- 企業向けブラウザー管理ポリシーを適用することで、高リスク機能を制限し、サンドボックス制御を強化し、重要なセキュリティ設定を厳格に管理する。
- WebAssemblyを一時的に無効化するパッチを直ちに適用できない環境で実施する。特に、攻撃への露出度が高いエンドポイントでは重要だ。
- ブラウザーのログ、EDRシグナル、クラッシュ分析を監視し、WebAssembly関連のメモリエラーや、Firefoxプロセスの異常な挙動がないか確認する。
- ネットワークレベルの防御を利用する――DNSフィルタリング、セキュアWebゲートウェイ、ドメインレピュテーションツールなどにより、悪意のある、または疑わしいWebコンテンツをブロックする。
- ブラウザー分離を導入するか、高リスクなブラウジング活動を分離し、信頼できないサイトに日常的にアクセスするユーザーからの脅威を封じ込める。
- エンドポイントとOSの防御を強化することで、エクスプロイト緩和設定、アプリケーションサンドボックス、厳格な最小権限アクセス制御を適用する。
これらの対策を組み合わせることで、サイバーレジリエンス全体を強化できる。
CVE-2025-13016が示す、より大きなセキュリティ上の教訓
この脆弱性は、ブラウザーがWebAssembly GCのような、ますます複雑化する低レベル技術を採用する中で生じるリスクの高まりを浮き彫りにしている。
C++のようなメモリ安全性のない言語におけるわずかなミスでさえ、従来のコードレビューや回帰テストをすり抜ける深刻度の高い欠陥につながり得る。今回のバグは独自のテストとともにリリースされていたにもかかわらず、6カ月間発見されなかったことがその証拠だ。
今回のインシデントは、従来のQAプロセスでは見落とされがちな微妙なメモリ問題を特定するうえで、自律型分析ツールが重要であることも示している。
WebAssemblyが現代のWebアプリケーションにさらに深く組み込まれるにつれ、ブラウザーベンダーと企業はいずれも、低レベルのメモリエラーを防止・検出するため、より強固な安全対策に投資する必要がある。
成熟したパッチ管理プログラムを維持することが、ブラウザーのリスクから身を守るうえで重要である理由は、今回の脆弱性が発見されないまま長期間存在していたことからも明らかだ。