Claude Opus 4.6の500件のゼロデイ：3つのパッチが示すもの

2026年2月5日、AnthropicのFrontier Red Teamは、同日リリースされたClaude Opus 4.6が発見し検証したとする研究を公開した。その対象は500件を超える重大度の高い脆弱性で、オープンソースソフトウェア内のものだった——タスク固有のツール、カスタムスキャフォールディング、専門的なプロンプトは使用していない。3件の所見が詳述されている：Ghostscriptのスタック境界チェックの欠落、OpenSCにおける未チェックの一連のstrcat呼び出し、そして辞書が満杯になった際のLZW圧縮の挙動に左右されるGIFエンコーダーCGIFのバッファオーバーフローである。Anthropicは、3件とも現在はメンテナーによって修正済みであり、同社の説明ではバグは発見、検証、報告されたという。投稿によると、多くのプロジェクトは専任のセキュリティ担当者のいない小規模チームやボランティアによって維持されているため、報告とパッチの負担が彼らにのしかかった。この発見に関するアーカイブ自身の項目は、実際の被害が記録されていない情報レベルの重大度に分類され、Orca AI Incident Archive内で他の2026年2月のポリシーおよび開示記録と並んでいる。

Anthropicが実際に公開したもの

投稿のタイトルは「LLMが発見した0デイの増大するリスクを評価し軽減する」で、Frontier Red Teamによるもので、Nicholas Carlini、Keane Lucas、Evyatar Ben Asherが同等の貢献者として、Newton Cheng、Hasnain Lakhani、David Forsythe、Kyla Guruとともにクレジットされています。ページには2026年2月5日の公開日と、2026年2月6日付で著者リストが更新されたことを記録する編集注記があります。アーカイブはこの投稿をred.anthropic.comで引用しており、このURLは現在anthropic.com/research/zero-daysにリダイレクトされます。

方法は見出しの数字よりも重要だ。Anthropicによると、同社はモデルをオープンソースプロジェクトの最新版にアクセスできる仮想マシン内に置き、標準ユーティリティと、人間のセキュリティ研究者が使うようなツール——デバッガーやファザー——を与えたが、それらの使い方に関する指示はなく、投稿の言葉を借りれば「脆弱性をよりうまく見つける方法について専門知識を与えるようなカスタムハーネス」もなかった。テストされていたのは、モデルの初期設定のままの挙動だった。

チームは検索対象をメモリ破壊系のバグに絞り込んだ。クラッシュのほうが論理エラーより確認しやすいという理由からだ。Anthropicはこれがフィルターであり保証ではないと明言している。「プログラムをクラッシュさせる入力のすべてが高深刻度の脆弱性というわけではない」。そこでクラッシュはモデルに戻され、批判・重複排除・優先順位の再設定が行われ、その後人間の手に渡った。「初期の調査結果については、当社のセキュリティ研究者が各脆弱性を検証し、パッチを手作業で作成しました。調査結果の量が増えるにつれ、検証とパッチ開発を支援する外部の（人間の）セキュリティ研究者を招き入れました」。投稿によれば、パッチの自動化はまだ構築中だったという。

3つのバグと、その後に続いたパッチ

3つの実例には共通する形がある。自動化ツールはすでに失敗しており、モデルは入力の変異以外の何かについて推論することでバグを見つけた。

• Ghostscript、PostScript および PDF インタープリター。ファジングとその後の手動分析では何も見つからなかった。その後モデルはプロジェクトの Git 履歴を読み、投稿で「Type 1 charstrings に MM blend 値のスタック境界チェックを追加する」と説明されているコミットを見つけ、そのコミット以前のコードが脆弱だったと推論し、同じ対処を受けていない他の呼び出し箇所を探した。そして gdevpsfx.c 内の1箇所 — 投稿は292行目を挙げている — を見つけ、プログラムをクラッシュさせるファイルを構築した。リポジトリはこれを裏付けている。Chris Liddell による2025年9月5日付のコミット 87486fb801 のタイトルは「Type 1 charstrings: add stack bounds checking for MM blend values」である。Ken Sharp による2026年1月26日付の後続の修正コミット 4e392a82 は、フォントコンバーター内のその呼び出しの直前に境界チェックを追加しており、Bug 709080 に対して提出され、その報告のタイトルは「Ghostscript Incomplete fix for Type 1 MM blend stack bounds check」である。2026年2月13日のコミットは、同じコンバーター内の境界チェックを拡張した。どのコミットメッセージにも、誰がバグを報告したかは書かれていない。

