RufRoot: an MCP bridge open to the network is a root shell with 233 tools

Noma Labs disclosed CVE-2026-59726 on July 30. The nickname is RufRoot, the score is CVSS 10.0, and the target is Ruflo, the open-source multi-agent orchestration harness that sits on top of Claude Code and Codex and has about 66.5k GitHub stars. The vulnerability is not a clever memory bug. It is a default. The MCP bridge listened on the network out of the box, with no authentication, and exposed 233 tools to anyone who could reach the port, including a shell, database operations, and the memory store. Every version below 3.16.3 is affected. The fix from maintainer Reuven Cohen binds the bridge to loopback and fails closed.

What an attacker gets

Read the tool list as a capability list. With no login, a remote caller could execute commands as the node, read the provider API keys the harness holds, and start swarms of agents billed to those keys. That is bad enough. The item I would put in bold for any team running agent memory is the fourth one: writing into the AgentDB learning store. That is not a one-off remote code execution. Poisoned memory is served to every future session on that instance, for every user, until someone notices. It is persistent, and it is invisible in the code.

An MCP endpoint is not an internal implementation detail. It is an untrusted network surface, and the tools behind it are the blast radius.

Why this is not a Ruflo story

The pattern "MCP bridge open to the network without auth" is not specific to one project. It is how a lot of agent tooling gets deployed: a local dev tool grows a network listener so a container or a second machine can reach it, the listener binds to 0.0.0.0 because that is what made the demo work, and nobody adds auth because the thing was local last month. The MCP protocol does not make this mistake for you, but it does not stop you either; the stateless spec revision due July 28 moves authorization closer to OAuth and OIDC, which helps only if you turn it on.

Ruflo happens to have 233 tools. Your harness probably has fewer. It still has a shell.

Hardening checklist

• Bind to loopback. No MCP bridge, yours or a client's, listens on 0.0.0.0 without a reason written down. If a remote client is required, put it behind a token or an OAuth flow, not an IP allowlist you will forget about.
• Fail closed. If the auth config is missing or malformed, the bridge refuses to start rather than starting open. That is exactly what the 3.16.3 fix does, and it is the right default for anything you write.
• Upgrade. Ruflo and anything derived from it: 3.16.3 or later, today.
• Inventory the tools. List every tool the bridge exposes and mark the ones that execute code, touch credentials, or write persistent state. Those need a second gate regardless of transport auth. The isolation patterns in sandboxing-coding-agents apply directly.
• Treat memory as untrusted input. Audit the AgentDB or whatever learning store you use for entries that look like instructions. Add integrity metadata: who wrote it, when, from which session. If your agent memory can be written from the network, your agent memory is the prompt injection vector.
• Rotate keys. If a bridge was ever reachable, assume the provider keys it held are burned.

The honest gap

I have not reproduced the exploit, and I am relying on Noma's disclosure and the coverage in The Hacker News and InfoWorld for the tool count and the impact list. I also do not know how many exposed instances existed; the disclosure does not give a number, and a 66.5k-star project running as a dev tool on laptops is a different exposure than the same project on a shared server. None of that changes the checklist. The bridge in front of your agent tools is a network service. Audit it like one.