In September 2025, the maintainers of Flowise, one of the most widely deployed open-source AI agent builders, shipped version 3.0.6 to patch a CVSS 10.0 remote code execution flaw in their CustomMCP node. Seven months later, in April 2026, researchers confirmed the vulnerability was being actively exploited in the wild. Somewhere between 12,000 and 15,000 publicly accessible Flowise instances were still running unpatched versions.
Seven months. Maximum severity. A patch that existed. And a user population that either didn't know, didn't act, or didn't have a patch management process that covered their AI stack at all.
The Cloud Security Alliance's new whitepaper, The AI Agent Disclosure Vacuum, published on 17 April, uses Flowise as one of several case studies in what it calls a structural failure in vulnerability disclosure for agentic AI. The paper is careful, well-cited, and worth reading in full. But the conclusion most security leaders will reach after reading it, that the industry needs better disclosure infrastructure for AI, is only half the story.
The disclosure vacuum the CSA describes is real. But it is a symptom. The deeper failure is a remediation vacuum that the vulnerability management industry has been quietly living with for a decade, and agentic AI is the first ecosystem where that failure is showing up on a timescale too short to ignore.
What the CSA paper actually documents
The paper advances three claims that deserve to be taken seriously.
First, the Common Vulnerabilities and Exposures program was not designed for systems like this. CVE assumes software components with bounded scope, identifiable vendors, reproducible flaws, and version-specific patches. An agentic AI deployment in production may involve a frontier model from one vendor, an orchestration framework from another, two or three community-built MCP servers with no formal maintainer, and a deployer-defined configuration that nobody upstream has reviewed. When a prompt injection via a tool response causes the agent to exfiltrate credentials, every stakeholder can make a defensible argument that the vulnerability belongs to someone else.
Second, there is a growing "silent bounty" pattern where vendors accept vulnerability reports, pay researchers, and never file a CVE. The paper cites the case of a reference SQLite MCP server in which a SQL injection report was classified as "out of scope" because the repository was an archived demonstration, despite having been forked more than 5,000 times into production-adjacent workflows. The pattern is not unique to any one vendor. It is the predictable outcome when a new product category reaches widespread deployment before disclosure norms have caught up.
Third, the exploitation window is collapsing. Roughly twenty-nine percent of Known Exploited Vulnerabilities in 2025 showed confirmed exploitation on or before the day their CVE was published. AI-assisted exploit development can now operationalize a public CVE in fifteen minutes at negligible cost. A joint April 2026 briefing from SANS, CSA, and the OWASP GenAI Security Project warned specifically that AI-driven vulnerability discovery is compressing exploit timelines from weeks to hours.
Put together, the picture is bleak. Vulnerabilities that are hard to attribute, disclosures that never happen, and an offensive side of the equation that can weaponize whatever does get disclosed before the defense side has finished its morning coffee.
Where the paper understates
I have spent the last decade in and around vulnerability management, and at Mondoo, we have spent the last several years building a capability whose entire premise is to close the gap between discovering a vulnerability and fixing it across cloud, container, and endpoint estates. That vantage point is what makes one pattern in the CSA paper stand out. Every one of the case studies the CSA walks through, Flowise, EchoLeak, LangFlow, and the MCP Inspector RCE, has a patch. The disclosures happened. The CVEs were assigned. In the Flowise case, the CVE was filed, the patch shipped, and the advisory was public. None of that prevented seven months of exposure on 12,000 production deployments.
That is not a disclosure problem. That is a remediation problem.
The vulnerability management industry has spent three decades optimizing for the discovery end of the pipeline. We have scanners that catalog, aggregators that enrich, feeds that distribute, dashboards that prioritize, and ticketing systems that assign. What we do not have, for most organizations running most software, is a closed loop from "vulnerability identified" to "vulnerability fixed" that operates on a timescale shorter than the attackers' operationalization cycle. The median enterprise has been living with this gap on conventional infrastructure for years. Agentic AI is simply the first ecosystem where the gap has become too visible to explain away.
When the CSA paper notes that many organizations "treat AI components as black boxes exempt from patching cycles," what it is actually describing is an organization that does not have a functioning patching cycle in the first place, one that happened to have the gap exposed by a CVSS 10.0 in a new component class. The Flowise users who were still exploitable seven months after patch release are not a unique failure mode. They are the same organizations that are running six-month-old CVEs in their container images and nine-month-old ones in their Windows fleets. AI just made the clock visible.
Why agentic systems make this worse, faster
Three properties of agentic deployments turn a chronic remediation gap into an acute one.
They are compositional. A single production agent may inherit risk from five or six distinct components, each with its own disclosure cadence, patch release process, and user base. There is no single feed to subscribe to that covers the full blast radius. When CSA research finds that eighty-two percent of surveyed MCP servers use file operations vulnerable to path traversal, the implication is not that one vendor needs to ship a patch. It is that thousands of community-maintained components each carry a variant of the same flaw, and no disclosure mechanism on earth is going to serialize the remediation of all of them.
They operate with delegated authority. A compromised traditional server is a compromised server. A compromised agent is a compromised principal, acting with the user's credentials against the user's email, files, code, and tickets. The blast radius of a single vulnerability is bounded by what the agent was permitted to do, and most enterprises have not yet had the identity governance conversation about what that should be.
They are deployed by people who do not consider themselves security owners. Flowise was adopted for rapid prototyping. LangFlow for internal automation. Community MCP servers by developers who wanted to wire a model to an internal tool. The populations deploying these components are, on average, further from a patch management workflow than the populations running production databases or Kubernetes clusters. The organizational gap is real, and it will not be closed by a more aggressive CVE pipeline.
What this means for security leaders
The CSA paper's recommendations are sensible and worth implementing. Inventory AI components, monitor CVE feeds, require disclosure track records from vendors, assign distinct agent identities, and log agent activity in a reviewable format. All of that is necessary. None of it is sufficient.
The operating model the agentic stack needs is the one vulnerability management has been avoiding for a decade. A closed loop in which finding a vulnerability and closing it follow the same workflow, are owned by the same system, and are measured by the same clock. Not a report handed to another team. Not a ticket that ages in a queue. A remediation path that executes on the same timescale as the exploitation path that the attackers are running against you.
Three practical questions for CISOs. Do you have an inventory of every AI component, model provider, framework, MCP server, and tool integration in production, and does your vulnerability management program cover it the same way it covers your container registry? When a CVSS 10.0 lands against a component in that inventory, what is your mean time to remediation across all affected hosts? And when a vendor classifies a flaw as "out of scope" or "archived demo" and declines to file a CVE, does your procurement team treat that as a signal about the vendor's security posture, or accept it at face value? If you cannot answer the first two with numbers and a chart, the Flowise story is your story too.
One structural point worth naming. Agentic systems inherit classical software vulnerabilities, RCE, SQL injection, path traversal, and command injection, alongside AI-specific failure modes. Every case study in the CSA paper is a conventional vulnerability class in a new component class. CISOs who delegate AI security entirely to an ML or AI governance team build a silo that misses 80% of the problem that looks like ordinary infrastructure security.
What this means for security service providers
The disclosure vacuum creates a service opportunity that did not exist twelve months ago. Enterprises cannot realistically build in-house expertise to track CVEs across frontier models, orchestration frameworks, community MCP servers, and tool integrations. The feeds are fragmented, the taxonomy is immature, and the components are being deployed by teams outside central IT. That is the gap managed vulnerability services exist to close, and the MSSPs who extend their coverage to the AI stack in 2026 will lock in a capability competitors will spend two years catching up to.
The service boundary has to move. A scanner that catalogs Kubernetes nodes but cannot tell a customer they are running a vulnerable Flowise instance has a coverage gap that the customer will discover at exactly the wrong moment. Asset discovery needs to expand to cover AI framework components and community MCP servers, and the service needs a curated feed of AI-specific advisories built in.
Remediation-led service wins over detection-led service. Every MSSP in the market can promise to find things. The CSA paper is implicitly arguing that finding is not the binding constraint. The binding constraint is that nothing closes the loop between a published CVE and a patched host inside the compressed exploitation window. Partners who can demonstrate a measurable MTTR on customer environments, not a ticket handed back but a fix delivered, are selling the thing the market actually needs.
For MSSPs in regulated markets, the regulatory calendar is a commercial hook in its own right. The EU AI Act's high-risk obligations take effect in August 2026, and the Colorado AI Act becomes enforceable in June. Neither mandates disclosure processes specifically, but both create liability exposure that customers are already asking about. An MVS offering that can position itself as evidence of due diligence under the AI Act's robustness and oversight requirements has a compliance-led entry point that does not require the customer to already believe in the security argument.
What this means for the industry and professional practice at large
The CVE program needs reform, and the reform is coordination work rather than technology work. Scope expansion for AI-specific components, taxonomy updates for prompt injection and memory poisoning, CNA designations for major AI vendors, and multi-party coordinated disclosure processes are all within the reach of MITRE, CISA, and the CNA community. None of it requires new technology. It requires a working group, agreed standards, and vendor willingness to participate. The practical industry action is to visibly support that coordination. Attend the working groups, publish transparency reports, file CVEs on AI components even when the path is awkward, and treat disclosure as a professional obligation rather than a reputational trade-off.
The bug bounty model is under structural strain. The curl case the CSA cites, fewer than five percent of submitted reports are legitimate, and the program eventually closed, is a warning about an open-source maintenance model that cannot absorb AI-generated report volume. If the industry does not develop triage tooling that handles the noise or funding models that enable maintainers to operate sustainably, the long tail of community AI components will lose its primary external security review mechanism. That is a generational security debt problem worth industry-level attention now rather than retrospectively.
And vulnerability management, as a discipline, has to evolve beyond detection economics. For twenty years, vendor economics have favored the find side. Scanners ship, dashboards render, prioritization models rank, and remediation is someone else's operational problem. The CSA paper is, implicitly, a reckoning with that split. Practitioners who internalize it and CISOs who insist on MTTR-led metrics will push the profession toward an operating model the industry should have adopted a decade ago. The regulatory trajectory will pull in the same direction whether or not the profession moves first.
The bottom line
The CSA has done the security community a service by documenting the disclosure vacuum in rigorous, citable detail. The paper deserves wide reading, and its recommendations deserve serious engagement. But the underlying lesson for enterprise security leaders is not that AI needs a better CVE pipeline. It is that the remediation gap the industry has tolerated in conventional software for years is now running against a clock that AI-assisted offense has compressed to hours.
The organizations that will operate agentic AI safely at scale in 2027 and beyond are the ones that decide, now, to treat remediation as a measurable operating discipline rather than a downstream consequence of detection. Find it. Fix it. Measure the time. Repeat. Everything else is commentary.
At Mondoo, we built our capabilities around the operating model described in this piece. If the questions I've raised are ones your team cannot yet answer with numbers, we'd welcome the conversation about how we can help you deliver an effective and efficient vulnerability management program.
