AI Agent Exploits Now Hit Within Hours of Disclosure

This week, security researchers watched attackers begin exploiting a newly disclosed vulnerability in PraisonAI, an open-source multi-agent orchestration framework, within four hours of the flaw becoming public. In a separate disclosure the same week, researchers found three now-patched security flaws in LangGraph, the framework LangChain built for running complex, stateful, multi-agent systems. Neither framework is obscure — both sit underneath a meaningful share of the AI agents businesses have stood up in the past year, often without anyone outside the engineering team knowing which framework, or which version, is actually running in production.

The four-hour number is the part worth sitting with. That's not how long it took to find the exploit — it's how long it took after the vulnerability was already public knowledge for someone to start using it against real deployments. For comparison, most businesses' patch cadence for internal tooling is measured in weeks, not hours. A four-hour exploitation window against a multi-week patch cycle isn't a narrow miss — it's a gap wide enough to drive a breach through, and most companies running agent frameworks don't even have a process that could close it.

Why Agent Frameworks Are a Different Kind of Attack Surface

A vulnerability in a normal library is usually contained: it does one job, and a flaw in it compromises that one job. An AI agent framework is different because the entire point of the framework is to give an agent broad reach — access to tools, memory across sessions, the ability to call other agents, and often standing credentials to internal systems so it can actually get work done. A flaw in the orchestration layer doesn't just break a feature. It can hand an attacker the same reach the agent has: the same tool calls, the same data access, the same permissions someone granted it to do its job. That's why agent framework CVEs get exploited faster than typical library CVEs — the payoff for an attacker who gets in is disproportionately large relative to the effort of finding the flaw.

This is compounded by a visibility problem specific to how businesses have adopted agents over the past two years. Most companies can tell you which cloud provider they use and which database is in production. Fewer can tell you, without checking, which orchestration framework their agents run on, which version, and whether that version has an open CVE right now. Agent frameworks got adopted fast, often by individual teams solving individual problems, without going through the same asset-inventory and patch-management process that a database or a web server would go through. You can't patch what you haven't inventoried.

What a 4-Hour Exploitation Window Actually Requires of You

• A real-time inventory of every AI agent in production and the exact framework + version each one runs on — not a wiki page updated quarterly
• A subscription to security advisories for every framework in that inventory, routed to someone who can act same-day, not filed into a newsletter folder
• A patch or mitigation path that can ship in hours, which usually means the agent architecture needs to support a fast, low-risk redeploy — not a change-control process built for quarterly releases
• Least-privilege scoping on every agent's tool access and credentials, so that if the orchestration layer itself is compromised, the blast radius is the agent's actual job, not everything it was ever able to reach
• A kill switch — the ability to pull a specific agent or agent type out of production immediately, without taking down every other agent running on the same framework

A Realistic Scenario

A Wizeb client, a regional healthcare billing processor, had built three internal agents on an open-source orchestration framework over the previous year — one for claims triage, one for eligibility checks, and one for denial-letter drafting — each stood up by a different team, each with its own service account and its own set of tool permissions layered on ad hoc as needs came up. When we ran a security review before a compliance audit, we found the eligibility-check agent was still running a framework version with a disclosed, patchable vulnerability from four months earlier, and its service account had standing read access to the full patient billing database rather than the narrow eligibility fields it actually needed. Nobody had exploited it, but nobody had been watching for it either — there was no owner responsible for tracking framework CVEs against the agent inventory. We rebuilt the deployment around a single tracked framework version across all three agents, scoped each agent's credentials to only the data it touched, and set up automated advisory monitoring tied to a same-day patch process. The audit passed, and more importantly, the next disclosed CVE for that framework got patched across all three agents in under six hours instead of sitting unpatched for months.

Questions to Ask About Your Own Agent Deployments

1. 1Do you have a current, accurate list of every AI agent in production and the exact framework and version each one runs on?
2. 2Who is responsible for monitoring security advisories for those frameworks, and what is the actual time-to-patch when a critical CVE drops?
3. 3Does each agent's credential scope match the narrow job it does, or did it inherit broad access because that was easier to set up at the time?
4. 4If you needed to pull one specific agent out of production in the next ten minutes, could you do it without disrupting every other agent on the same framework?
5. 5Was your agent architecture designed with security review as a step, or did it go straight from prototype to production because it worked in testing?

How Wizeb Approaches This

We treat AI agent security as infrastructure, not an afterthought bolted on before an audit. Every agent system we build starts with a framework and version that's actively tracked, credentials scoped to least privilege from day one, and a same-day patch path baked into the deployment architecture — not designed after the fact when a CVE forces the issue. If your business has agents running in production and nobody could tell you their exact framework versions and CVE exposure right now, that's the gap worth closing before an attacker finds it for you. See how we build and govern agent systems at wizeb.com/services/ai-agents.