Your Agent Framework Is Ordinary Software With Ordinary CVEs: Eleven Flaws Across LangChain, CrewAI and Google ADK, and a Langflow Bug on the CISA Exploited List
Check Point researchers disclosed eleven vulnerabilities across LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework and Google ADK, and the bug classes are insecure deserialization, server side request forgery, path traversal and use after free. In the same week CISA added an unauthenticated remote code execution flaw in Langflow to the Known Exploited Vulnerabilities catalogue. Your AI risk register is full of model risk. The thing being exploited is a Python orchestrator with a missing authentication check.
Two disclosures landed this month that belong in the same sentence, and almost nobody has put them there. First, Check Point researchers Yarden Porat and Shahar Tal presented a year of testing at Black Hat, covering LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework and Google ADK, and disclosed eleven vulnerabilities across those six frameworks, several rated critical, collecting 17,133.70 dollars in bounties along the way. Second, CISA added CVE-2026-9198, an unauthenticated remote code execution flaw in Langflow, the IBM owned low code builder for AI agents, to the Known Exploited Vulnerabilities catalogue on 4 August 2026, with a federal remediation deadline of 7 August under Binding Operational Directive 26-04. Read the bug classes in the Check Point work and the striking thing is how unremarkable they are: insecure deserialization, server side request forgery, path traversal, use after free. Not a single one is an AI problem. They are the same defects that have been shipping in application frameworks since the 2000s, now sitting inside the layer that holds your model keys, your database credentials and your cloud service account.
The two sharpest findings show what the boundary failure actually looks like. In Microsoft Agent Framework the researchers found a checkpoint deserialization flaw that allowed remote code execution, and the delivery path is worth spelling out because it is genuinely novel in shape even though the bug is old in kind. One user injects a payload. The payload sits in a stored checkpoint. Later, a different user rewinds their own session, the framework deserialises the saved state as part of that ordinary operation, and the attacker gets shell access. Microsoft paid a 10,000 dollar bounty and hardened the framework, and no CVE was issued because the product was not generally available at the time of discovery, which is a reasonable process outcome and also a reason the finding will never show up in your dependency scanner. In Google ADK the researchers found a built in development assistant that remains reachable over the HTTP API even when it is hidden from the application listing, with no authentication by default, including on default Cloud Run deployments. From there an attacker can write files that get executed as Python at import time, reaching environment API keys and the service account attached to the container. Google issued a partial fix and paid 3,133.70 dollars.
The Langflow case is the one that removes any doubt about whether this is theoretical. CVE-2026-9198 carries a CVSS score of 9.8 and works by chaining two API endpoints on a default deployment. The auto_login endpoint hands a superuser token to any caller that can reach it over the network, with no credentials required, and the code validation endpoint runs arbitrary Python through exec. That is the whole exploit. It affects Langflow OSS from 1.0.0 through 1.10.0, and the fix is 1.10.1 or later. Public tracking of exploitation attempts starts on 6 July 2026, with telemetry showing hundreds of attempts from more than two hundred unique addresses spread across dozens of countries, which is the signature of commodity scanning rather than targeted intrusion. If your team stood up a Langflow instance to prototype an agent, gave it a public address so a colleague could try it, and left it running, you did not deploy an AI experiment. You deployed an unauthenticated Python execution service holding whatever credentials the prototype needed to be useful.
This is where the mental model most organisations built over the past eighteen months turns out to be wrong in a specific and expensive way. AI risk registers are full of model behaviour: hallucination, bias, output quality, prompt injection, data leakage through inference. Those risks are real and we have written about several of them, including agent data injection and the way instructions smuggled inside content survive every input filter you own. But the Check Point conclusion is more uncomfortable than any of that. Their argument is that prompt injection is the entry point rather than the bug, and the damage happens when attacker controlled content crosses out of the input path and into trusted framework logic, meaning orchestration, memory and checkpoint handling. That is not a guardrail problem, and no amount of tuning a system prompt addresses it. It is a software supply chain problem in a component that most teams installed with a package manager and have never patched, reviewed or listed anywhere.
The blast radius is what separates this from a routine dependency advisory. An ordinary web framework compromise gets an attacker into a request handler. An agent framework compromise gets them into the place where the credentials are deliberately concentrated, because concentration is the entire point of the design. The agent runtime holds model provider API keys, retrieval credentials for your document store, database connection strings, a cloud service account with whatever permissions somebody granted when they were trying to make a demo work, and increasingly OAuth tokens for mail, chat and CRM systems so the agent can act on behalf of staff. That is a credential vault that almost nobody has classified as one. It usually has no data classification, no access review, no key rotation schedule and no runtime egress controls, because it was categorised as a development tool rather than as production infrastructure holding tier one secrets.
The framework mapping is entirely conventional, which is the good news, and the reason the gap is embarrassing rather than novel. ISO 27001 already asks for management of technical vulnerabilities, secure configuration, secure development and monitoring of what is running, and an unauthenticated control plane on a public address fails all four at once. The SOC 2 common criteria expect vulnerabilities to be identified, evaluated and remediated on a defined timeline, and expect logical access to be provisioned against documented authorisation, and a superuser token issued to anonymous callers is not a control finding you can talk your way past. ISO 42001 requires an inventory of AI systems with a recorded purpose and a named owner, and a self hosted agent builder is an AI system whether or not procurement ever saw it. If any of this sits near a payment page, the PCI DSS expectations on patching timelines, inventory and script integrity follow it directly. Be precise about what the platforms can do here: Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will confirm that your vulnerability management policy is approved and your reviews ran on schedule, and Snyk, GitHub Advanced Security and Checkmarx One will flag a known CVE in a manifest they can see, but none of them will tell you that a developer pip installed an agent framework into a container last Thursday and exposed its API to the internet. Our compliance readiness tool and the vulnerability management and secure development templates in our policy templates library both assume somebody maintains the asset list.
There is a fair counterargument and it deserves to be stated properly. This is what healthy software maturation looks like. Researchers tested the frameworks, vendors paid bounties, fixes shipped, one issue reached the KEV catalogue with a hard federal deadline attached, and the ecosystem is now doing to agent frameworks what it did to web frameworks over a decade. Nobody should conclude that LangChain, CrewAI or Google ADK are unusually bad engineering, because the honest reading is that they are ordinary engineering being adopted at extraordinary speed. The problem is the mismatch between those two rates. These libraries enter an organisation through a developer laptop rather than through procurement, they get wired into production because a prototype worked, and the patch discipline that a company applies to its web stack has not been extended to them because nobody filed them under the same heading. The low code builders make it worse in one specific way, since they are designed to be run by people who are not operating a service, and a self hosted instance with a public address and default settings is the exact configuration the Langflow exploitation data shows attackers scanning for.
The exercise for this week takes an afternoon and leaves you with something durable. First, produce an actual list: grep your repositories and container images for langchain, langgraph, crewai, autogen, the Microsoft Agent Framework packages, google adk and langflow, and record the version of each and where it runs, because you cannot patch what is not on a list. Second, check exposure before you check versions, since network reachability is the difference between a bad advisory and an incident, so find every agent runtime or builder UI that answers on a public address and put it behind authentication or an internal network today. Third, if you run Langflow anywhere, confirm you are on 1.10.1 or later and treat any instance that was internet facing before you patched as potentially compromised, which means rotating every credential that instance could reach rather than just upgrading it. Fourth, inventory the secrets in each agent runtime and ask what an attacker would hold if they got code execution there, then remove the ones that are only present because they made a demo easier. Fifth, add agent frameworks to the same vulnerability management scope, patch SLA and KEV monitoring you already apply to your web stack, and name an owner for each, which is the ISO 42001 inventory requirement and the ISO 27001 asset requirement satisfied in one action. Sixth, ask your agent platform vendors two written questions and keep the answers: how do you authenticate the control plane by default, and what is your published timeline for security fixes. The agent conversation for the past year has been about whether models can be trusted. The exploited component this month was a Python function called exec sitting behind an endpoint that never asked who was calling.
Editorial note: AES Tech reviews are independent. Some outbound links are affiliate links and are marked sponsored; they never change our rankings. See our disclosure.
Get the next post by email
One short email when something worth knowing ships. No spam, unsubscribe anytime.