CoreBreakとは｜AIエージェント 脆弱性の確認バイパスをADK/AgentCore/Vercelで解説

AIエージェント 脆弱性の新しいクラスとして、Black Hat USA 2026でセキュリティ企業Stealth社（Hedi Ingber・Aviyam Ivgi）が「CoreBreak」という攻撃クラスを発表した。対象はGoogle ADK・AWS Bedrock AgentCore・Vercel AI SDKという主要3ベンダーのAIエージェント基盤で、共通する根はただ一つ——「モデルのターンを一度も経由せずにツール実行へ到達できる」という設計上の欠陥だ。人間承認（confirmation）を要求するはずの「危険なツール」のガードが、セッション履歴へのイベント注入で偽造できてしまう。本記事は2026-08-11時点で確認できた一次・準一次情報をもとに、何が起きたか・なぜ起きたか・自分のエージェント実装で何を確認すべきかを整理する。

この事案はAIエージェント基盤という開発者ツールに共通する設計上の欠陥であり、サプライチェーン全体のセキュリティ課題とも地続きだ。攻撃手口と防御の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

CoreBreakとは——AIエージェント 脆弱性の新しいクラス

CoreBreakは特定製品の1つのバグではなく、「AIエージェントがツールを実行する前に、その要求が本当にモデルから来たものかを検証していない」という設計パターンそのものを指す攻撃クラスの名称だ。

多くのAIエージェント基盤は、破壊的な操作（ファイル削除・外部送金・本番環境への書き込み等）を伴う「危険なツール」について、実行前にユーザーへ確認を求める confirmation の仕組みを持つ。CoreBreakが突いたのは、この確認フローが「誰がこの確認要求を出したか」を検証していなかったという共通の穴だ。攻撃者はモデルの応答を一切生成させず、SDKが解釈するセッション履歴（イベントログ）に偽造したツール呼び出し・確認済みイベントを直接注入することで、SDK側に「これはモデルが正規に要求し、ユーザーが確認済みの操作だ」と誤認させ、ツールを実行させることができた。

時系列と影響範囲——3ベンダー4件のCVSSスコア

CVSSは全て「v4.0」表記の値である点に注意してほしい。 CVSS v3.1とは採点基準が異なるため、「AgentCoreの8.6は他より軽微」のような単純比較はできない。

発見・報告日と公開日の表記は情報源によって割れている。 ある情報源はGoogle ADK 脆弱性（CVE-2026-18236。AgentCore CVEであるCVE-2026-18830とは別採番）について「Pillar Securityが2026-07-21に協調的開示」、別の情報源は「CVE公開日2026-07-29」としており、どちらも確認は取れるが両者の関係（開示日と公開日）は情報源ごとに書き方が違う。本記事では確定できる事実である「修正版v2.5.0のリリース日=2026-07-16」を時系列の軸とし、報告日・公開日は情報源ごとの表記のまま併記する。Black Hat USA 2026での攻撃クラスとしての公表は2026年8月上旬である。

なお、AWSのStrands Agents SDK（OSS）については、外部から注入可能な経路を指摘するPRが2026年4月に提出されたが2026-06-19にクローズ（未マージ）されており、2026-08-11時点でCVE番号が付与されているかは確認できていない。GitHub Advisory Databaseでの該当エントリは執筆時点で見当たらなかった。CVE番号が付いていないことを「脆弱性が存在しない」とは読まない方がよい——番号の有無は各ベンダーのCNA（CVE採番機関）としての運用判断に左右され、コードの状態そのものを保証するものではないためだ。PRがクローズされた経緯（マージ不要と判断されたのか、別の理由でクローズされたのか）は一次ソースからは読み取れず、本記事では「未確認」として扱う。

また、影響を受けるバージョンの境界にも注意が必要だ。Google ADKのv2.5.0未満という条件は、メジャーバージョンの新旧ではなく「confirmation processorの検証ロジックが入ったコミットを含むかどうか」で切られている。したがって「新しいメジャーバージョンだから安全」という単純な判断はできず、実際に手元のpip show google-adkで表示されるバージョン番号を、修正版のv2.5.0（2026-07-16公開）と直接比較する必要がある。

