Claude による脆弱性発見｜Chrome・Linux など 5 事例と防御策

はじめに

Anthropic の Frontier Red Team は 2026 年 10 月 27 日、研究記事「Discovering and exploiting vulnerabilities in critical, real-world software with Claude」を公開しました。未公開の社内研究モデルを使い、Chrome、Safari、Android、Windows、Linux で脆弱性を発見し、複数の弱点を組み合わせた 5 つの攻撃チェーンを実証したという内容です。

これまでも AI による脆弱性発見は報告されてきましたが、今回はブラウザーのサンドボックスや OS の防御機構を段階的に越え、実際に動作する攻撃として検証まで行った点が異なります。一方で、事例ごとに攻撃の前提条件や修正状況は異なり、見出しだけを読むと影響範囲を誤解しやすい内容でもあります。

結論として、5 事例はいずれも開発元による修正対応が報告されていますが、Linux の CVE-2026-98432 は upstream で修正済みである一方、2026 年 10 月 30 日時点で Ubuntu と RHEL の修正パッケージは提供されておらず、各ディストリビューションの提供状況と適用状況を個別に確認する必要があります。また、AI が脆弱性の発見から攻撃の組み立てまで担えるようになったことで、パッチ適用までの猶予が短くなる前提で運用と開発プロセスを見直すことが求められます。

Claude が発見した 5 つの脆弱性事例

Anthropic によると、いずれの事例も初期の指示を与えた後、モデルが攻撃チェーンを作成しました。各脆弱性は Anthropic の協調的脆弱性開示ポリシーに沿ってベンダーへ報告され、修正に 90 日、さらに公開アドバイザリーを超える詳細を説明するまでに 45 日の期間を設けています。そのため、研究記事の公開日と各 CVE の公開日・修正日は一致しません。

Chrome: サンドボックスを突破するワンクリック RCE

JavaScript エンジン V8 のメモリ破損を起点に、V8 のメモリ領域サンドボックスの突破と ASLR の回避、renderer プロセスの制御、プロセスサンドボックスの突破を組み合わせた攻撃です。Anthropic の PoC は、標準設定の Chrome でページを読み込んだ数秒後に、追加の操作なしで電卓アプリを起動したとしています。

Anthropic によると、報告した脆弱性のうち 62 件に CVE が割り当てられ、Chrome 156 までに修正されました。すべて深刻度 Critical または High で、うち 13 件がサンドボックス脱出、21 件が renderer の侵害に利用できるものです。62 件は Anthropic が報告した CVE の集計であり、1 つの攻撃チェーンに必要な脆弱性の数ではありません。攻撃チェーン自体は、後述の 4 つの弱点で構成されています。

Safari: コード実行を伴わない同一オリジンポリシーの回避

JavaScriptCore の UAF を起点に、TypedArray を隔離する Gigacage の外側への読み書き、WebContent サンドボックスの IPC の弱点を組み合わせ、最終的にメモリ上の変数を書き換えて同一オリジンポリシーを無効化しました。Safari の履歴や Cookie を読み取り、他のドメインへ認証済みのリクエストを送ってレスポンスを読める状態になるため、ログイン中のメールや銀行サイトの情報にアクセスされる恐れがありました。

この事例の特徴は、任意コード実行に頼らないデータ主体の攻撃である点です。Anthropic は、単体では脆弱性ではなく意図された動作であっても、組み合わせることで悪用可能になる弱点が含まれていたと説明しています。Apple は報告当日に受領を確認し、修正を提供済みです。Anthropic が修正としてリンクしているのはiOS 26.5.2 / iPadOS 26.5.2 のセキュリティコンテンツ（2026 年 6 月 29 日公開）ですが、どの CVE がこの攻撃チェーンに対応するかは明示されていません。

Android: 物理アクセスを前提としたロック画面の回避

盗難などで入手したロック中の Android 端末から、ロックを解除せずに写真などの個人情報を抽出する攻撃です。オープンソース部分のソースコード解析、Google Play 開発者サービスのバイナリーのリバースエンジニアリング、Google Pixel 9 実機での検証を組み合わせ、3 つの脆弱性を連鎖させました。

突破された防御は、ロック中の USB データ転送の制限、端末間転送プロトコルの認可チェック、6 桁コードによるペアリングの確認、USB 転送でファイル内容を送らないための固定チェックです。前提は端末への物理アクセスと USB 接続であり、リモートから任意の Android 端末を解除できる脆弱性ではありません。Google は対応済みとされていますが、CVE 番号やパッチの公開日は記載されていません。

