重み公開AI、Firefoxの修正から攻撃を自作 Epoch調査

AI の研究機関 Epoch AI が10月29日、AI can turn security fixes into working exploits before users receive an update という報告を出しました。重みが公開されている Z.ai の GLM 5.3 だけで、Firefox の最新版を狙う攻撃コードを作れたという内容です。モデルは公開されたセキュリティ修正の中身を読み、まだ更新していない利用者を狙う攻撃を、人の手を借りずに組み立てました。9月中旬から10月下旬までの6つの版すべてで、Web ページを開くだけで手元のファイルを読まれる状態を再現しています。かかった API 費用は1つの版あたり約1,000ドルでした。

背景と文脈
技術/ビジネス面
開発者として試すなら
これからどうなるか
まとめ
参考リンク

背景と文脈

修正が公開されてから利用者の手元に届くまでの間を、パッチギャップ（patch gap）と呼びます。オープンソースのソフトでは、直したコードが先に公開リポジトリに入ります。配られている版が古いままでも、修正の差分を読めば、どこに穴があったかがわかってしまいます。昔から知られた問題ですが、差分から実際に動く攻撃コードを作るには、熟練した人が何日もかける必要がありました。

この手間を AI が肩代わりし始めています。Mozilla は2026年春、Anthropic の Claude Mythos Preview を使った仕組みで Firefox のコードを調べ、Firefox 150 で271件のセキュリティバグを直したと公表しました（Help Net Security の報道）。Anthropic も、Mythos が Windows のようにソースが公開されていないソフトでパッチギャップを突けたと示しています。ただ、どちらも一般には配られていない最先端のモデルの話でした。

今回の調査は、誰でもダウンロードして動かせる重み公開モデル（オープンウェイトモデル。学習済みのパラメータが配布され、自分の環境で動かせるモデル）でも同じことができるかを確かめたものです。自分の環境で動かせば提供元の安全対策を通らないので、悪用を止める手段は限られます。

技術/ビジネス面

実験の環境は、Ubuntu 26.04 の標準設定に公式の Firefox を入れたものです。モデルには対象の版番号と基本的なツール、その版が出る前に公開されていた情報だけを渡し、インターネットにはつなぎませんでした。あとから公開された脆弱性を使えないようにするためです。人が出した指示は、パッチギャップを狙うことだけでした。どの修正を使うかの選択から攻撃の組み立てまで、モデルが自分で進めています。

攻撃は2段構えです。Firefox は Web ページを処理するプロセスを、サンドボックス（ほかの部分に手を出せないよう権限を絞って閉じこめた実行環境）の中で動かしています。モデルはまず、パッチギャップにある脆弱性を使って、このプロセスの中でコードを動かしました。次に、まだ公表されていなかった別の脆弱性でサンドボックスを抜け、ファイルを読み出しています。この未公表の脆弱性はモデルが試すたびに見つけ直したもので、Mozilla に報告され、10月27日の Firefox 159.0 で直りました。

Mozilla が修正をふつうの改良に見せかけて公開していても、モデルはコードを読んでセキュリティの修正を見分けました。Z.ai の公式 API などを通して使いましたが、提供元の安全対策で止められたことは一度もなかったそうです。Chrome にも約10万ドルをかけて同じ攻撃を試しましたが、こちらは成功していません。

開発者として試すなら

開発者がすぐにできるのは、手元のソフトの更新が遅れていないかを確かめることです。修正が公開されてから攻撃コードができるまでの時間が、とても短くなっています。調査の数字は次のとおりです。

項目	Firefox	Chrome
対象	156.0〜158.0.1 の6版	最近の版
結果	6版すべてでファイルの読み出しに成功	成功なし
かかった時間	最短約12時間（1回の上限は48時間）	なし
API 費用	1版あたり約1,000ドル（準備を含む総額は10万ドル超）	約10万ドル