なぜ起きたか——「確認済み」を検証せずに信じた設計

CoreBreakの技術的な共通点は、「確認（confirmation）」という状態をどこに置くかという設計判断にある。

・多くのエージェント基盤は、確認フローの状態をセッション履歴（イベントログ）そのものに記録する
・SDKはツール実行の直前に「このツールは確認済みか」をイベントログから読み取って判断する
・しかし読み取る際に、そのイベントが本当に正規のモデル応答・ユーザー操作から生まれたものか（呼び出し元エージェントの一致・引数の一致・確認要求そのものの真正性）までは検証していなかった
・結果として、履歴に直接書き込む権限（API・SDK呼び出し）さえあれば、モデルの推論を一切経由せずに「確認済み」を偽造できた

Google ADKのケースでは、confirmation processorが「どのエージェントに紐づくツールなのか」「引数がユーザーの元の意図と一致するか」を照合していなかったことが直接の原因としてCVE記述に明記されている。Vercel AI SDKのケースは経路がやや異なり、信頼済みプロセスのパスをモデルの権限に暗号学的に紐付けないままリレーしていたことで、別プロセスからの要求をモデル発の要求と誤認する余地があった。AWS Bedrock AgentCoreのInvokeHarness APIは、認証済みユーザーであれば誰でもtool-useブロックを注入できる状態になっており、こちらは「誰が呼んだか」ではなく「呼び出し内容そのものの入力検証」が不足していたパターンで、3社の欠陥は同じ「確認済みを検証しない」という結果に至りながら、原因となったコンポーネントはそれぞれ異なる。

3社で原因コンポーネントが違う理由

同じ「モデルのターンを経由せずツール実行に到達する」という結果でも、脆弱性が刺さっていた層は製品ごとに異なっていた。

この違いは、単一の修正パッチで3社すべてが直るような単純な脆弱性ではなかったことを示している。「確認フローの出所を検証する」という設計原則は共通でも、実装のどの層にその検証を足すべきかは製品ごとに個別の判断が必要だった。

ベンダーで割れた対応——AWSはOSS側を直さなかった

ここが今回の事案でもっとも興味深い点だ。同じ設計クラスの脆弱性でありながら、ベンダーの対応は次のように割れた。

AWSはBedrock AgentCoreというマネージドサービス側の脆弱性は自動パッチで塞いだ一方、OSSとして配布しているStrands Agents SDK自体のコードには手を入れず、「顧客の責任」としてドキュメント更新のみで済ませた。これはシェアード・レスポンシビリティ・モデル（責任共有モデル）の考え方に沿った対応ではあるが、マネージドサービスは直り、自分でホストするOSSは直らないという非対称が生まれた点は、Strands Agents SDKを使って自前でエージェントを組んでいる開発者にとって重要な情報だ。

自分のエージェント実装で確認すべきこと

AWS Bedrock AgentCore・Google ADKのマネージド機能はベンダー側で自動パッチ済みのため、セルフホスト実装者でなければ「自分で何かする」余地は少ない。実際に手を動かして確認する価値があるのは、Strands Agents SDK利用者とVercel AI SDK harness利用者だ。以下のコマンドで現在のバージョンを確認できる。

# Google ADK for Pythonのバージョン確認（v2.5.0以上か）
pip show google-adk

# Strands Agents SDKのバージョン確認
pip show strands-agents
python3 -c "import strands; print(strands.__file__)"
# ↑のパス配下で、モデル実行をスキップして直接ツール実行に至る分岐
# （イベントループ内の tool-use ショートカット相当のロジック）が
# 現行バージョンに残っていないかをコードリーディングで確認する
# （自動検出コマンドではなく目視確認が必要）

# Vercel AI SDK harnessパッケージのバージョン確認
npm ls @ai-sdk/harness-codex @ai-sdk/harness-opencode

Google ADK・Vercel AI SDK harnessはpip show/npm lsの結果が修正版（それぞれv2.5.0以上・1.0.29/1.0.28以上）であれば対応済みと判断できる。Strands Agents SDKはコード修正が入っていないため、バージョン確認だけでは不十分で、自分のエージェント実装で「確認必須」フラグを付けたツールがある場合、その検証ロジックが実際に呼び出し元の妥当性（エージェントの一致・引数の一致）を確認しているかをコードレビューで確かめる必要がある。