Windows: HTTP/3 に応答するサーバーへのリモート DoS

Windows ネイティブ実装の HTTP/3 に応答するマシンへ数パケットを送るだけで、クラッシュと再起動を引き起こせる脆弱性です。繰り返し送信すれば、サーバーを継続的に利用不能にできます。Anthropic は、こうしたサーバーがインターネット上に数百万台規模で存在すると推定しています。

Anthropic は Windows カーネルの QUIC 実装における領域外読み取りと説明し、Microsoft は CVE-2026-33096（HTTP.sys のサービス拒否の脆弱性、CVSS 3.1 は 7.5、深刻度 Important）として 2026 年 4 月 14 日に修正しました。HTTP.sys は HTTP/3 の QUIC トランスポートに MsQuic を使用しているため、両者は同じ処理経路を別の観点から説明していると考えられます。この脆弱性はバイナリー解析で発見されたもので、Ghidra などで実行ファイルの動作を再現した C プログラムを作成し、そのコードを調査する手順が取られました。

Linux: MPTCP リスナー経由のゼロクリック RCE

MPTCP リスナーを持つ Linux サーバーへパケットを送るだけで、認証やユーザー操作なしに root 権限で任意のコマンドを実行できる攻撃です。根本原因はカーネルのネットワーク処理における競合状態起因の UAF で、1 段階目でカーネルポインターを漏えいさせて KASLR をリモートから回避し、2 段階目でコールバックポインターを書き換えて制御フローを乗っ取ります。

競合に負けてもハンドシェイクが失敗するだけでシステムはクラッシュしないため、攻撃者は成功するまで再試行できます。Anthropic の PoC では、カーネルポインターの漏えいに 48 分、コマンド実行までにさらに 5 分を要しました。

Anthropic はこの脆弱性を CVE-2026-98432 としていますが、CVE レコードは「ipv4: free inet_opt and ireq_opt after an RCU grace period」という IPv4 TCP のソケット処理の修正で、MPTCP には触れていません。Anthropic が実証した MPTCP 経由の攻撃条件と、CVE そのものの影響範囲は分けて考える必要があります。影響範囲と確認方法は後半の「企業の情シス・インフラ担当者が確認すべきこと」で整理します。

AI はどのように複数の脆弱性を組み合わせたのか

今回の研究で重要なのは、個々の脆弱性の発見よりも、防御機構ごとに異なる弱点を見つけて組み合わせ、攻撃の成立まで検証した点です。Chrome の事例を使って、多層防御と攻撃チェーンの関係を整理します。

攻撃チェーンを理解するための用語

サンドボックス

プロセスやメモリ領域の権限を制限し、脆弱性が悪用されても被害を閉じ込める仕組みです。Chrome では V8 のメモリ領域と renderer プロセスの 2 つの層で使われています。

ASLR / KASLR

プログラムやカーネルのメモリ配置をランダム化し、攻撃者が狙うアドレスを予測しにくくする仕組みです。攻撃者は情報漏えいの脆弱性で配置を把握してから、次の段階に進みます。

UAF（Use-After-Free）

解放済みのメモリを参照し続ける不具合です。解放後の領域に攻撃者が用意したデータが置かれると、読み書きや制御フローの乗っ取りにつながります。

競合状態（レースコンディション）

複数の処理が同じデータに同時にアクセスし、実行順序によって結果が変わる不具合です。Chrome の CacheStorage と Linux の事例で悪用されました。

同一オリジンポリシー（SOP）

あるサイトのスクリプトが、別のオリジン（スキーム、ホスト、ポートの組み合わせ）のデータを読み取れないようにするブラウザーの基本的な制限です。

Chrome の攻撃チェーンと突破された防御境界

V8 のメモリ破損だけでは、攻撃者は V8 のサンドボックス内に閉じ込められ、OS 全体を制御できません。Claude は防御境界ごとに別の弱点を見つけ、次の 4 段階で境界を越えました。

各段階の脆弱性は、単体では影響が限定的です。多層防御はこの「単体では届かない」状態を作る設計ですが、層ごとに弱点が 1 つずつ見つかれば境界を越えられます。Safari の事例のように、単体では仕様どおりの動作が組み合わせで弱点になる場合もあります。

