Mythos 0、AISLE 29 — curl が暴いた脆弱性発見の本当の律速

概要

2026年9月2日、curl 8.22.0 がリリースされた。同時に10件の CVE が公表され、そのうち6件は AISLE という専業スタートアップの自律エージェントが報告したものだった。

その1週間前、curl 作者の Daniel Stenberg は同じコードベースに対する別の結果を公開していた。 Anthropic の Mythos と OpenAI の Codex Security を走らせ、どちらも新規の脆弱性をゼロ件で返した、と。

Stenberg はスコアボードの形で書いた。

Mythos: 0 Aisle: 29 — Daniel Stenberg, curl 作者

29 は AISLE が数日で提出した報告の件数である。うち6件が curl のセキュリティチームの査読を通り、CVE 番号を得た。

同じ 176,000 行の C コードに、フロンティアラボの最新モデルは何も見つけられず、スタートアップのシステムは6件見つけた。この差は、モデルの大きさでは説明できない。

詳細

公開されたスコアボードという珍しさ

この比較が意味を持つのは、順序が公開されていたからである。

Stenberg は AISLE が走る前に、Mythos と Codex Security の空の結果をタイムスタンプ付きで公表していた。後追いの主張ではなく、事前に固定されたベースラインがある。

日付	出来事
8月24日	Stenberg が Mythos と Codex Security のゼロ件結果を公開。AISLE が3件報告
8月26日	AISLE が2件報告
8月27日	AISLE が1件報告
9月2日	curl 8.22.0 リリース。AISLE 由来の6件を含む10件の CVE を公表

セキュリティスキャナのベンチマークは、通常この形にならない。既知の CVE を埋め込んだ人工的なデータセットで測るか、ベンダー自身の集計を信じるかのどちらかになる。本番のコードベースに対して、複数のシステムを既知の順序で走らせた記録は珍しい。

6件は地味な穴だった

curl 8.22.0 の CVE は、すべて Low 深刻度である。報告者としては AISLE の Stanislav Fort がクレジットされている。

CVE	内容
CVE-2026-80229	OpenSSL provider の use-after-free
CVE-2026-80230	証明書 pinning のバイパス
CVE-2026-80231	OS 標準 CA ストア利用時の接続再利用
CVE-2026-80255	タブ文字による secure cookie 属性のバイパス
CVE-2026-82208	wolfSSL の CA キャッシュヒットがコールバックを上書き
CVE-2026-82209	PSL ドメインへのドメインスコープ cookie

派手なリモートコード実行はない。接続再利用の条件判定、cookie 属性のパース、キャッシュとコールバックの優先順位といった、境界条件の取り違えが並ぶ。

この種の欠陥は、人間のレビューが最も見落としやすい。 1関数だけを読んでも間違いに見えず、複数のモジュールにまたがる状態の組み合わせを追わないと成立しないためである。

6月の curl 8.21.0 では、AISLE は別の6件を報告していた。そのうち CVE-2026-8932 は、2001年3月22日の curl 7.7 で混入した接続再利用の欠陥である。 25年以上、30億台規模のデバイスに配られながら誰も気づかなかった。

AI slop が先に壊したもの

同じ技術が、その半年前には curl のセキュリティ運用を壊していた。

curl のバグバウンティは2019年4月に始まり、6年で10万ドル以上を支払い、87件の実脆弱性を確認した。それが2026年1月31日に終了した。

原因は LLM で生成された報告の量である。

指標	バウンティ健全期	2025年
実脆弱性の確認率	15% 超	5% 未満
完全な捏造報告の割合	ほぼなし	約20%
週あたり報告数	数件	2025年半ばで週2件、2026年初頭は16時間に7件
査読体制	ボランティア7人	同じ7人

Stenberg はこれを death by a thousand slops と呼んだ。 1件の捏造報告は、それが捏造だと確定するまで人間の数時間を消費する。報告が長く、自信たっぷりで、C の用語を正しく使っていればなおさらである。

