Um POST HTTP. Sem token, sem header de autenticação, sem allowlist de IP. Foi só isso que a Noma Labs precisou pra tomar controle total de uma plataforma de agentes rodando em produção. A falha, batizada de RufRoot (CVE-2026-59726), recebeu nota CVSS 10.0, a máxima possível, e expôs 233 ferramentas de alto privilégio porque o bridge MCP da plataforma Ruflo simplesmente não pedia login pra ninguém.
O que é a falha RufRoot no bridge MCP do Ruflo?
Ruflo é uma plataforma open source de orquestração de agentes autônomos. O componente afetado é o MCP Bridge, um servidor Express.js que centraliza a invocação de ferramentas entre workflows de agentes: shell, banco de dados, gestão de outros agentes, armazenamento de memória. Até a versão 3.16.3, esse bridge escutava na porta 3001 sem exigir autenticação nenhuma.
Segundo o The Hacker News, um único POST não autenticado contra essa porta dava execução de comando completa dentro do container. Sem exagero: 233 ferramentas de alto privilégio expostas por HTTP puro, incluindo acesso a shell e operações de banco de dados.
"A single unauthenticated HTTP POST request to port 3001 gave full command execution inside the container. No token, no API key, no header check, no IP allowlist."
Fonte: relatório técnico da Noma Security
Por que isso importa pra quem roda qualquer agente de programação?
A parte que deveria tirar o sono de quem opera infraestrutura de IA não é só o RCE. É o que vinha junto. O docker-compose padrão do Ruflo repassava todas as chaves de provedor de LLM (OpenAI, Anthropic, Google, OpenRouter) como variáveis de ambiente, e os processos de backend herdavam esse ambiente inteiro via { ...process.env }. Um printenv despejava todas as chaves de uma vez. Fora isso, o bridge dava acesso de leitura a conversas armazenadas e permitia envenenar a memória persistente do agente, ou seja, plantar instrução maliciosa que sobrevive e volta a agir em sessões futuras.
Isso não é peculiaridade do Ruflo. É o padrão de boa parte dos bridges MCP self-hosted: configuração padrão prioriza "funciona rápido" sobre "só quem devia acessar, acessa". Quanto mais ferramentas um agente expõe (e 233 é um número que só cresce conforme a categoria amadurece), maior a superfície que fica aberta se ninguém checar o básico antes de subir em produção.
A resposta rápida não apaga o problema estrutural
Vale reconhecer o que a Ruflo fez certo: a Noma Labs reportou a falha em 30 de junho de 2026 com prova de conceito funcional, e os mantenedores lançaram correção em 24 horas. O patch mudou o bind do bridge pra interface loopback por padrão, colocou a ferramenta terminal_execute atrás de controle server-side e ativou autenticação no MongoDB usado pra guardar conversas, entre outras mudanças, segundo o InfoWorld.
Isso não vira desculpa pro resto do ecossistema. O problema de fundo continua de pé em qualquer projeto que decidiu que autenticação é opcional na v1 e "a gente adiciona depois". Depois, nesse caso, foi quando um pesquisador de segurança externo bateu na porta primeiro. Da próxima vez pode não ser um pesquisador que reporta com responsabilidade, e sim alguém que só quer as chaves.
Como proteger seu bridge MCP self-hosted?
Se você roda qualquer bridge MCP fora de um serviço gerenciado, quatro checagens resolvem a maior parte do risco:
- Bind em loopback, não em 0.0.0.0: o bridge não deveria estar acessível fora do host que o hospeda, a menos que exista uma razão explícita e um proxy autenticado na frente.
- Autenticação obrigatória em toda ferramenta de alto privilégio: shell, banco de dados e gestão de agentes não deveriam responder a request sem token validado.
- Nunca repassar o ambiente inteiro: processos que executam tools não deveriam herdar todas as variáveis do host. Cada chave de API entra explicitamente, não por
{ ...process.env }. - Auditoria de memória persistente: se o agente guarda instruções entre sessões, precisa existir um jeito de revisar e invalidar o que foi escrito lá, porque é exatamente esse mecanismo que vira vetor de envenenamento.
Nada disso é sofisticado. É o tipo de checklist que qualquer time de infra já aplica em API REST há anos. A novidade é que um agente com 233 ferramentas na mão esquece esse checklist com uma facilidade assustadora, porque o foco vai todo pro "o agente funciona", não pro "quem mais consegue falar com ele".
O que fica dessa história
CVSS 10.0, 233 ferramentas, chaves de quatro provedores diferentes expostas por uma env var mal segmentada, patch em 24 horas depois de meses rodando exposto por padrão. Não existe um vilão claro aqui, existe uma categoria inteira (orquestração de agentes via MCP) crescendo mais rápido do que a disciplina de segurança que deveria acompanhar.
Isso é parte do motivo pelo qual optamos por rodar o Verboo Code como serviço gerenciado, com os modelos abertos rodando em GPU dedicada nossa, em vez de te empurrar pra hospedar bridge, chave e memória de agente por conta própria. Você não decide se vai lembrar de bloquear a porta 3001. Simplesmente não existe uma porta 3001 sua exposta pra esquecer.
Hoje são 165 devs pagando pelo Verboo Code, crescimento de MRR de +50% no período, chegando a R$ 32.202,90. Ninguém migrou pra cá pensando em CVE. Migraram porque tokens ilimitados sem cap escondido já resolve metade da dor. A outra metade é não ter que virar administrador de segurança de infraestrutura de agente no tempo livre.
Se você quer entender o protocolo por trás dessa treta toda, o guia completo de MCP aqui no blog explica o que o protocolo resolve e onde ele ainda deixa a decisão de segurança na sua mão.
A Verboo Code aposta nessa direção: modelos open source, GPU dedicada, tokens ilimitados, sem te transformar em responsável pela superfície de ataque da sua própria ferramenta de trabalho. Saiba mais.