防御側から見ると、チェーンのどこか 1 か所が修正されれば攻撃は成立しなくなります。一方で、編集部の見解として、単体の深刻度が低い脆弱性でもチェーンの構成要素になり得るため、「単体では DoS 止まり」「サンドボックス内に限定される」といった理由だけで修正を後回しにする判断は見直す余地があると考えます。

企業の情シス・インフラ担当者が確認すべきこと

Chrome、Safari、Android、Windows の 4 事例は開発元の修正が提供されているため、確認すべきは修正が自社の端末とサーバーに実際に適用されているかです。Linux は upstream で修正済みでも、ディストリビューションの修正パッケージの提供状況が異なるため、利用中の配布元の情報を個別に確認します。以下はいずれも読み取り専用の確認を中心にしています。

ブラウザーとモバイル端末の更新状況

• Chrome は Chrome 156 以降の最新安定版へ更新されているかを確認します。2026 年 10 月 27 日には Windows / Mac 向け 156.0.8078.73/.74、Linux 向け 156.0.8078.73 の追加のセキュリティ更新も公開されています。
• Chrome は更新をダウンロードしても再起動するまで反映されないため、長期間ブラウザーを閉じない利用者の端末に注意します。管理コンソールや資産管理ツールで実際のバージョンを確認する運用を推奨します。
• Apple 製品は、iOS / iPadOS と macOS の Safari をそれぞれ最新のセキュリティアップデートへ更新します。MDM で OS バージョンの分布を確認すると、未適用端末を把握しやすくなります。
• Android 端末は、セキュリティパッチレベルを確認します。Android の事例は物理アクセスが前提のため、紛失・盗難時の端末管理（リモートロック、ワイプ）の手順もあわせて見直しておくと効果的です。

Windows Server の HTTP/3 利用状況（CVE-2026-33096）

Microsoft のアドバイザリーでは、Windows 11（23H2、24H2、25H2、26H1）、Windows Server 2022、Windows Server 2022 23H2、Windows Server 2025 が対象です。MSRC は公開時点で悪用や一般公開を確認していませんが、Anthropic の説明どおり、HTTP/3 で待ち受けるサーバーは認証なしで繰り返しクラッシュさせられる可能性があります。対象 OS であっても、Anthropic が実証した攻撃経路は HTTP/3 に応答するマシンが前提であり、すべての Windows PC が無条件にリモートから攻撃されるわけではありません。

Windows Server 2022 の HTTP.sys では、HTTP/3 はレジストリで有効化する方式です。Microsoft は IIS で HTTP/3 を使う要件の 1 つとして、次のように記載しています。

参考: Microsoft Learn（Use ASP.NET Core with HTTP/3 on IIS）
“The EnableHttp3 registry key is set.”
（EnableHttp3 レジストリキーが設定されていること。）
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/http3

ただし、OS バージョンや構成によって既定値が異なる可能性があるため、レジストリの値だけで判断せず、UDP 443 の待ち受けと更新の適用状況をあわせて確認します。

reg query "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" /v EnableHttp3

Get-NetUDPEndpoint -LocalPort 443 | Select-Object LocalAddress, LocalPort, OwningProcess

Linux の MPTCP とカーネル更新（CVE-2026-98432）

CVE-2026-98432 は Linux 4.4 で混入した IPv4 TCP の競合状態起因の UAF で、2026 年 10 月 15 日に CVE が公開されました。CVSS 3.1 の評価は評価元によって異なります。Linux カーネルの CVE チームは 9.8（攻撃複雑性 Low）とし、Red Hat の CVE ページは 8.1（攻撃複雑性 High）としています。差の主な理由は、競合に勝つ難しさを攻撃複雑性にどう反映するかの判断の違いです。Red Hat は、TCP サービスに到達できる攻撃者が悪用し得ること、IPv6 は主要な問題の影響を受けないこと、TCP リクエストソケットの移行（net.ipv4.tcp_migrate_req=1 など）でも同様の危険があることも説明しています。

つまり、Anthropic が root 権限の奪取まで実証したのは MPTCP リスナーを持つサーバーですが、脆弱性自体は IPv4 TCP の処理にあります。MPTCP を使っていないことを理由に「影響は一切ない」と判断せず、カーネルの修正を適用する前提で計画を立てることを推奨します。MPTCP リスナーの有無は、修正の優先順位を判断する材料として確認します。