圧力は2026年夏まで続いた。 curl は7月1日から8月3日まで、有償サポート契約者以外からのセキュリティ報告の受付を止めた。 Stenberg はその休止を summer of bliss と名付けている。

As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. — Daniel Stenberg, curl 作者

curl 8.22.0 のリリースが予定から2週間ずれたのは、この休止の帰結である。

つまり同じ2026年のうちに、AI 生成の報告が curl の査読能力を飽和させ、AI 生成の報告が curl の25年物の欠陥を掘り出した。技術は同じで、結果が反対を向いた。

差はモデルの大きさではない

では Mythos と AISLE の差はどこから来たのか。

AISLE は自社を model-agnostic と説明している。特定のフロンティアモデルに賭けず、複数のエージェントで triage、修正、検証を回すパイプラインを持つ。 API コールを一切せず、完全にオンプレミスで動く構成も選べる。

Stenberg は5月時点で、Mythos の結果をこう評価していた。

My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. — Daniel Stenberg, curl 作者

このとき Mythos は5件を主張し、curl のチームが精査して1件だけが実脆弱性として残った。残りは false positive 3件と、脆弱性ではない通常のバグ1件である。

ここに構造が見える。生のモデルに「この 660,000 語のコードから脆弱性を探せ」と投げる方式は、探索の当てが外れれば何も返さない。検出、再現、深刻度判定、パッチ生成を別々のエージェントに割り、失敗した仮説を捨てながら回す方式は、当てが外れても次の仮説に進む。

観点	フロンティアモデル単発方式	多エージェントパイプライン方式
実行単位	1回の長い推論	検出、再現、検証、修正の分割
失敗時	空のリストを返す	仮説を捨てて次を探索
出力の質	主張のみ。人間が再現を担う	再現手順とパッチを添える
実行環境	ベンダー API	オンプレミス構成が可能
curl での結果	Mythos 5件主張 → 実1件、8月は0件	29件提出 → CVE 6件

AISLE は curl 以外でも同じ結果を出している。 OpenSSL では12件の CVE を報告し、うち1件は約30年前の欠陥だった。 30以上の主要 OSS に対して225件以上を開示し、UC Berkeley の Vulnerability Detection Benchmark では CVE 件数、CWE の広さ、MITRE Top 25 の網羅の3部門で1位に付けている。

脆弱性発見の性能を決めるのは、モデルのパラメータ数ではなくパイプラインの設計だという主張が、公開された比較で裏付けられた形になる。

律速は発見から修正へ移った

発見が安くなると、次の工程が詰まる。 2026年前半の数字がそれを示している。

主体	発見した候補	公表 CVE	修正確認	転換率
Anthropic Project Glasswing	23,000	126	97	約0.5%
Palo Alto NOVA	14,090（2ヶ月、3,915プロジェクト）	公表待ち	未公表	未確定
AISLE（curl 8.22.0）	29	6	6	約21%

Glasswing の 23,000 件から公表 CVE になったのは 126 件、実際にパッチが確認されたのは 97 件である。 NOVA が2ヶ月で挙げた 14,090 件は、99.4% が未報告の新規で、約40% が high か critical に分類されている。

この数字を、curl のボランティア7人という査読体制の横に置くと問題の形が見える。候補を出す側は機械の速度で動き、確定させる側は人間の速度で動く。差は縮まらず、開く。

AISLE の転換率が相対的に高いのは、報告に再現手順とパッチを添えているためである。 6月の curl 8.21.0 では、報告した6件のうち3件にパッチを提供した。メンテナ側の作業を、確認と取り込みだけに縮めている。

発見の価値は下がり、検証済みで修正案付きの報告の価値が上がる。バグバウンティが「発見」に報奨金を払う制度だったことを踏まえると、curl が2026年1月にそれを閉じたのは制度設計の順当な帰結だった。

CVE 番号を誰が振るのか

制度側の変化も動いている。

2026年7月22日、AISLE は CNA（CVE Numbering Authority、CVE 番号を自ら割り当てられる組織）に指定された。 AI 専業企業としては初である。 Anthropic もその6日後に指定を受けた。

