Four CVEs let agent tools run without the model running at all. The guardrails were not bypassed, they were never asked

The model never runs. Its tools still do

Hedi Ingber and Aviyam Ivgi, co-founders of Stealth, presented a cross-platform pattern they call CoreBreak at Black Hat USA 2026 on 6 August. It affected production agent infrastructure at Amazon Web Services, Google and Vercel, and the description of the flaw fits in one sentence of theirs:

The runtime received data shaped like a model-generated tool call and treated it as authoritative.

That is the whole thing. To understand why it matters, it helps to see where the missing check belongs.

Where the provenance check belongs

CoreBreak · Black Hat USA 2026

Working exactly as specified, and untouched by this attack

1. 01

   System prompt and tool definitions

   Everything you hardened lives here

2. 02

   The model decides

   Refusal training and safety filters apply to this step

3. 03

   A structured tool call is returned

   The legitimate origin of any instruction the runtime should honour

The missing link: did a real model turn produce this

Four of the five disclosed paths never asked. An attacker reaching dispatch directly, holding data shaped like step three, is indistinguishable from step three.

Runs regardless

1. 04

   The runtime reads an instruction

   It checks the shape. It does not check the origin

2. 05

   The tool executes

   With whatever authority the agent holds

An attacker did not have to talk the model into anything. They did not have to defeat a system prompt, find a jailbreak, or get past a safety filter. They reached the dispatch path directly with something that looked like the model's output, and the runtime ran it.

The guardrail was not bypassed. It was never asked

This is the part worth sitting with, because it invalidates a control most agent deployments are resting on.

If your agent security review consisted of hardening the prompt and evaluating the model's refusals, that review measured a component this attack does not touch. A guardrail inside the model can only govern decisions the model makes. These paths let a tool run without the model making one.

The five identifiers, and what each one needed

CoreBreak, by vendor

CVE	Product	CVSS	Precondition
CVE-2026-18236	Google Agent Development Kit for Python	9.3	Attacker manipulates session history or injects events, or a user-authored function call in a resumable-mode flow
CVE-2026-18830	Amazon Bedrock AgentCore, InvokeHarness API	8.6	An authenticated remote user placing tool-use blocks in the final InvokeHarness request messages
CVE-2026-64650	Vercel @ai-sdk/harness-codex	6.3	Untrusted code already running inside the Linux sandbox with an active harness session holding host-provided tools
CVE-2026-64651	Vercel @ai-sdk/harness-opencode	6.3	The same, on the other harness

Look at the Vercel score. 6.3, because the attacker needs code already running inside the sandbox. That is the fourth time in a week this site has written down the same sentence in a different context: a precondition drags the score down, the score is what triage sorts by, and the precondition is a Tuesday for anybody who already has a foothold.

Passkeys required malware already on the device. Akira's Safe Mode reboot required a session on the host. August's only exploited zero-day was rated Important because it needed local code execution. In every case the qualifier that lowered the number is the state an attacker reaches first and worries about least.

The one that is not patched

Four of the five paths are fixed. The exception is the model-skipping code path in the open-source Strands Python SDK, and AWS declined to fix it with a code change.

Their position is that the behaviour "falls on the customer's side of its shared-responsibility model". Instead of a patch they published a documentation page, Trusted Message History, telling developers to "build message history from their own application rather than from input a caller can shape".

It is worth being fair about the reasoning. A library that hands you the primitives cannot know which of your inputs are trusted, and a shared-responsibility split is a legitimate way to allocate that. But a defect described in documentation is discovered by people who read documentation, and a defect described in a patch is discovered by anyone running a dependency scanner. Those are very different populations.

What to check this week

The fourth item is the durable one. Everything else on that list is a patch or a habit; that one is an architecture decision that makes the whole class of attack less interesting.

The position

The industry spent two years building agent security around the model, because the model is the part that looked dangerous and the part vendors could sell you controls for. CoreBreak is the bill for that. The controls were real, they worked as specified, and they sat one layer above the place where the attack happened.

That is the same finding as an antivirus that named ransomware and could not remove it, and as a safety classifier that ran with its logging disabled for eleven months. Five briefings this week, five controls doing exactly what their specification says, and five gaps between that specification and what somebody believed they had bought.

For agents specifically, the correction is unglamorous and structural. Authorisation belongs at the tool, in code, enforced by something that does not care whether a model was involved. Prompts are not a security boundary. They never were, and now there are four CVE identifiers to point at when somebody argues otherwise.