・対策①：Google ADK for Pythonはv2.5.0以上へアップデートする
・対策②：Vercel AI SDKのharness-codex/harness-opencodeを修正版へアップデートする
・対策③：Strands Agents SDKで確認必須ツールを実装している場合、セッション履歴への書き込み経路を制限し、確認イベントの出所（呼び出し元プロセス・エージェントID）を自前で検証するコードを追加する
・対策④：いずれのSDKを使っている場合も、危険なツールの確認フローを「イベントログに何が書かれているか」だけで信じず、要求元の真正性を別レイヤーで担保できないか設計を見直す

検知のヒント——悪用の痕跡はどこに残るか

CoreBreakの仕組みから逆算すると、悪用の痕跡が残りやすい場所は「モデルのターン記録とツール実行記録の対応関係」だ。正規フローであれば、ツール実行イベントの直前には必ず対応するモデルの応答（構造化ツール呼び出し）が存在する。攻撃フローでは、この対応するモデル応答が存在しないか、時刻・内容が不自然に一致しない状態でツール実行イベントだけが記録される。

・確認ポイント①：エージェントのトレースログ・監査ログで、危険なツール（ファイル削除・外部API呼び出し等）の実行イベントを抽出し、直前のモデル応答イベントが存在するか突き合わせる
・確認ポイント②：確認（confirmation）イベントのタイムスタンプが、対応するユーザー操作のタイムスタンプと極端に近い、または操作主体が不明なものが無いか確認する
・確認ポイント③：セッション履歴を直接書き換えられるAPI・SDKメソッドへのアクセス権限が、想定より広く付与されていないか棚卸しする
・想定される限界：この検知手法は事後のログ調査であり、CoreBreak型の攻撃自体を未然に防ぐものではない。根本対策は上記の対策①〜④（バージョン更新・検証ロジックの追加）である

まとめ——AIエージェント 脆弱性の再発を防ぐための視点

CoreBreak 攻撃クラスは単一のCVEではなく、「確認フローの出所を検証していない」という共通の設計欠陥に対して、Black Hat USA 2026で付けられた通称だった。この種のAIエージェント ツール実行 バイパスは、確認ダイアログの見た目だけでは検知できない点が厄介だ。Google ADK・Vercel AI SDKはコード修正で対応し、AWS Bedrock AgentCoreはマネージド側の自動パッチで対応した一方、AWSのOSS Strands Agents SDKだけはコード修正が入らず、利用者側の緩和実装に委ねられた。この非対称は、マネージドサービスとセルフホストOSSの安全性が同じベンダー内でも一致しないことを示す実例として覚えておく価値がある。

CoreBreakは「確認フローの偽造」という切り口だが、AIエージェントの自律実行がもたらすリスクはこれだけではない。ファイルシステムへの誤破壊はAIエージェントが290件のファイル破壊インシデントを起こす理由とYoloFSが示す解法、本番環境への意図しない書き込みはPocketOS事件とは｜CursorのClaudeが本番DBを9秒で削除した原因と防御策を徹底解説、エージェント基盤そのものの脆弱性群はOpenClawのセキュリティリスク完全ガイド：138件のCVE、Cisco調査、安全な使い方で扱っている。いずれも「エージェントに何をどこまで任せるか」という同じ論点に行き着く。

参照ソース

・AWS, Google, and Vercel Agent Flaws Let Attackers Trigger Tools Without Running the Model - The Hacker News — CoreBreak攻撃クラスの全体像・4製品の脆弱性詳細・発見者情報
・CVE-2026-18236 | THREATINT — Google ADK for Pythonの脆弱性詳細・CVSS・修正版
・AWS Fixed Its Managed Agent Service but Left Strands Python SDK Unpatched - Tech Times — AWSがStrands SDKを未修正のまま残した経緯
・google/adk-python（公式リポジトリ） — star数・ライセンス・リリース履歴
・strands-agents/sdk-python（公式リポジトリ） — star数・ライセンス