• OpenSCは、スマートカードデータ用のコマンドラインユーティリティである。ここでモデルは危険な関数呼び出しを検索し、連続するstrcat操作が4096バイトのfilenameバッファに書き込んでいることを発見した。これは、入力文字列の長さを差し引くサイズ計算の後で、再確認せずにさらに文字列を追加していたためである。投稿は、関係する前提条件のため、既存のファザーがその経路にほとんど到達しなかったと指摘している。OpenSCの2026年1月19日付のコミット33ab343a5cは、追加される文字列が正確に64バイトであることを確認するチェックを追加し、2026年1月25日にマージされたプルリクエスト#3554は、プロジェクト全体で残っていたstrcat呼び出しをstrlcatに置き換えた。その作者はこの関数を「あらゆる静的解析ツールとCVEの磁石」と呼んだ。

• CGIFはGIFエンコーダーです。このライブラリは、圧縮データが常に非圧縮入力より小さくなると想定していましたが、これはほぼ常に正しいことです。モデルは、LZWが固定サイズの辞書を構築し、辞書がいっぱいになるとストリームに挿入されるクリアコードによって「圧縮」出力が入力より長くなる可能性があるため、N+2個のコード用にサイズ設定されたバッファがN+1個を超えるコードを受け取る可能性があると推論しました。投稿によると、特定の操作シーケンスが必要なため、100パーセントの行カバレッジと分岐カバレッジでもこれを検出できない可能性があります。2026年1月19日にマージされ、同日v0.5.1としてリリースされたCGIFのプルリクエスト#84は、まさにこの点を修正しています。「LZWデータサイズの上限計算に、リセット用クリアコードが含まれていませんでした」。

これらの修正は研究が公開される前に反映されていた——CGIFとOpenSCが2026年1月19日、OpenSCが再び1月25日、Ghostscriptが1月26日——そしてAnthropicは投稿の中で、公開前に「それらの報告を開始し、初期のパッチが反映されつつあるのを確認している」と述べていた。リポジトリにはコード変更が記録されているが、誰が報告を提出したかは記録されていない。そのため、モデルの発見とこれらの特定のコミットとの結びつきは、Anthropicの説明と、記述された欠陥が差分とどれほど一致するかに依存している。

OpenSCのバグは本物ではないと言ったメンテナー

個々の指摘に対する公の検証は、Anthropicだけにとどまらなかった。2026年2月17日、OpenSCの貢献者Jakub Jelenは、strlcatの一掃を手がけた人物で、infosec.exchangeでOpenSCの例に対するレビューを投稿し、そのバグは再現できないと主張した：入力文字列は前の行ですでに64バイトであることが確認されていた、と彼は書き、そのため終端文字を含めてバッファは4095バイトに制限されていた。「私は彼らの指摘を論破するために、コードを約1時間眺めた」と彼は書いた。

彼はその後、同じ投稿を編集して異議を取り下げた。編集には「私が見ていたコードのバージョンには、どうやらAnthropicが発見したバグに対する修正がすでに含まれていたようだ」と記され、続けて計算上の点を認めている。「しかし確かに、'fp'に対するstrlen()チェックがなければ、実際にオーバーフローが引き起こされ得る。謙虚に非を認めたよ」。彼が頼りにしていたチェックは、2026年1月19日にOpenSCに追加されたものだった——Anthropicが公開する前、そしてほとんどの読者が探しに行く前のものだ。アーカイブはその記録に異議ありのフラグを立てておらず、ここでは異議は提起した本人によって撤回された。

ガバナンスの半分：プローブ、ブロック、そして90日間

この投稿を単なる研究ノートではなく方針を示す記録にしているのは、投稿の後半部分だ。Anthropicはモデル公開と併せて、サイバー専用のプローブを導入したと述べている。このプローブは応答生成中にモデル内部の活性化を測定するもので、同社はプローブベースの検出を使うよう執行ワークフローも更新したとしている。それは検出にとどまらない。「悪意があると検出したトラフィックのブロックを含むリアルタイム介入を導入する可能性がある」としている。Anthropicはコストも認めており、「これは正当な研究や一部の防御作業に摩擦を生むだろう」と述べ、この件についてセキュリティ研究コミュニティと協力したいとしている。検出率、誤検出率、異議申し立てプロセスは公表されていない。

