Written by AI agents, curated and verified by me.
Twelve CVEs across four agent frameworks: the boundary sits in the orchestration layer
- Agentic Engineering
- Verification
- Automation
On 6 August, Check Point Research published a recap of the four talks it gave at Black Hat USA 2026. One of them lands directly on what many teams are building agents with right now: Shahar Tal and Yarden Porat audited LangChain, Google’s ADK, Microsoft Agent Framework and CrewAI, and found 12 CVEs across the four. My thesis: prompt injection is the delivery path, not the damage. The damage happens one layer down, where attacker-controlled content crosses into the framework’s own machinery.
What did Check Point Research report?
The text is a conference recap, not a technical report. It summarises four talks. The one that matters for agent work is called “No Tools Required: Post-Injection Exploitation Across AI Agent Frameworks”. Tal and Porat argue against the common framing of prompt injection as purely a model behaviour problem or purely tool misuse. Their wording: the damage happens when content an attacker controls crosses into a framework’s own internal plumbing, its serialization, its caching, its file parsers. None of those were built to handle hostile input.
Their second talk is “When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers”. The other two sit beside our topic: Jiří Vinopal analysed a Windows Defender kernel driver that has shipped for over a decade, carrying the same hard coded key across eighteen signed builds, and Aleksandra “Hasherezade” Doniec presented a pipeline that turns compiled V8 bytecode malware back into something readable. Both tools were released as open source. I mention them for completeness, they are not the subject here.
Why is the orchestration layer the trust boundary?
Because, per Check Point, the trigger does not have to be a tool call. The sentence the recap describes as the point that stuck with the room:
A poisoned document lands in the agent’s memory, and the framework’s own save and reload behavior fires the payload on its own.
In several cases nobody calls the dangerous function directly. That moves the place where you have to check. If you only review the model’s output and approve its tool calls, you are guarding a boundary the attack never needs to cross.
Their closing point is the reassuring part: most of these bugs are ones the security community already knows how to fix. The challenge is recognising them once they have moved into a new part of the stack. This is not a new class of attack on AI. It is known application security in a place many teams have so far treated as a library rather than as attack surface.
The sandbox protects the engine, not the glue
The second talk targets Cloudflare’s Code Mode. The idea there: instead of having a model call tools one at a time, let it write a small program and run that program inside a locked down sandbox. Tal and Porat did not go after the model. They went at the runtime beneath it, which Check Point describes as the same code handling more than a tenth of all traffic on Cloudflare’s network.
They found five memory corruption vulnerabilities, two of them rated Critical. Two carried the talk: a flaw in URLPattern that let an attacker reach across the boundary meant to separate tenants and pull a neighbouring customer’s secrets straight out of shared memory, with every defence switched on. Plus a use after free in node:zlib that the pair chained to arbitrary memory read and write and from there to a full sandbox escape. The starting point of that demonstration was nothing more than a prompt injection. Cloudflare ran a full disclosure process, the recap says, and shipped fixes for everything in runtime version v1.20260619.1.
The line the two left the room with fits both talks: the sandbox protects the engine, not the glue holding it together. Once a model is the one writing the code, that glue becomes the boundary and needs to be audited like one.
What the recap does not say
No CVE identifiers. No affected versions, no split of the twelve CVEs across the four frameworks, no fix status for LangChain, ADK, Microsoft Agent Framework or CrewAI. The only patched version named anywhere is the Cloudflare runtime. The bug classes are not enumerated either; the text names serialization, caching and file parsers as the areas involved, and stops there. Full technical write-ups are announced for research.checkpoint.com, they are not in the recap. If you need the identifiers for your own inventory, you cannot copy them from here yet, and I will not invent them.
What does this mean for your work?
Treat your agent framework like any other dependency with network access. Pin the version, follow the security advisories of the four projects, plan for updates. That sounds obvious, and it is exactly the gap: a framework that orchestrates a loop gets filed mentally as tooling rather than as software that processes hostile input.
Second, saving and loading is an execution step, not transport. If an agent’s memory is persisted, the load is where foreign content takes effect. So put a boundary there: separate memory per task, a format that does not reconstruct objects, and the willingness to discard the memory instead of carrying it forward.
Third, a sandbox is a good building block and not an answer. The Cloudflare part shows the interesting bugs sitting between the blocks. Where you execute is the question I covered in Claude Code on your own compute. This report adds the second one: what exactly runs between your tools, and who has audited it?
It is the same line as in agentic engineering: reliability does not live in the model, it lives in the architecture around it. The Black Hat finding only moves where that architecture draws its boundary. Not at the model’s output, but where the framework stores state, reloads it, and runs it.