参考: Linux Kernel Documentation（Multipath TCP）
“MPTCP is then opt-in: applications need to explicitly request it.”
（MPTCP はオプトインであり、アプリケーションが明示的に要求する必要がある。）
https://docs.kernel.org/networking/mptcp.html

同じドキュメントでは、LD_PRELOAD（mptcpize）や eBPF などでアプリケーションに MPTCP を強制する方法も紹介されています。カーネルの設定だけでなく、実際に MPTCP で待ち受けているソケットを確認します。

sysctl net.mptcp.enabled

ss -Mln

uname -r

カーネルを自前でビルドしている場合、upstream の修正は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3 に含まれています。一方、ディストリビューションの修正パッケージは配布元ごとに提供状況が異なります。2026 年 10 月 30 日時点で、Debian、Oracle Linux（UEK）、SUSE と Amazon Linux の一部カーネルでは修正パッケージが提供されています。Ubuntu は各リリースの linux パッケージが「Vulnerable」（修正作業中を含む）で、修正パッケージは未提供です。RHEL 8 / 9 / 10 は「Fix deferred」となっており、修正の提供時期は示されていません。Fix deferred は将来の修正提供を保証する表記ではない点に注意が必要です。Red Hat は、同社の基準を満たす緩和策はないとしています。最新の状況は Debian や SUSE など、各ディストリビューションのページで確認してください。

ディストリビューションのカーネルは、修正をバックポートしても upstream と異なるバージョン番号のままの場合があります。uname -r の数字を upstream の修正版と比較するだけで修正済み・未修正を判定せず、配布元のアドバイザリーやパッケージの変更履歴で確認しましょう。

インターネット公開サービスの攻撃面を減らす

Windows と Linux の事例は、どちらも認証前のネットワーク処理が攻撃の入り口でした。修正の適用とあわせて、到達できる範囲そのものを減らしておくと、未知の脆弱性に対する防止にもつながります。

• ファイアウォールやセキュリティグループで、UDP 443 を含む公開ポートが業務上必要なものに限定されているか確認します。
• HTTP/3 や MPTCP など、性能向上のために有効化した機能が現在も必要か見直します。
• 外部からのポートスキャンや ASM（Attack Surface Management）ツールで、想定外に公開されているサービスがないか定期的に確認します。
• カーネルや HTTP.sys の異常終了、予期しない再起動を監視対象に含め、DoS の兆候を検知できるようにします。

AI による脆弱性発見を開発プロセスに取り入れるには

Anthropic は、既存の脆弱性を修正するだけでは課題の半分しか解決せず、残りの半分は新しい脆弱性がコードに入り込む速度を下げることだと述べ、Pull Request の段階でのスキャンを推奨しています。研究で使われた手法と、一般のチームが利用できるツールを分けて整理します。

Anthropic の研究基盤で使われた考え方

Anthropic は、多数のスキャンエージェントを並列に実行し、各スキャナーが追加で見つけた脆弱性の数で評価しながら、コードベース全体を網羅する基盤を構築しました。テスト時の計算量とスキャナーの多様性が、発見数を大きく左右したとしています。

• 網羅型: 関数ごとに脆弱性があるかを調べる
• 目的型: 顧客データの侵害につながる箇所があるかなど、守るべき対象から逆算して調べる
• 脅威モデル型: 文書化された脅威モデルを迂回する処理がないかを調べる
• Variant Analysis: 確認済みの脆弱性ごとに、類似のパターンを自動で探索する
• 検証パイプライン: すべての発見を標準化された検証とリスク評価に通し、品質の基準を保つ

この中で一般の開発チームが取り入れやすいのは、脅威モデルに基づく検査と Variant Analysis です。脆弱性を 1 件修正したら、同じ誤りが他のモジュールにないかを AI に調べさせ、結果を人が検証する流れは既存のチームでも始められます。

Claude Code の Security Guidance プラグイン

Anthropic は、自社の開発プロセスに組み込んだセキュリティ検査を Claude Code のプラグインとして公開しています。公式ドキュメントによると、Claude が書いたコードを次の 3 つの時点で検査し、見つかった問題を同じセッション内で修正させます。

Claude Code のセッションで次のコマンドを実行してインストールします。ドキュメントでは、Python 3.7 以降（コミット時の審査は 3.10 以降）と Git リポジトリーが前提条件とされています。

/plugin install security-guidance@claude-plugins-official

