CoreBreak and the Tool Call That Skips the Model Entirely

Three vendors patched the same bug this week. None of the fixes involve the model, because in the broken paths the model never ran at all.

Every piece of agent safety advice from the last two years assumes the model is in the room. Write a careful system prompt. Add a content filter. Pick a model that resists manipulation. All of that guidance shares one hidden premise: that a tool runs because a model decided it should.

Three vendors just shipped patches proving that premise was optional.

Hedi Ingber and Aviyam Ivgi, co-founders of Stealth, presented the pattern at Black Hat USA 2026 today under the name CoreBreak. In the vulnerable paths across Amazon Bedrock AgentCore, Google's Agent Development Kit for Python, and two Vercel AI SDK harness packages, the runtime received data shaped like a model-generated tool call and executed it. No provenance check. No verification that a model turn produced the instruction. In several paths, as The Hacker News reported, the model never ran.

That last detail is what separates this from everything filed under prompt injection. There is no probabilistic system to fool and no stronger model that resists it, because nothing is being persuaded.

Why this breaks the mental model most teams are using

Picture the normal flow. Your SDK bundles the user request, the system prompt, the conversation history, and the tool definitions, and sends them to the model. The model returns a structured instruction: tool name, arguments. The SDK executes it.

The gap sits between those last two steps. The SDK trusts the shape of what it received. It never asks where the shape came from.

Amazon's version carries CVE-2026-18830 at CVSS 8.6. An authenticated remote user could place a tool-use content block in the final message of an InvokeHarness request, and the event loop would dispatch the named tool directly. AWS added server-side validation that rejects caller-supplied tool-use blocks before they reach the loop, applied automatically, no customer action needed. The managed API was affected before July 31, 2026.

Google's is the more instructive one. CVE-2026-18236 sits at CVSS 9.3 and affects ADK for Python before 2.5.0. ADK lets you flag a sensitive tool as requiring human confirmation, which holds the call until a person approves. The confirmation processor never verified three things: that the target tool belonged to the executing agent, that the tool required confirmation at all, or that its name and arguments matched what the session actually recorded. An attacker who could inject events into session history could forge the approval. Google's patch added exactly those checks.

Read that again. The human-in-the-loop control, the one every governance deck puts on the slide about responsible deployment, accepted a yes without checking which question it answered.

Vercel's two findings are smaller in blast radius and sharper in what they teach. @ai-sdk/harness-codex through 1.0.28 (CVE-2026-64650) and @ai-sdk/harness-opencode through 1.0.27 (CVE-2026-64651) both sit at 6.3. The relay trusted any process whose command line contained the path of an approved helper script. Malicious code already running inside the sandbox could satisfy that check and call host tools, including secret lookups and deployment operations. Vercel removed the process-path fallback; the patched relay accepts a request only against an exact, short-lived, one-time authorization tied to a tool name and input observed in a model event.

Three different vendors, three different attack conditions, one identical mistake. Each execution layer treated tool-call-shaped data as sufficient authority.

The part AWS did not fix

AgentCore's harness is built on the open-source Strands Python code, and the comparable branch is still there.

The current upstream event_loop.py calls a helper named _has_tool_use_in_latest_message. When that check passes, the loop sets the stop reason to tool_use, takes the latest message, and skips model execution. The comment above it reads: "Skip model invocation if the latest message contains ToolUse." The Hacker News confirmed the branch was still on main as of August 5, 2026.

An April pull request warned that externally injected toolUse blocks could reach execution without model invocation and proposed removing the shortcut. It was closed unmerged on June 19.

AWS told the researchers this falls on the customer's side of the shared-responsibility model. The company's answer was a documentation page, filed under Safety and Security, titled Trusted Message History. It tells developers that a tool-call block sitting as the most recent message causes the agent to run that tool directly on its next invocation with no model call in between, and that whoever authored the block picks the tool and its arguments outright. The guidance is to build message history inside your own application rather than from anything a caller can shape.

