SURIQ
AI agent platforms keep making the same mistake: they ship the control bridge that drives the agents bound to every network interface, with no authentication, as a shipping default. Ruflo is the largest instance of that pattern so far. Noma Security disclosed CVE-2026-59726, a maximum-severity flaw (CVSS 10.0) that let anyone on the network run shell commands on a Ruflo host with one unauthenticated request. The remote code execution is bad. The reason to pay attention is what an attacker leaves behind: instructions written into the platform's own memory that keep steering the AI after you have closed the hole.
What was exposed
Ruflo is an open-source agent orchestration platform, reported by The Hacker News to have started life as Claude Flow. It has more than 66,000 GitHub stars, sits second on the MCPMarket listing, and by Noma's count has roughly ten million downloads. Its Docker packaging ran an Express-based Model Context Protocol (MCP) bridge, the layer that lets a model call tools, on port 3001. Per the researchers, the default docker-compose.yml bound that bridge to 0.0.0.0, every interface on the box, with no authentication in front of it. A MongoDB instance on port 27017 was reachable the same way, unauthenticated.
Behind the bridge sat 233 registered tools covering shell execution, database access, agent control, and the memory store. One of them was ruflo__terminal_execute. A bridge that hands 233 tools to any caller with no token or address check is not a developer convenience. It is an unauthenticated remote shell wearing a JSON-RPC coat. A single POST returned command output from inside the container, and Noma noted the call walked straight past the tool's own AUTOPILOT_BLOCKED_PATTERNS blocklist. Every version before 3.16.3 is affected. Maintainer Reuven Cohen shipped the fix within a day of the June 30 disclosure; the patch binds the bridge to the loopback interface, puts terminal execution behind server-side controls, and enables authentication on the database. At the time of writing there is no public report of exploitation in the wild, and the researchers did not publish internet-exposure counts.
The part that breaks incident response
Standard practice after a critical remote code execution flaw is well worn: contain, patch, rebuild from a clean image, rotate anything the attacker could read, move on. That playbook assumes the damage lived in the binary or in a network foothold, and a clean redeploy erases both.
RufRoot does not fit that assumption. Among the 233 tools was ruflo__agentdb__pattern-store, which writes into the platform's persistent learning memory. Noma's example is precise: an attacker stores a fake SOC2 "compliance policy" that tells the agent to embed an attacker-controlled URL in every deployment script it later generates. That instruction lives in the MongoDB-backed memory, not in the code. Rebuild the container from a patched image and the memory comes back with it. As the advisory puts it, a patched redeploy alone does not undo the poisoning, and future conversations produce attacker-influenced output with no visible tell. You have replaced the lock and kept the intruder inside.
Same root cause, different logo
We have written this vulnerability class before under other names. Amazon's coding assistant shipped an MCP configuration an attacker could reach. Docker's own agent tooling let a rigged container image break out to the host. A Grafana MCP server leaked tokens through the same tool layer, and Cursor's editor escaped its sandbox into code execution. The specifics differ; the shape does not. The tool bridge that gives a model real power gets exposed further than its authors pictured, because "bind to 0.0.0.0 so it works in the demo" is the default nobody revisits before shipping. As agent frameworks race for adoption, the network posture of the tool layer keeps losing to convenience.
How you would know
The cheap moment to catch this is at the network edge, before the write. A bridge that should answer only on loopback answering on 0.0.0.0, or an unexpected inbound request to port 3001 from off the host, is the signal that costs least to detect. If you run agent infrastructure, inventory what binds to public interfaces rather than trusting the compose file. A managed detection layer that flags a newly exposed listening service and unexpected shell execution catches the intrusion at that stage, which is the affordable place to catch it.
After the write it gets harder. You cannot file-scan your way to a poisoned memory, because nothing on disk looks wrong. The reliable check is to diff the pattern store against a known-good baseline and treat the agent's memory as attacker-reachable state, not as trusted application data. That is a category most teams have not added to their response plans yet.
Treat the agent's memory as reachable state
If you run Ruflo, upgrade to 3.16.3 now. If ports 3001 or 27017 were ever reachable beyond the host, assume compromise instead of hoping: close them, rotate every LLM provider key the process could read, and inspect the AgentDB pattern store for entries an attacker planted, because the clean redeploy that fixes the code will not remove them. The wider lesson outlives this CVE. The moment an AI agent gets persistent memory and real tools, that memory becomes state an attacker wants to write to, and your response plan has to cover data integrity, not just the patch.
| Incident response step | Typical CVSS 10 RCE | RufRoot (CVE-2026-59726) |
|---|---|---|
| Close the network exposure | Ends attacker access | Necessary, not sufficient |
| Rebuild from a clean, patched image | Restores a trusted system | Restores the poisoned memory with it |
| Rotate exposed credentials | Cuts off reuse | Required: LLM API keys were readable |
| Audit the application data store | Rarely part of the drill | Mandatory: the pattern store can carry injected instructions |