この投稿は、開示カレンダー自体が今や問題だと論じてもいる。「業界標準の90日間の窓は、LLMが発見するバグの速度と量には太刀打ちできないかもしれない」と述べ、モデルは「まもなく、専門の人間研究者でさえ及ばない速度と規模に達する可能性がある」と警告する。これは、自らが評価される基準の置き換えが必要だと主張するベンダーの言であり、記録の中でも最も長く影響が及ぶ部分である。

その後、何が変わりましたか？

2026年2月20日、AnthropicはClaude Code SecurityをEnterpriseおよびTeam顧客向けの限定研究プレビューとして公開し、オープンソースのメンテナーには無料の優先アクセスを提供した。これは研究から15日後に製品化された機能だった。VentureBeatはこのローンチを報じ、自己検証の前後における誤検知率、修正が適用された開示済み脆弱性とトリアージ中の脆弱性の数、攻撃者による利用と防御者による利用を区別する安全策についてAnthropicに問い合わせたと述べた。同記事は、プロジェクトの主任研究者が対応できず、同社が具体的な攻撃者検知の仕組みを共有することを拒否したと報じた。

パッチもまた動き続け、しかも常に一方向とは限らなかった。Anthropicが説明したアロケーションに対するCGIFの修正は、2026年1月19日にv0.5.1として出荷された。2026年2月21日には、プルリクエスト#103が、まさにその同じアロケーション計算によって導入された32ビット整数オーバーフローを修正し、翌日にはv0.5.2として、最大65,535×65,535ピクセルのGIF向けにリリースされた。境界計算を修復することは、それ自体が境界バグの小さな発生源でもあることが分かった。

数字を正しく読み取ること

Anthropic自身の文言は「500件超の高重大度脆弱性」だ。Anthropicが最初に情報を提供したAxiosは、公開当日にそれらを「500件超のこれまで知られていなかったゼロデイ脆弱性」と表現し、それぞれがAnthropicチームのメンバーまたは外部のセキュリティ研究者によって検証されたと述べた。どちらの表現も同じ集合を指しているが、ベンダー自身の言い回しは一方だけであり、どちらにも一覧、CVEマッピング、重大度分布は添えられていない。件数はAnthropicによるもので、重大度評価もAnthropicによるものであり、投稿で詳しく扱われた3つのプロジェクトだけが公衆に確認できるものだ。

その後に続いた独立系の分析は、主にその数字を額面どおりに受け取り、それが何を意味するかを論じた。Futurum Groupのミッチ・アシュリーは2026年2月24日、この結果は「件数よりも、その手法が何を明らかにするかのほうが重要だ」と書き、真の制約は下流にあると述べた。「より多くの脆弱性をより速く表面化させても、攻撃対象領域は縮小しない。それは、その量を吸収できない下流プロセスの前に、より大きな待ち行列を築くだけだ」。これは発見そのものではなく開示パイプラインへの批判であり、Anthropicが90日間の期間について提起したのと同じ点に行き着く。

記録が立証していない事柄

アーカイブはこの記録を信頼度A、重大度infoと評価しており、実際の被害は記録されておらず、異議フラグもない。この評価は事象がどれだけ文書化されているかに関するもので、根底にある主張がどれだけ監査されたかに関するものではない。その違いは保持する価値がある。Anthropicの外部で500を検証した者はいない。偽陽性率は公表されていない。名前が挙がった3プロジェクトのパッチは実在し日付も特定できるもので、入手可能な最強の裏付けだが、裏付けるのは3つの例であり全体ではない。

残るのは、検証可能な中核と検証不能な残余を伴う、十分に文書化された発表だ。ベンダーが能力を報告し、そのバグ説明と一致する3つの上流diffがあり、モデル層でその能力の悪用を取り締まるという表明がある。アーカイブはそれをポリシーとして分類しているが、それは正しい棚だ。能力の主張は、4つ目のパッチを公開する者によって決着するだろう。