プロジェクトに .claude/claude-security-guidance.md を作成すると、自社の脅威モデルやレビュー基準を自然言語で追加できます。たとえば「/admin 配下のルートはデータベースを読む前に管理者ロールを確認する」といった規則を記載しておけば、モデルによる審査の判断材料になります。

参考: Claude Code Docs（Catch security issues as Claude writes code）
“one layer of defense in depth, not a complete security solution”
（多層防御の 1 層であり、完全なセキュリティソリューションではない。）
https://code.claude.com/docs/en/security-guidance

ドキュメントも明記しているとおり、プラグインは書き込みやコミットをブロックせず、審査モデルが問題を見落とす可能性もあります。確実に禁止したい操作は、フックや CI のチェックで強制する必要があります。

既存の SAST / DAST / SCA との役割分担

AI による検査は、既存のツールを置き換えるものではなく、パターン照合では捉えにくい論理的な欠陥を補う位置付けです。段階ごとの役割を次のように整理できます。

今回の研究で使われたのは、未公開の研究モデルと大規模な並列スキャン基盤です。一般に利用できる Claude や Claude Code で同じ規模の発見が得られるわけではありません。AI の指摘は誤検知を含む前提で、人による検証の工程を必ず残しましょう。

今回の研究からわかることと注意点

Anthropic は、複数の脆弱性を発見して組み合わせる作業は、これまで限られた専門チームの領域だったと述べています。研究記事の「防御側にとっての意味」では、次のようにまとめています。

参考: Anthropic（Discovering and exploiting vulnerabilities in critical, real-world software with Claude）
“Frontier models have the ability to discover and combine multiple vulnerabilities into a working exploit.”
（フロンティアモデルは、複数の脆弱性を発見し、組み合わせて実際に動作するエクスプロイトにする能力を持っている。）
https://www.anthropic.com/research/discovering-vulnerabilities-with-claude

この能力が攻撃者にも広がれば、脆弱性の公開から実用的な攻撃が作られるまでの時間は短くなると考えられます。Anthropic は防御側への助言として、自社のコードをスキャンすることがこれまで以上に重要だとしています。そのうえで、研究結果を自社のリスク評価に当てはめる際は、次の点を区別する必要があります。

• 使用されたのは Anthropic が「未公開の社内研究モデル」と説明するモデルです。同じ記事で紹介されている Cyber Verification Program の提供モデル（Claude Opus 5.5、Claude Sonnet 5.5、Claude Mythos 5.1 など）と同一とは説明されていません。
• 研究上の攻撃実証であり、実際の攻撃者による悪用は確認されていません。MSRC は CVE-2026-33096 を悪用なしとしており、CVE-2026-98432 も 10 月 29 日時点で悪用の報告はありません。
• 攻撃の成立は、標準設定の Chrome、HTTP/3 で応答する Windows、MPTCP リスナーを持つ Linux など、事例ごとの前提条件に依存します。すべての環境で確実に成立するわけではありません。
• Linux の PoC について、Anthropic は検証したカーネルのバージョンや構成を公開していません。MPTCP リスナーがないサーバーで同じように root 権限を奪取できるかも明らかにされていません。
• Anthropic の報告から、実際の悪用件数や攻撃の成功率を推定することはできません。

今回の研究が示しているのは、特定の製品の危険性よりも、防御側の前提が変わりつつあることです。修正の提供から適用までの期間を短くする運用と、新しい脆弱性を作り込まない開発プロセスの両方が、これまで以上に重要になります。

まとめ

Anthropic の研究は、AI が個別の脆弱性を見つけるだけでなく、多層防御を段階的に越える攻撃チェーンを組み立て、動作まで検証できる段階に来たことを示しました。5 事例はいずれも開発元による修正対応が報告されていますが、Linux では各ディストリビューションの修正パッケージの提供と適用状況を個別に確認する必要があります。

• 未公開の研究モデルが 5 製品で攻撃チェーンを実証
• Chrome の 62 件は修正済み CVE の総数で、チェーンの構成数とは別
• Safari はコード実行を使わないデータ主体の攻撃で、Android は物理アクセスが前提
• Windows は HTTP/3 の待ち受け状況と 4 月以降の更新適用を確認します。
• Linux は MPTCP の有無にかかわらず配布元のカーネル修正を確認します。
• PR 時の AI 検査と Variant Analysis で新たな脆弱性の混入を抑制
• AI の発見は人が検証し、既存の SAST / DAST / SCA と組み合わせて運用

以上、最後までお読みいただきありがとうございました。