「AIが穴を見つけてくれるなら、守る側が有利になるんでしょ？」そう思ってる？ 半分は当たってる。残りの半分が、先週まとめて出てきた。
前回の記事では肩の力を抜いて、AIの文章の癖を数えた。今日は重いほうに戻る。Googleが最上位モデルを守る側にだけ渡した話を書いたとき、私は「見つけた」ところで話を止めていた。見つけた穴は、そのあとどうなるのか。週末に出た2本の記事が、その続きを別々の方向から持ってきた。
水曜に公開、木曜の夜にはもう来ていた
1本目は10月3日のThe Register。
登場するのはAnthropicのMythos。穴探しが得意なモデルで、Anthropicは強すぎて一般には出せないと言っている。4月に発表したProject Glasswingという枠で、選んだ相手にだけ使わせている（The Register）。守る側にだけ渡す、というやり方の先輩だ。
その相手のひとつが、AIで侵入テストをする会社Horizon3。7月に枠に入った。9月30日の水曜、同社の研究者Zach Hanleyが、Mythosで見つけた欠陥を公開した（Horizon3）。場所はRejetto HFS。ファイルを手軽に置いて共有できる、オープンソースのサーバーソフトだ。番号はCVE-2026-61500。ログインをすり抜けて管理者になれて、そのままサーバーの上で好きなコードを動かせる。Hanleyは手順を見せる動画も出した（The Register）。
翌日の木曜。穴の悪用を見張っている会社VulnCheckのPatrick Garrityが、LinkedInにこう書いた。
「今晩、Rejetto HFSのCVE-2026-61500が突かれているのを検知し始めた」（The Register、原文は英語）
最初に来たのは中国にあるIPアドレス1つ。狙われたのは米国と日本にある、まだ直していないサーバーだった。金曜には、米国の2つのIPアドレスからさらに4回。この2つは同じ区画にあって、中継を通しているように見える、とGarrityは話している（The Register）。
公開から1日。使っている人がみんな更新を入れ終わるより先に、もう誰かが扉を叩いていた。HFSを動かしている人は、3.2.1以降に上げてほしい（The Register）。
人間は気づいていた。面倒だから追わなかった
この穴、中身がちょっと変わっている。
HFSは、ログイン済みの印に署名する鍵を、起動のときにMath.random()という乱数で作っていた。これは安全のための乱数じゃない。出てきた数をいくつか続けて見れば、中の状態を逆算できる。しかもHFSは、別の場所でその乱数を外にそのまま見せていた（Horizon3）。
Mythosはこの2つをつないだ。漏れている乱数を12回集める。そこから中の状態を解く。起動の瞬間まで巻き戻して、鍵を作り直す。その鍵で管理者の印を偽造する。使ったのは、Microsoftが公開している、条件に合う答えを探すための道具Z3だ。Mythosは動く実証コードまで自分で書いて、任意の命令が通るところまでやって見せた（Horizon3）。
ここでHanleyが、正直すぎることを書いている。こういう弱い乱数の使い方は、これまで何度も見つけてきた。でも、実害を証明するところまで追うのは早々にやめていた。理由は2つ。自分たちには暗号の深い数学の素養が無い。そして、理解して手口に仕上げるまでに時間がかかる穴は、後回しになる（Horizon3）。
続きはこうだ。
「Mythosは、この2つの理由をどちらも消す」（Horizon3、原文は英語）
これ、読み流せない。穴はずっとそこにあった。人間は気づいてもいた。守っていたのは鍵じゃなくて、「割に合わない」という手間のほうだった。その手間が消えた。
Horizon3は同じ文章で、反対側のことも書いている。こういう能力があれば、狙う側が大量に使える手口に仕上げようとする穴の種類が変わる。前なら複雑すぎて当てにならなかった穴も、手間がかからないなら使われる、と（Horizon3）。見つける側の手間が消えたなら、突く側の手間も消える。同じ道具の話だから。
ただ、数字は公平に置いておく。GarrityはMythosとGlasswingが見つけた穴を数え続けていて、金曜の時点で286件。そのうち実際に突かれたと分かっているのは、木曜まで1件だけだった。今回が2件目だ（The Register）。286件のうち2件。数だけ見れば、先に見つけて先に塞ぐ側が大きく勝っている。問題は、負けた2件のうち新しいほうが、1日で来たことだ。
同じ木曜、Googleは窓口を閉めた
2本目は10月4日のTechCrunch。
Googleには、自社のオープンソースの穴を外の研究者が見つけて報告すると報奨金を払う仕組みがある。10月1日、Googleはその受付を止めた。公式アカウントの告知はこうだ。製品の欠陥についての報告は、一時的に受け付けない。供給網まわりの報告と、すでに出ている報告には影響しない（Google VRPのX投稿）。次の知らせは2027年の1〜3月に出すという（TechCrunch）。
理由としてGoogleが挙げたのは、この一文だ。
「今回の停止は、自動で作られた報告が大きく増えたためで、その大半は有効ではない」（TechCrunch、原文は英語）
Tom's Hardwareは10月3日の記事で、Googleの技術者とオープンソースの保守担当が、実際には成り立たない報告や、もっともらしいだけで中身の無い報告の確認に時間を取られ、本物の穴を直す時間が削られていたと報じられている、と書いている。同じ記事によると、Linuxの保守担当も、AIを使った穴探しが持ち込む報告に「完全に手一杯だ」と話している。
日付を並べてみてほしい。10月1日の木曜。片方では、AIが見つけた本物の穴が、公開の翌日に突かれ始めた。もう片方では、自動で作られた成り立たない報告が多すぎて、Googleが本物を受け取る窓口ごと閉めた。
そしてその前日の9月30日、Googleは自分の最上位モデルを「守る側に制限なしで渡す」と発表している。自社のAIには穴を探させる。外から届く自動の報告は、もう読み切れない。同じ会社の、同じ週の話だ。筋は通っている。通っているけど、ちょっと苦い。
割り引いて読むところ
いい話にも怖い話にも、しすぎない。
Horizon3の文章は、AIで侵入テストをする会社が自社のサイトで出したものだ。Mythosを褒めるほど、自分たちの商売にも効く。IPアドレスが中国にあるというのは、誰がやったかを言っているわけじゃない。Garrityが伝えたのは、狙う動きを検知した、というところまでで、実際に入られたサーバーがあるという話は、私が読んだ範囲には出ていない。
Googleの側も、数は出していない。何件届いて何件が無効だったのか、公式には「大半」としか言っていない。それに、Googleの言葉は「自動で作られた報告」だ。AIと名指ししているのは、伝えた媒体のほうになる。
今日の本音
2つの話は、根っこが同じだ。手間が消えた。数学が要るから誰も追わなかった穴を、モデルが自分で最後まで仕上げる。報告書を1通書く手間も消えたから、窓口には当たりも外れも一緒に流れ込む。
消えなかった手間が、ひとつだけある。確かめる人、直す人、更新を入れる人の時間だ。ここだけは先週も今週も、人間の速さのまま動いている。
「守る側にだけ渡す」は、モデルの配り方としては正しいと思う。でもそれは入口の話だ。見つけた穴は、直すために公開される。公開された瞬間から、時計は全員に対して同じ速さで回る。先週わかったのは、その時計が1日で鳴ることがある、ということだ。
参考・引用記事
- Anthropic's super bug-hunting model Mythos is hardcore good at math, as latest vuln under attack shows（The Register、2026年10月3日）
- Horizon3's Tales from the Trenches: Anthropic's Mythos and Rejetto HFS（Horizon3、2026年9月30日）
- Google froze its open source bug bounty program due to a 'significant rise' in AI submissions（TechCrunch、2026年10月4日）
- Google freezes open-source bug bounty program amid flood of invalid AI slop submissions（Tom's Hardware、2026年10月3日）
- Google VRPの告知（X、2026年10月1日）
