Ruflo has more than 66,500 stars on GitHub and a straightforward pitch: point it at Claude Code or OpenAI Codex and it coordinates fleets of AI agents to work through tasks in parallel, sharing memory and tool access along the way. That coordination happens through a Model Context Protocol bridge, and according to The Hacker News's coverage of the disclosure, the bridge shipped, by default, with no authentication in front of it at all. Noma Security's research arm, Noma Labs, found the issue, assigned it the internal name RufRoot, and it's now tracked as CVE-2026-59726 with a CVSS score of 10.0 - the maximum the scale allows.
The flaw wasn't clever. It was a docker-compose default
What makes this one worth reading closely isn't a sophisticated exploit chain. It's that Ruflo's own docker-compose.yml bound the MCP bridge to port 3001 on every network interface, 0.0.0.0, rather than restricting it to the local machine. Any self-hosted deployment that used the defaults - which, for an install-and-go open-source tool, is most of them - had its bridge reachable from whatever network the container sat on. The bridge's /mcp endpoint accepted standard JSON-RPC tool calls and simply carried them out, with no session token, no API key, and no access check in between. GBHackers' writeup and Noma Labs' own disclosure both describe the same underlying problem from different angles: 233 tools sitting behind that unauthenticated endpoint, covering shell command execution, database operations, agent management and the platform's persistent memory store.
One of those 233 tools, terminal_execute, runs whatever command it's handed inside the bridge container. Reaching it required nothing more than a correctly formatted HTTP request to a port most administrators never thought to check, because it wasn't the kind of port anyone expects to need firewalling - it's the coordination layer behind the AI agents, not a customer-facing service. That gap between "internal-feeling" and "internet-reachable" is exactly the same gap that made Arista's VeloCloud Orchestrator flaw, which we covered earlier this week, so dangerous: the component nobody thinks to expose-check is usually the one that was never checked at all.
What a compromised bridge actually hands over
Shell access was the headline capability, but not the only one worth losing sleep over. With the bridge open, an attacker could pull LLM provider API keys straight out of environment variables, read every conversation the agents had stored, and write directly into Ruflo's AgentDB memory store - meaning they could plant instructions that influence how the agents behave on future tasks, long after the initial access. That last capability is the one that should concern anyone running agentic AI in production: a memory-poisoning foothold doesn't need to be rediscovered or re-exploited, it just sits there quietly shaping outputs until someone notices something is off.
To the maintainer's credit, the response was fast. Reuven Cohen shipped a fix within 24 hours of the June 30 disclosure, landing in version 3.16.3: the MCP bridge now binds to loopback by default, terminal_execute and similar tools are gated behind server-side access controls, and the bundled MongoDB instance - previously open on port 27017 with no authentication of its own - now requires credentials. That's a genuinely good disclosure-to-patch turnaround. It doesn't undo the months the insecure default was the default, and open-source projects with this kind of adoption curve tend to have a long tail of deployments that never pull the update at all.
The pattern is bigger than one project
Ruflo is the third AI-tooling security story we've covered in two weeks with the same shape: a capability meant for the AI agent itself - a code editor's sandbox, a dataset pipeline, now a multi-agent coordination bridge - turns out to be reachable by anyone who can find it, because nobody treated it as a piece of production infrastructure that needed the same access controls as everything else. We wrote about the same dynamic when Cursor's sandbox could be escaped by content it only read, and it's the same conversation we have with clients building governance around Model Context Protocol adoption more broadly: MCP servers and bridges are infrastructure, not developer tooling, the moment they touch a shared network, and they need an inventory, an owner and an access policy like anything else that can execute code on your behalf.
- Identify every Ruflo instance in your estate - including ones spun up by individual engineers or teams outside a formal deployment process - and confirm it's running 3.16.3 or later.
- Audit network exposure for any MCP bridge, agent orchestration tool or AI coordination layer, regardless of vendor: confirm it binds to loopback or an internal-only interface, not 0.0.0.0.
- Rotate any LLM provider API keys that were reachable from an exposed Ruflo instance's environment, and review conversation logs for signs of prior access.
- Treat AI agent memory stores as a tampering target, not just a data store - if poisoning is possible, add integrity checks or periodic review, not just access control.
- Bring MCP bridges and similar AI coordination infrastructure into the same asset inventory and patch cadence as production services, before adoption outpaces governance rather than after.
The fix here was fast and the maintainer did the right thing once notified. The harder problem is upstream of any single project: teams are standing up agentic AI tooling faster than security review can keep pace with, often because it feels like a developer convenience rather than a production system. If you'd like help building an inventory and access model for the AI agent tooling already running inside your organisation, email sales@halfteck.com.