まず、手元と社内の端末で Firefox の版を確かめます。メニューの「ヘルプ」から「Firefox について」を開くか、端末で firefox --version を実行すれば表示されます。159.0 より古ければ、今回狙われた版と同じ状態です。会社で一括配布している場合は、Mozilla の企業向けポリシー（policies.json）で自動更新を止めていないかも見ておきます。DisableAppUpdate が true のままだと、利用者は修正を受け取れません。

オープンソースを公開している側は、Epoch が挙げた対策をそのまま使えます。セキュリティ修正は出荷の準備ができるまで公開しない、ベータから正式版までの期間を縮める、組み合わせると攻撃に使える複数の修正を同じリリースにまとめない、の3つです。Hacker News のこの報告への議論では、Mozilla の担当者が、パッチギャップを完全になくすのは無理だと書いていました。そのうえで、Web ページを処理する部分の修正と、サンドボックスの外に出られる穴の修正が同じ時期に公開状態にならないよう調整していると説明しています。

ただし、この結果には条件があります。攻撃が成功したのは、サンドボックスの外に出られる、まだ公表されていない脆弱性があったからです。159.0 でそれが直ったあとも同じことができるかは、確かめられていません。Chrome で成功しなかったことも、Epoch 自身は Chrome が安全な証拠とは見ていません。逆に、実験はネットにつながない環境で行っていて、制限のない攻撃者ならもっと安く済むとも書いています。

これからどうなるか

更新の間隔が短いソフトほど、この攻撃に強くなります。Epoch によると、Firefox と Chrome はすでに毎週の更新に移りました。危ないのは更新が遅いソフトで、Epoch はルーターのファームウェアやスマートフォンの OS を例に挙げています。

開発者は、依存ライブラリに修正版が出たら、すぐに適用しないといけません。修正版が出ても数週間は様子を見てから入れる、というやり方だと、その間に AI で攻撃コードを作られてしまいます。Dependabot や Renovate では、セキュリティ更新をほかの更新と分けて、すぐ取りこむ設定にしておけます。公開しているライブラリなら、修正のコミットメッセージに脆弱性の中身を書かず、リリースと同時に GitHub Security Advisory を出す流れが合っています。ふつうの改良に見せかけた修正もモデルに見抜かれたので、隠すより、早く出荷するほうが役に立ちます。

守る側も同じモデルを使えます。Hacker News の Mozilla の担当者は、バグの数には限りがあり、すべてのコミットをモデルで調べ続ければ守る側が有利になると書いていました。Mozilla は春の時点で、AI による調査を CI（継続的インテグレーション。コードを入れるたびに自動でビルドや検査を回す仕組み）に組み込み、入ってくる修正ごとに調べる計画を示しています。重み公開モデルなら、自社のコードを外に出さずに同じ調査を回せます。

まとめ

Epoch AI は、重み公開の GLM 5.3 が Firefox の公開された修正を読み、6つの版で手元のファイルを読み出す攻撃を作れたと報告しました。費用は1版あたり約1,000ドル、最短12時間です。使う側はブラウザと依存ライブラリをすぐ更新すること、作る側は修正を公開してから出荷するまでの期間を縮めることが、いまできることです。ただし、まだ公表されていない脆弱性があったから成功した点と、Chrome では成功していない点も、あわせて見ておく必要があります。

ぽこのひとこと

攻撃する側は、AI のモデルを使ってどんどん攻撃コードを作れます。それに対して、更新する側は、一人ひとりがきちんとパッチを適用しないといけません。どこかで適用が漏れていれば、そこが狙われるので、かなり攻撃されやすい状況だと思います。だからといって、今さらデータを外に出さないようにするのは無理なので、みんなに更新してもらうしかありません。

記事の最後に、守る側も同じモデルを使えるという話があります。ソフトを作っている人が自分で守るだけなら、それでできると思います。ただ、そのソフトを使っている全員が更新しないといけないところが、大きなハードルだと感じました。