ただし CNA の権限は自社製品に限られる。 AISLE が OpenSSL に見つけた欠陥に、AISLE が自分で CVE 番号を振ることはできない。番号の割り当ては、これまでどおり製品側のメンテナか上位の root にとどまる。

さらに AISLE は CISA と MITRE の系列ではなく、ENISA（欧州連合サイバーセキュリティ機関）の root 配下に入った。 ENISA 配下の CNA は20組織で、うち8組織は MITRE root から移管されたものである。 CVE 制度の調整が複数 root にまたがる構図が、AI 発見の増加と同時に進んでいる。

制度が拡張しても、律速は動いていない。番号を振る前段の査読が人間に残るかぎり、発見の増加はそのまま公表の増加にはならない。

日本への示唆

この事案は、日本の開発現場に3つの具体的な課題を残す。

第一に、少人数 OSS のメンテナが同じ砲火を受ける。 curl は7人のボランティアで飽和した。日本発の OSS は、メンテナ1人か2人という規模が普通である。報告の受付窓口を持つなら、捏造報告を人間が読む前に落とす仕組みを先に用意する必要がある。再現手順とパッチの添付を必須にする、有償契約者を優先する、受付を期間で閉じるといった手段は、curl が実際に取った選択肢である。

第二に、IPA の脆弱性関連情報の届出制度も、人が読む前提で設計されている。 JVN iPedia の日本語版登録は2026年第2四半期で累計 290,167 件に達し、AI ツール自体の脆弱性登録も増加傾向にある。発見側が機械の速度に移った以上、受付側の三分作業を機械に寄せるかどうかが制度の処理能力を決める。

第三に、オンプレミス実行が日本企業にとって現実的な差になる。

制約	ベンダー API 方式	オンプレミス方式
自社ソースの外部送信	発生する	発生しない
金融・製造の社内規程	審査が必要	既存の閉域で完結
監査証跡	ベンダー側に依存	自社で保持
適用対象	送信可能なコードのみ	レガシー資産まで含む

ソースコードを外に出せないという制約は、日本の金融と製造で日常的な条件である。 AISLE が API コールなしの構成を選べると明示しているのは、この層に直接効く。

そして最も重い含意は、コードの棚卸しが終わっているという前提が崩れることである。 25年前に混入した欠陥が読まれ、30年前の OpenSSL の欠陥が読まれた。日本の長寿システム、とりわけ銀行の勘定系と製造業の組み込みは、この年代のコードを本番で動かし続けている。これまで「誰も見ていないから見つからない」で守られてきた資産が、機械の読解速度に晒される。

守る側が先に読むか、外から読まれるかの順序だけが選べる。

まとめ

2026年9月2日リリースの curl 8.22.0 で10件の CVE が公表され、うち6件は専業スタートアップ AISLE の自律エージェントが報告した
同じコードベースに対し、Anthropic Mythos と OpenAI Codex Security は8月24日時点で新規脆弱性をゼロ件で返している。順序が公開された珍しい比較になった
差の源はモデルの大きさではなく、検出、再現、検証、修正を分割して回す多エージェントパイプラインの設計にある
同じ技術が半年前には curl のバグバウンティを潰した。実脆弱性の確認率は 15% 超から 5% 未満へ落ち、約20% が完全な捏造報告だった
律速は発見から修正へ移った。Anthropic Glasswing は 23,000 件の候補から公表 CVE 126 件、パッチ確認 97 件にとどまる
報告の価値は「見つけたこと」から「再現手順とパッチが付いていること」へ移る。AISLE の転換率が高いのはこの差である
日本への示唆は、少人数 OSS メンテナの防衛、IPA 届出制度の処理能力、オンプレミス実行の実用性、そして長寿コードの棚卸し前提の崩壊の4点にある

発見が安くなった世界で守りを固めるのは、賢いスキャナを買うことではない。機械が出す大量の候補を、人間が詰まらずに確定させる工程を先に作ることである。

概要

詳細