Ruflo CVSS 10.0 MCP桥接漏洞：为什么会是所有 AI 编码工具的安全警钟

TL;DR

Ruflo——一个整合了 Claude Code 和 Codex 的开源 AI Agent 元框架——被发现存在 CVSS 10.0 最高危漏洞 CVE-2026-59726（代号 RufRoot）。其默认配置将 MCP 桥接端口 3001 暴露在公网上，且无需任何认证。攻击者只需发送一个 HTTP POST 请求，就能在桥接容器中获得 shell、窃取所有 LLM API 密钥、读取对话历史、并在 AI 记忆库中注入恶意模式。补丁在 24 小时内发布，但仅打补丁远远不够：已泄露的密钥不会自动失效，被污染的 AI 记忆也不会因版本升级而清除。

发生了什么

2026 年 6 月 30 日，安全研究机构 Noma Labs 披露了 Ruflo 中的 CVE-2026-59726 漏洞。Ruflo 是一个开源的 AI Agent 元框架（meta-harness），可以在 Claude Code、Codex、Pi、OpenCode 等多个编码 Agent 之间切换，当时拥有超过 67,000 个 GitHub Star，在 MCPMarket 上排名第二。

漏洞本身极其简单。Ruflo 的默认 docker-compose 配置将 MCP 桥接服务暴露在 3001 端口，监听所有网络接口（0.0.0.0），且 POST /mcp 端点完全不需要认证。在桥接器暴露的 233 个工具中，有一个叫 terminal_execute。一次未认证的 HTTP POST 请求，就能在桥接容器中执行任意命令。

攻击者拿到 shell 后可以做三件事：

• 窃取 API 密钥：读取所有已配置的 LLM 提供商密钥（OpenAI、Anthropic、Google 等），这些密钥以明文形式存储在桥接容器的环境变量或配置文件中
• 读取对话历史：获取开发者与 AI Agent 之间的完整对话记录，其中可能包含业务逻辑、代码片段和敏感信息
• 污染 AI 记忆：向 Ruflo 的 AgentDB（一个持久化的 Agent 学习存储）注入恶意模式。AgentDB 用于记录 Agent 的行为模式以改进未来决策——攻击者注入的模式会在后续交互中被 Agent "学习"并执行

项目维护者 Reuven Cohen 在披露后 24 小时内发布了 v3.16.3 补丁。补丁将 MCP 桥接默认绑定到本地回环接口（localhost），为 terminal_execute 工具添加了服务端执行控制，并启用了 MongoDB 认证以防止对话窃取。

为什么打补丁不够用

大多数 CVE 漏洞的处理流程很简单：打补丁、轮换凭证、完事。RufRoot 不一样，有两个原因让它特别棘手。

AI 记忆污染是持久性的。 AgentDB 中存储的行为模式不会因为升级版本号而自动清除。如果攻击者在补丁前向 AgentDB 注入了恶意模式——比如让 Agent 倾向于推荐某个恶意 npm 包、跳过安全检查、或向外部域名发送数据——这些模式在升级后依然存在。Agent 的行为会缓慢退化，而不是突然崩溃，你很难第一时间发现。

已泄露的密钥不会自动失效。 如果你的 OpenAI 或 Anthropic API 密钥在漏洞窗口期内被窃取（攻击者只需一个请求就能读取），升级到 v3.16.3 不会让这些密钥失效。攻击者仍然可以使用它们。

Noma Labs 的修复建议明确反映了这一点：将所有 AI 提供商凭证视为已泄露并全部轮换、审计 AgentDB 中的异常模式、从干净的镜像重建容器——不是打补丁后就完事，而是从头重建。

为什么这事关整个 AI 编码工具生态

RufRoot 不只是 Ruflo 一个项目的问题。它暴露了一个正在 AI 编码工具生态中快速扩散的模式。

MCP（Model Context Protocol，模型上下文协议）已经成为 AI 编码 Agent 的通用连接器。Claude Code 用 MCP 调用工具，Codex 用 MCP，Cursor 和 GitHub Copilot 也支持 MCP。这个协议让 Agent 能够读取文件、执行命令、与外部服务交互——所有这些操作都通过一个标准化的桥接器完成。

问题在于：目前野外部署的大多数 MCP 桥接器是为便利而非安全设计的。开发者在本地 localhost 上跑桥接器，就假设它是安全的。但在 Docker Compose 部署、CI/CD 管道和云 VM 环境中，绑定到 0.0.0.0 的端口或通过容器网络可达的端口，就是一扇敞开的大门。Ruflo 的默认配置绑定到了所有接口——攻击者用 Shodan 搜一下就能找到你。

这不是一个理论上的攻击面。每一个暴露了工具调用端点且没有认证的 MCP 桥接器，都是一个等待被发现的命令执行入口。Ruflo 只是第一个被高调披露的案例。

你应该做什么

我跟几个开发者聊过，最常见的反应是"我又没用 Ruflo，跟我没关系"。你可能确实没用 Ruflo，但 MCP 桥接器的模式才是真正的风险。以下是需要检查的：

审计你运行的所有 MCP 桥接器。 不只是 Ruflo。检查你的 Claude Code MCP 配置、Codex 集成、Cursor 设置。任何接受未认证连接的桥接器都需要修复或加防火墙。

轮换所有 API 密钥。 如果你在 2026 年 7 月 1 日之前运行过 Ruflo，假设所有配置过的 LLM API 密钥都已泄露。全部轮换——OpenAI、Anthropic、Google，所有你连接过的提供商。

审计 AI 记忆存储。 如果你使用过 AgentDB 或 Ruflo 中的任何持久化 Agent 记忆，检查最近的条目。注意注入的提示词、异常的工具调用序列、或对陌生域名的引用。

从零重建容器。 在已被入侵的容器中升级版本号不是干净状态。从干净的镜像构建并重新部署。

像对待数据库端口一样对待 MCP 桥接器。 从现在开始，你部署的每个 MCP 桥接器都应该默认启用认证、仅监听本地回环、在防火墙后面——就像你对待数据库端口一样。当这些桥接器开始持有 API 密钥并执行命令的那一刻，"它只是个开发工具"就不再是有效的借口。

底线

RufRoot 是那种注定会发生的漏洞。我们拿一个为本地工具调用设计的协议，把它挂到互联网可达的基础设施上，然后假设默认配置能扛住。它扛不住。

MCP 桥接器就是命令执行端点。这个类别中的下一个漏洞不是"会不会"的问题，而是"什么时候"的问题。真正的问题是：你的桥接器会不会成为下一个被击中的目标——以及你是否做了足够的工作，让攻击者的成本变高而不是白捡。