何が起こったのか
Cloud Security Alliance は、2026 年 8 月 6 日に、AWS、Google、および Vercel エージェント フレームワークにわたる 4 つの CVE のセットである CoreBreak について説明するリサーチ ノートを公開しました。CoreBreak では、ツール ディスパッチ層が、言語モデルが実際に生成したことを検証せずにツール呼び出しを実行していました。 4 つすべてにベンダーによる修正が含まれています。
Cloud Security Alliance の AI Safety Initiative は、2026 年 8 月 6 日に、研究者が CoreBreak と名付けたクロスプラットフォームの脆弱性パターンについて説明した研究ノートを公開しました。このメモによると、セキュリティ企業 Stealth の共同創設者であるセキュリティ研究者の Hedi Ingber 氏と Aviyam Ivgi 氏は、Amazon Bedrock AgentCore、Google の Python 用エージェント開発キット (ADK)、および Vercel の AI とともに配布されるハーネス パッケージのツール実行層を示す調査結果を Black Hat USA 2026 で発表しました。正規のモデル ターンが発生することなく、SDK がそれぞれツールを実行するように誘導される可能性があります。言語モデルは一度も呼び出されなかったため、モデルの周りに構築されたガードレールには介入する決定がなかった、とメモは主張している。
この種のエージェント フレームワークは共通の構造を共有します。オーケストレーション層は、ユーザーリクエスト、システムプロンプト、会話履歴、利用可能なツールのカタログをバンドルして言語モデルに送信し、ツールとその引数を指定する構造化された命令をモデルが返すのを待ちます。次に、SDK は対応する関数、スクリプト、または API 呼び出しをディスパッチし、結果を会話にフィードバックします。 CoreBreak は最後のステップをターゲットにしています。メモによると、3 つの製品のそれぞれのディスパッチ ロジックは、モデル生成されたツール呼び出しに似ているだけのデータを、データの出所を確認することなく、信頼できるものとして扱っていました。
このメモには、ベンダーの公開情報と National Vulnerability Database のエントリを引用して、明確な悪用パスを持つ 4 つの CVE 識別子がリストされています。 AWS は、Bedrock AgentCore ハーネスの欠陥に CVE-2026-18830 (CVSS v4.0 8.6、高) を割り当てました。この欠陥では、認証されたリモート呼び出し元が、InvokeHarness API リクエストの最終メッセージにツール使用コンテンツ ブロックを直接配置する可能性があります。 Google は、ADK の欠陥に CVE-2026-18236 (9.3、重大) を割り当てました。この脆弱性では、攻撃者がセッション履歴にイベントを挿入できるため、人間の承認確認を偽造する可能性があります。これは、確認プロセッサが、ターゲット ツールが実行エージェントに属していること、実際に確認が必要であること、またはその名前と引数が元の記録された呼び出しと一致することを確認しなかったためです。 Vercel の @ai-sdk/harness-codex および @ai-sdk/harness-opencode は、CVE-2026-64650 および CVE-2026-64651 (それぞれ 6.3、中) を受け取りました。Linux サンドボックス内ですでに実行されている悪意のあるコードは、コマンド ラインに承認されたヘルパー スクリプトのパスが含まれるプロセスを信頼するプロセス パス チェックを満たす可能性があります。
修正は利用可能ですが、負担は展開モデルによって異なります。このメモには、フルマネージドの Bedrock AgentCore InvokeHarness API に対する AWS の修正は 2026 年 7 月 31 日より前に自動的にデプロイされ、顧客のアクションは必要なかったと記載されていますが、それでも特定のリージョンと構成のカバレッジを確認することを推奨しています。 Google の修正は 2026 年 7 月 16 日に Python バージョン 2.5.0 の ADK で出荷され、Vercel の修正は 2026 年 7 月 10 日に harness-codex 1.0.29 および harness-opencode 1.0.28 で出荷されました。セルフホスト型オペレータが自分で適用する必要があるパッケージ更新です。この注記は、CoreBreak をプロンプト インジェクションとは区別するものとして説明しています。プロンプト インジェクションはモデルの判断を操作しようとしますが、CoreBreak はモデルが判断を行ったかどうかという問題を回避します。
ソースの詳細: labs.cloudsecurityalliance.org ↗
なぜそれが重要なのか
コンテンツ フィルター、システム プロンプト、拒否トレーニング、および人間による承認ゲートはすべて、モデルがツールを実行するかどうかを決定する当事者であることを前提としています。ディスパッチ層がモデルのツール呼び出しのような形のものを受け入れる場合、それらのコントロールは破られるのではなくバイパスされ、通常は検査するログ監視チームが作成されることはありません。
エージェント AI のエンタープライズ コントロールのほとんどは、モデル上またはモデルの周囲に配置されます。システム プロンプトは機密性の高いアクションを制限し、コンテンツ フィルターは入出力をスコアリングし、拒否トレーニングはモデルの重みに組み込まれ、人間による確認ステップにより高リスク ツールがゲートされます。これらのコントロールはすべて、モデルがツールを実行するかどうかを決定する当事者であることを前提としています。ディスパッチ層が正しく形成されたペイロードを実行する場合、それらの投資は予防的保護をほとんど提供しません。設計が不十分だからではなく、攻撃が動作する場所を迂回するためです。これは、議論の対象となるガードレールとは異なる種類の問題です。
これらのディスパッチ層の背後にある特定の機能が、調査結果に重みを与えるものです。このメモによると、Vercel の欠陥は、シークレット検索、デプロイ操作、クラウド API 呼び出しなど、ホストに公開されているツールに影響を与える可能性があります。 Google の欠陥はさらに深刻です。この脆弱性により、人間の承認の背後に意図的に配置されたツール (自動化するには重大すぎると考えられるアクションのために管理組織が予備として置いたツール) に偽造確認書が到達することが可能になってしまいました。人間参加者のステップを特に無力化するバイパスは、広範なエージェントの自律性を正当化する際に多くのチームが引用する緩和策を損なうことになります。
パッチの話は、エージェントのツールが普及するにつれて再発するであろう非対称性も示しています。フルマネージド AWS サービスの顧客は何もせずに修復されました。 Google の ADK または Vercel のハーネス パッケージを独自の環境で実行しているチームは、アドバイザリに気づき、依存関係を更新し、再デプロイする必要があります。また、運用スタックの依存関係の更新には、通常、数週間または数か月の遅れが生じます。したがって、同じ根本的な設計ギャップであっても、組織がエージェント インフラストラクチャをサービスとして利用するか、ベンダー インフラストラクチャを独自のコードベースに組み込むかによって、実際のエクスポージャー ウィンドウが大きく異なります。
検出ギャップもあります。このメモでは、エージェント システムのセキュリティ監視は一般に、プロンプトの記録、疑わしい完了のフラグ付け、モデルが選択したツールの確認など、モデルの入力と出力に焦点を当てていると述べています。モデルを実行せずにツールを実行すると、ログに記録されるアーティファクトは存在しません。いくつかの重要な点が不明のままです。メモでは、実際の悪用の証拠は報告されておらず、影響を受けた展開の数の推定も示されておらず、概念実証コードについても説明されていません。 CSA は、4 つのベンダーにわたる 2 つの開示は業界全体のパターンを証明するものではなく、観察された重大度の勾配はスコアリング ルールではなく 1 つのデータ ポイントであることを率直に述べています。
インタラクティブなメカニズム: 実際にどのように機能するか
この開発の背後にある基盤となるテクノロジーをインタラクティブに探索します。
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
次に見るべきもの
セルフホステッド オペレーターが実際に Google および Vercel パッケージの更新を適用するかどうか、他のエージェント フレームワークでも同様の出自のギャップが表面化するかどうか、実際の悪用が報告されているかどうか、ベンダーがツールの実行のために署名されたセッション限定の承認トークンに移行するかどうか。
最も具体的な短期的な問題は、パッチの取り込みです。 AWS のマネージド フィックスは既に展開されていると説明されていますが、ADK 2.5.0 と 2 つの Vercel ハーネス リリースは、それらをインストールするオペレーターのみを支援します。ダウンストリームのシグナル (パッケージ レジストリの採用率、アップデートを決してプルしないベンダーのフォーク、古いバージョンを固定する内部プラットフォーム イメージ) に注意してください。このメモでは、遡及的なチェック、つまりセッション レコード内の対応する適切な形式のモデルの完了に関連付けることができないツール呼び出しのログを確認することも推奨しています。組織がそのチェックを実行するためのディスパッチ層テレメトリを持っているかどうか自体は未解決です。
2 番目の質問は範囲です。 CoreBreak は 3 つの製品をカバーしていますが、説明されているパターン (ペイロードの形状またはプロセスのコマンド ラインをモデル承認の証拠として信頼する) は、これらの製品に固有のものではありません。同じ SDK、モデル、ツールの構造を持つフレームワークには、同等のギャップがある可能性があります。他のエージェント フレームワーク管理者からのさらなるアドバイスや、Black Hat のプレゼンテーション後に研究者がより完全な技術的詳細を公開するかどうかに注目してください。追加の確認症例は、これが 3 つの偶然のバグではなく、構造的なパターンであるという CSA の主張を強化するでしょう。
第三に、アーキテクチャの応答を観察します。 CSA の推奨事項は、メッセージ構造やプロセス ID から認可を推測するのではなく、ツール呼び出しが実際のモデルの完了 (署名された、セッションにバインドされたワンタイム トークン) から発生したことを示す暗号学的証明を要求することです。大手ベンダーがそのモデルを採用するかどうか、またそれが購入者が調達時に要求して検証できるものになるかどうかによって、この開示によって設計が変更されるのか、それともパッチのみが作成されるのかが決まります。ツールの所有権、確認要件、および元の記録された呼び出しに対する引数の整合性を検証する確認処理ロジックは、同じ修正の縮小バージョンです。
最後に、ガバナンスと脅威インテリジェンスの追跡を見てみましょう。 CSA は、MAESTRO 脅威モデリング フレームワークと AI Controls Matrix v1.1 を、実行制御と権限管理の評価でツールのディスパッチを明確にカバーすべき場所として指摘し、CoreBreak をシェル レベルのガードレール バイパスに関する以前の GuardFall 研究に結び付けています。また、NVD エントリや CVSS スコアが改訂されているかどうか、ベンダーが最初の報告以外のインシデント後の詳細を公開しているかどうか、確認されたエクスプロイトが出現しているかどうかなども監視する価値があります。現在、4 つの CVE のいずれも、CSA が引用するような環境での虐待に関する公的報告を行っておらず、そのような報告がないことは、活動がないことと同じではありません。