I think that page is honest and I also think it is insufficient, and both can be true. The behavior is documented, which means a developer who reads the security section will find it. But nothing in the library signals it at the call site, and every framework in this space has trained us to believe the model is the thing that decides. A default that surprises careful people is still a default worth changing.

To be fair to AWS: the shortcut does not make every Strands application remotely exploitable. Exposure depends on whether untrusted callers can submit structured conversation messages or alter stored history. Plenty of deployments never expose that surface.

Put this into practice

Start with the patches, because they cost nothing. Google ADK for Python to 2.5.0 or later, @ai-sdk/harness-codex to 1.0.29 or later, @ai-sdk/harness-opencode to 1.0.28 or later. Both Vercel fixes published on July 10, 2026, and both packages have since moved well past them, to 1.0.60 and 1.0.59. If you pinned a version in the spring, you are behind on more than this.

Then run the audit that actually generalizes, because your own runtime is probably not on the CVE list and probably has the same seam.

Open the code path between "model response arrives" and "tool executes." Ask one question: does anything in that path prove the invocation came from a model event, or does it only prove the data has the right fields? Grep for where you deserialize tool calls. If the answer is a shape check, you have the bug in your own code.

Next, list every place conversation state re-enters your system from outside. Resumed sessions. Replayed events. Approval callbacks from a web form. Anything read back out of a database that a user can write to. Each of those is an external boundary, and everything crossing it is untrusted input no matter how internal the data model feels.

Then bind the authorization. Vercel's patched design is the reference implementation and it is worth copying even if you never touch their SDK: one authorization, tied to a specific tool name and input, valid once, expiring fast, issued only when a model event is observed. Google's version of the same idea is checking a confirmation against the tool and arguments recorded in the session. Both refuse to let the shape of incoming data substitute for a turn.

Last, cut the standing authority each agent inherits. This is the boring control and it is the one that decides how bad the day is. The exposure here is bounded entirely by what the agent could already do. An agent holding a scoped read-only role and nothing else turns a successful forge into a shrug. An agent holding your deployment credentials turns it into an incident.

Do the credential audit even if you patch everything today. It is the only control on this list that keeps paying out against the next bug in this family, and there will be a next one.

What this analysis cannot tell you

The advisories and CVE records do not say whether any of these paths was used against a live deployment before it was patched. Ingber and Ivgi sent proof-of-concept code to the affected vendors and have not released it publicly. Absence of a public incident is not evidence of absence.

The CVE records themselves are messy. The Codex entry names the OpenCode package in its description, and the OpenCode entry's structured data lists a fixed version its own text contradicts. If you are automating patch decisions off CVE feeds, this pair will mislead your tooling. Read the two GitHub advisories directly.

The attack conditions differ enough that a single severity number is misleading. AWS needed an authenticated remote request. Google needed attacker-controlled session events or user-authored function calls. Vercel needed untrusted code already executing inside a Linux sandbox. Those are not equivalent bars, and treating a 9.3 and a 6.3 as the same alarm will waste your week.

And CoreBreak does not describe the only way in. Microsoft published a worm this week that writes into .claude/settings.json and waits for your coding agent to restart it, which no provenance check at the tool boundary will ever see. Fixing authorization at the dispatch path is necessary and it closes one seam out of several.

The line worth keeping

From the writeup, and it should end a lot of architecture arguments: any safeguard implemented only in a system prompt or model response disappears when a caller can reach the dispatch path without a legitimate model turn.

Every one of these three fixes is a boring engineering control. Verify provenance. Bind the authorization. Reject caller-authored structure at the boundary. None of it is about AI, and that is the useful part, because it means your existing instincts about authorization apply directly. You already know how to do this in an API. The agent runtime is an API that has been letting you skip the check.

Go read your own dispatch path this week. You will know within twenty minutes whether you have the bug, and if you do, you will have found it before someone else did.

Sources: The Hacker News, AWS security bulletin, CVE-2026-18236, Google ADK patch commit, Vercel advisory GHSA-qw9h-448j-6rph, Vercel advisory GHSA-g48p-5rr5-8rgq, Strands pull request 2136, Black Hat USA 2026 briefing.