CoreBreak: When the Model Never Gets a Turn
On Aug 6, 2026, three AI-agent SDK vendors — AWS, Google, and Vercel — patched the same class of bug. The Hacker News wrote it up under the name from Black Hat: CoreBreak. Hedi Ingber and Aviyam Ivgi (Stealth) presented the pattern at their Aug 6 briefing.
Across all three SDKs, an attacker can get a tool to execute without the model ever being called.
The Hacker News's closing line: "This is not prompt injection. There is no probabilistic model to fool and no stronger model that resists it, because the model never gets a turn."
What actually breaks
In a normal turn, the SDK sends the request, system prompt, history, and tool definitions to the model. The model decides whether to call a tool and returns a structured instruction. The SDK executes it.
In each vendor's harness, the executor didn't verify the tool call actually came from the model. The runtime received data shaped like a model-generated tool call and treated it as authoritative.
AWS (CVE-2026-18830, CVSS 8.6): An authenticated caller of Bedrock AgentCore's InvokeHarness API could place a tool-use content block in the final message. AgentCore's event loop dispatched the named tool directly, without asking the model. AWS added server-side validation on July 31 that rejects caller-supplied tool-use blocks before the event loop.
The same code path remains in the upstream Strands Python framework AgentCore is built on. Its event_loop.py has a branch commented "Skip model invocation if the latest message contains ToolUse." An April PR proposed removing the shortcut; it was closed unmerged June 19. AWS's response for standalone Strands users is a documentation page — "Trusted Message History" — rather than a code fix, on shared-responsibility grounds.
Google (CVE-2026-18236, CVSS 9.3): ADK for Python before 2.5.0 had two flaws. A continuation-forgery path: an attacker manipulating session-history events could forge a confirmation for a sensitive tool call — the confirmation processor didn't verify the target tool belonged to the executing agent, actually required confirmation, or matched the original call's name and arguments. Google's patch added those checks. A resumable-mode bypass shipped in the same 2.5.0 release: user-authored events with function_call parts were treated as instructions to run registered tools. Google's commit message describes the fix as preventing "bypassing the LLM and directly executing arbitrary registered tools."
Vercel (CVE-2026-64650 and CVE-2026-64651, CVSS 6.3): The harness relay for @ai-sdk/harness-codex and @ai-sdk/harness-opencode trusted a process when its command line contained the path of an approved helper script. Malicious code inside the sandbox could satisfy that check and invoke host tools — secret lookups, deployments, cloud APIs — without a model-authorized event. Vercel removed the process-path fallback; the patched relay now requires a short-lived, one-time authorization matching the model event's tool name and input.
The shape
Three vendors, three codebases, three preconditions — AWS needed an authenticated remote request, Google needed session-history injection, Vercel needed code already in the sandbox.
One shared failure: the execution layer trusted the shape of the incoming data instead of its provenance. Two of the three CVEs are filed under CWE-863, incorrect authorization. AWS filed its own under improper input validation. Different names, same root cause.
The remedies converge. Google binds confirmations to the session-recorded tool and arguments. Vercel binds each relay request to a one-time authorization tied to the model event. AWS rejects caller tool-use blocks before the event loop. None lets the incoming data's shape stand in for a model turn.
That is a general architectural claim arrived at independently by three SDK teams in 48 hours: bind each tool invocation to the exact model event, tool name, arguments, session, and authorization state that produced it.
Why the "not prompt injection" framing matters
The last year of AI security work has assumed the model is the boundary. Guardrails in the system prompt. Output classifiers. Safer models. Alignment training. All above the SDK.
CoreBreak sits below the SDK, where it decides to execute a tool. If the tool runs without a model turn, no model-side hardening matters. The prompt was never processed. The classifier was never invoked. The safety training was never consulted. The model was skipped.
Prompt injection is about what happens when the model gets adversarial input and responds badly. CoreBreak is about what happens when the model gets no input and the tool runs anyway. If your defense stops at the model, you cannot see it.
What to do about it
If you build on any of the three SDKs, patch: Google ADK for Python 2.5.0+, @ai-sdk/harness-codex 1.0.29+, @ai-sdk/harness-opencode 1.0.28+. AWS Bedrock AgentCore was fixed automatically. If you run standalone Strands, read AWS's Trusted Message History guidance and treat any externally supplied history — resumable events, confirmation responses, structured tool-use blocks — as untrusted input.
The AWS/Strands split makes a broader point. The upstream framework has the same code path AWS patched in the managed service; a proposed fix was rejected on design-intent grounds; the workaround is documentation. For organizations not on the managed service, the boundary CoreBreak crosses is one the framework will not close. Something else has to.
That something else is a runtime layer that watches tool executions and can tell when one happened without a corresponding model turn — a behavioral observable, not a signature to be updated variant by variant.
CoreBreak is the tightest recent evidence that the SDK boundary — not the model boundary — is where tool-invocation authorization has to be enforced. Three vendors converged on that answer in one week.
SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.