A pilha de agentes tem um problema de 1998

Na última semana de junho de 2026, um pequeno conjunto de CVEs atingiu as ferramentas de agentes de IA, duas delas no mesmo cliente de agente para desktop, ambas falhas de autorização, uma alojada bem dentro de um callback OAuth do MCP. Lida isoladamente, cada uma é uma falha de severidade média que um mantenedor corrige em um fim de semana. Lidas em conjunto, elas formam um sinal, e o sinal é estrutural: o ecossistema de agentes de IA acumula superfície de ataque mais rápido do que acumula a cultura de segurança capaz de defendê-la. Isso não é uma falha moral de nenhum projeto específico. É exatamente a condição em que a web estava por volta de 1998, quando uma linguagem se popularizou com padrões inseguros, as credenciais ficavam espalhadas por toda parte e a base instalada crescia mais rápido do que qualquer um conseguia endurecê-la. As ferramentas que guardam suas chaves e executam seu shell chegam com maturidade de segurança de 1998 para enfrentar um modelo de ameaças de 2026.

TL;DR

• O Cherry Studio, um cliente de agente de IA para desktop bastante popular, recebeu duas CVEs em 29 de junho de 2026: uma falha de autorização incorreta no servidor de callback OAuth do MCP (CVE-2026-13524) e um desvio de autorização em uma API de preload (CVE-2026-13534).¹²
• O padrão não se restringe a um aplicativo. As próprias ferramentas de referência do MCP saíram com falhas críticas de execução remota de código em 2025: mcp-remote com CVSS 9,6 (CVE-2025-6514) e o MCP Inspector da Anthropic com CVSS 9,4 (CVE-2025-49596).³⁴
• As ferramentas de agentes estão estruturalmente mais expostas do que as aplicações web jamais estiveram: guardam credenciais, executam código por design e ficam dentro das suas fronteiras de confiança (IDE, shell, navegador) em vez de atrás delas.
• O conhecimento para evitar essas falhas já existe. A especificação do MCP documenta em detalhe as classes de ataque do delegado confuso e do fluxo OAuth; a cultura de aplicá-lo em cada integração feita às pressas ainda não se propagou.⁵
• A web de 1998 só amadureceu depois que os worms tornaram a insegurança cara. O ecossistema de agentes ainda não tem uma função forçante equivalente, e os mesmos modelos que hoje encontram essas falhas podem escrever aquela que virá a ser essa função.

O conjunto, em concreto

O Cherry Studio é um cliente de desktop multiplataforma que se apresenta como um “estúdio de produtividade com IA, com chat inteligente, agentes autônomos e mais de 300 assistentes”, com suporte explícito a servidores do Model Context Protocol. É exatamente o tipo de ferramenta de que este ensaio trata: um agente voltado ao consumidor que intermedia suas chaves de API, executa integrações locais e busca a rede em seu nome.

Em 29 de junho de 2026, a VulDB publicou dois avisos contra ele. A CVE-2026-13524 é uma falha de autorização incorreta (CWE-285) no MCP OAuth Local Callback Server, em src/main/services/mcp/oauth/callback.ts, nas versões 1.9.0 até 1.9.6. O texto é direto: “A manipulação do argumento code leva a uma autorização incorreta”. Ela recebe CVSS 3.1 de 5,6, média.¹ A CVE-2026-13534 é um desvio de autorização (CWE-639) na API de preload CherryIN, até a versão 1.9.7 inclusive, com pontuação 5,0.² Nenhuma delas é manchete. As duas são o erro silencioso de autorização que uma equipe comete ao avançar rápido sobre uma superfície nova para todo mundo.

A primeira é o sinal revelador. Um callback OAuth em um cliente MCP é uma fronteira de confiança de manual: o ponto em que um servidor de autorização externo devolve um código para a sua máquina e a sua máquina decide se confia nele. Tratá-lo mal não é uma classe de falha exótica e inédita. É justamente aquela a que o próprio documento de segurança da especificação do MCP dedica mais tinta.

Descartei duas CVEs vizinhas da mesma janela, porque o conjunto precisa ser real: a CVE-2026-13533 é do agentejo Cockpit CMS, um gerenciador de conteúdo em PHP e não um framework de agentes, e a CVE-2026-13543 não pôde ser verificada de forma alguma. Alguns exemplos sólidos valem mais que uma lista inflada.

Por que as ferramentas de agentes estão estruturalmente em desvantagem

Uma aplicação web clássica de 1998 era insegura, mas vivia atrás de uma fronteira. Rodava em um servidor dentro do qual você não estava, seu raio de dano era o banco de dados e a sessão, e uma invasão dava ao atacante os dados da aplicação.

Uma ferramenta de agente inverte essa geometria. Roda na sua máquina ou dentro do seu IDE, guarda credenciais de longa duração para a sua nuvem e os seus repositórios, e executa código como recurso central em vez de como exploit. Não há fronteira atrás da qual se abrigar, porque a ferramenta é a fronteira, e ela é porosa por design.

Simon Willison nomeou o perigo com precisão em junho de 2025 com o “trio letal” (lethal trifecta): um agente se torna explorável quando combina “acesso aos seus dados privados”, “exposição a conteúdo não confiável” e “a capacidade de se comunicar externamente” de um jeito que permite roubar esses dados.⁷ Todo agente capaz tem os três por padrão, porque ler seus segredos, ingerir conteúdo influenciado por um atacante e fazer requisições de saída são seus recursos, não seus defeitos. O trio não é um caso extremo. É a configuração de partida.

Essa é a diferença estrutural. A aplicação web de 1998 precisava ser enganada para vazar os dados de uma única fronteira. O agente de 2026 chega pré-cabeado com todas as capacidades de que uma cadeia de exfiltração precisa, e a única coisa entre uma entrada maliciosa e as suas credenciais é se a ferramenta desenhou corretamente suas fronteiras internas de confiança. A falha de callback do Cherry Studio é a cara disso quando uma dessas fronteiras é desenhada um pouco errado.

A amplificação do MCP

O Model Context Protocol é o tecido conjuntivo da pilha de agentes de 2026, e ele multiplica a superfície de uma maneira bem específica: cada servidor MCP é uma nova integração privilegiada, em geral escrita às pressas, que o modelo pode invocar. Adicionar um não tem atrito. Auditar um tem. A base instalada de integrações está deixando para trás a população de gente que lê o código delas.

As ferramentas de referência mostram que isso não é problema de projeto amador. Em julho de 2025, a JFrog divulgou a CVE-2025-6514, uma injeção de comando de sistema operacional no mcp-remote, um conector usado por Claude Desktop, Cursor e Windsurf, que um servidor malicioso dispara com uma URL authorization_endpoint forjada durante o fluxo OAuth: crítica, CVSS 9,6.³ No mesmo mês, a Tenable divulgou a CVE-2025-49596, uma falha de execução remota de código de 9,4 no próprio MCP Inspector da Anthropic, em que a ausência de uma verificação de autenticação permitia que um site malicioso alcançasse uma porta local e, via rebinding de DNS, executasse comandos arbitrários.⁴

Duas das quatro CVEs deste ensaio são falhas de fluxo OAuth em ferramentas MCP: uma no servidor de callback, outra na descoberta de endpoints. Isso não é coincidência. OAuth em um cliente de agente é uma fronteira que se erra repetidamente, e a especificação diz isso em alto e bom som. O documento “Security Best Practices” do MCP, datado de 18 de junho de 2025, dedica sua seção mais longa ao “problema do delegado confuso” (confused deputy) e exige que servidores proxy implementem consentimento por cliente, validem o parâmetro OAuth state e façam a correspondência exata das URIs de redirecionamento.⁵ Isso foi publicado um ano antes de o Cherry Studio lançar sua falha de callback. A lacuna não é de conhecimento. É a distância entre o apêndice de segurança de uma especificação e a integração mediana escrita na terça-feira passada.

O prompt injection deixa a amplificação qualitativamente pior do que qualquer coisa que a web antiga enfrentou. Willison cunhou o termo em setembro de 2022, escrevendo “Proponho que o nome óbvio para isso seja prompt injection”, por analogia à injeção de SQL: instruções confiáveis e entrada não confiável concatenadas em uma única string que um motor então interpreta.⁶ Para um agente, o dado é um vetor, não apenas o código. Uma página web envenenada, um arquivo com armadilha, a descrição hostil de uma ferramenta: qualquer byte que o modelo leia pode carregar uma instrução. A especificação do MCP é categórica quanto a isso e alerta que um servidor malicioso pode transformar o cliente em um intermediário para exfiltração de dados.⁵ Não dá para corrigir isso escapando a entrada, porque a entrada é linguagem natural e o interpretador é um modelo.

A analogia de 1998, com precisão

A analogia precisa sobreviver à checagem de fatos ou não passa de uma impressão, então aqui está a época, com exatidão.

O PHP 3 saiu em junho de 1998 e colocou uma linguagem web dinâmica nas mãos de milhões com um padrão que hoje soa temerário: a entrada externa, vinda da query string, dos cookies ou do servidor, era registrada diretamente no escopo global. O register_globals estava ligado, e uma variável controlada por um atacante podia silenciosamente virar uma variável em que o seu código confiava. A correção levou quatro anos. O PHP 4.2.0, lançado em abril de 2002, mudou o padrão, e o anúncio da versão afirma isso sem rodeios: “Variáveis externas (do ambiente, da requisição HTTP, dos cookies ou do servidor web) não são mais registradas no escopo global por padrão”.⁸ A outra muleta que definiu a época, as magic quotes, rodava addslashes para fingir proteção contra injeção de SQL sem a substância, e sobreviveu ao register_globals por anos antes de o projeto finalmente matá-la. Padrões inseguros, uma ilusão de segurança, um atraso de vários anos até a cultura alcançar. Essa era a camada de aplicação da web jovem.

A cultura não chegou sozinha. Foi forçada. Em 19 de julho de 2001, o worm Code Red explorou um estouro de buffer no servidor web IIS da Microsoft e, pela contagem do CAIDA, “mais de 359.000 computadores foram infectados pelo worm Code-Red (CRv2) em menos de 14 horas”.⁹ Em 25 de janeiro de 2003, o worm Sapphire/Slammer atingiu um estouro de buffer no Microsoft SQL Server, se empacotou em pacotes de 376 bytes e “infectou a maior parte dos hosts vulneráveis que podiam ser encontrados em menos de dez minutos”, o worm de propagação mais rápida da história até aquele momento.¹⁰ Aqueles eram worms de infraestrutura, não falhas de PHP, e não vou misturar as coisas. O ponto é o formato da década: padrões inseguros em todas as camadas, e uma cultura de segurança que só amadureceu depois que a insegurança ficou visceral e publicamente cara. Seguro por padrão foi uma lição que a indústria pagou em worms.

Transponha isso para 2026 e a correspondência incomoda. Padrões inseguros: clientes de agentes que confiam em códigos de callback e pulam as verificações de consentimento. A ilusão de segurança: um pedido de permissão sobre um token com escopo admin:*. A base instalada explodindo: um servidor MCP para tudo, adicionado em um clique, auditado por ninguém. O que o ecossistema ainda não tem é o worm. Ele tem os padrões de 1998 e o perfil de alvo de 2001, e está esperando sua função forçante.

A postura do operador

Você não tem o luxo de esperar pela cultura. Você usa essas ferramentas agora, então é você quem desenha as fronteiras que o ecossistema ainda não desenhou para você. O enquadramento que uso é o trio como checklist operacional: para qualquer agente, pergunte o que ele pode ler, o que pode executar e o que pode exfiltrar, e coloque uma trava determinística em cada um desses pontos.

A coluna das travas não é aspiracional. Ela é determinística, e o determinismo é o ponto. Os hooks disparam em eventos de ciclo de vida com códigos de saída que o modelo não tem como contestar, e as regras de permissão são avaliadas antes de uma ferramenta rodar, não depois. Essa é a camada em que “o agente não deveria fazer X” vira “o agente não pode fazer X”, e é a única camada que um payload de prompt injection não consegue driblar na conversa. Quando você não pode confiar na entrada, e não pode confiar que o modelo se policie diante dela, você impõe a regra na fronteira que o modelo não controla.

Um segundo controle parece um recurso de produtividade, mas na verdade é de segurança. Quando um agente compila seu trabalho em um plano revisável antes de executar, revisar esse plano é uma revisão de segurança. Um script de workflow de quarenta linhas que nomeia cada ferramenta que vai chamar e cada arquivo que vai tocar é um modelo de ameaças que você lê em um minuto. Você não consegue auditar dez mil decisões ao vivo; consegue auditar o plano que as geraria, antes que ele gaste qualquer coisa.

E mantenha a assimetria à vista: a mesma capacidade que produz essas CVEs também as encontra. Um pesquisador da Anthropic usou um agente de código e um script de dez linhas para trazer à tona uma vulnerabilidade de 23 anos no kernel do Linux e 22 CVEs do Firefox. A ferramenta na sua mesa é um scanner de vulnerabilidades apontado para a sua própria pilha, se você apontá-lo. Os defensores já podem automatizar a descoberta hoje e estão construindo a camada de triagem agora. Essa é a única vantagem que a web de 1998 não teve.

Atualização de 24 de agosto: o registro desde a publicação

Este post argumentou que o conjunto de junho era um sinal estrutural, não azar. Sete semanas de registro desde então:

A cauda longa do MCP produz um fluxo constante de CVEs. Em uma única semana de meados de agosto, três servidores MCP da comunidade receberam CVEs: injeção de código no REPL Python do Jij-MCP-Server (CVE-2026-19964), execução de comandos por manipulação de argumentos no android-mcp-server (CVE-2026-19978) e falsificação de requisição do lado do servidor no mcp-florence2 (CVE-2026-19984).¹¹¹²¹³ Todas de severidade média — duas acionáveis remotamente, a terceira local à máquina em que o agente roda — e todas das classes clássicas: injeção, exec sem sanitização, SSRF, aterrissando em ferramentas que rodam com os privilégios de um agente. Este é o cenário que a seção sobre a amplificação do MCP dizia ser estrutural — uma cauda longa de integrações pequenas, cada uma um mcp-remote em potencial — e que agora chega na hora marcada.

Não é só a cauda da comunidade. O Azure SRE Agent — o agente de operações da própria Microsoft — recebeu a CVE-2026-62830 em 7 de agosto: autorização ausente permitindo elevação de privilégios pela rede, pontuada como 9,9 crítica.¹⁴ O argumento estrutural nunca foi sobre mantenedores amadores; é sobre o que as ferramentas de agentes são.

A pesquisa de ataque alcançou a cadeia de suprimentos. O ElasticBack demonstrou um backdoor condicional plantado em um único documento de skill de agente, apresentando as skills como “uma cadeia de suprimentos emergente em que uma única skill envenenada pode comprometer de forma persistente todo agente que a instala”.¹⁵ E a resposta do ecossistema à distribuição, o Agent Plugins 1.0, saiu com permissões e proveniência deixadas a cargo do cliente e sem nenhuma camada de assinatura — a camada de empacotamento chegou antes da camada de segurança, a mesma ordem que este post argumentou definir a pilha inteira: a capacidade sai primeiro, a cultura de segurança vem atrasada.

A previsão abaixo permanece sem edição.

A posição

Aqui está o que eu acho que vai acontecer, específico o bastante para estar errado. O ecossistema de agentes vai ganhar seu momento Code Red antes de ganhar sua cultura de segurança, porque foi nessa ordem que a web fez. A função forçante será, muito provavelmente, um payload de prompt injection autopropagável circulando entre agentes por servidores MCP compartilhados, ou um evento de exfiltração massiva de credenciais que se rastreie até uma única integração popular e pouco auditada. Vai ser barato de construir, porque os mesmos modelos que encontram falhas de kernel podem escrevê-lo, e o alerta de que “vem uma onda grande por aí” nunca foi só sobre defesa.

Depois que ela chegar, seguro por padrão deixa de ser opcional. Os clientes MCP vão sair com diálogos de consentimento ligados por padrão, audiências de token validadas e callbacks que rejeitam URIs de redirecionamento que não batem, do mesmo jeito que o PHP acabou saindo com o register_globals desligado. As camadas de permissão vão passar do opt-in para a negação por padrão. As integrações que sobreviverem serão as que trataram o apêndice de segurança da especificação como a própria especificação.

A parte incômoda é o cronograma. A web levou aproximadamente de 1998 a 2005 para internalizar o seguro por padrão, com anos entre os worms para pensar. A pilha de agentes compõe mais rápido, com um alvo de maior valor na máquina de cada desenvolvedor e uma cadeia de ferramentas de atacante que melhora a cada geração de modelos. O problema de 1998 é real. A única pergunta em aberto é se vamos agir sobre a analogia antes de o worm escrever o final, ou depois.

Principais conclusões

• Rode a auditoria do trio em cada agente. Anote o que cada ferramenta pode ler, executar e exfiltrar, e então confirme uma trava determinística em cada linha. Uma capacidade sem trava é a sua exposição, e o lugar onde o próximo payload vai aterrissar.
• Ponha os servidores MCP em lista de permissões; trate cada parâmetro de comando como execução não confiável. Adicionar uma integração é um clique e auditá-la não é, então limite o registro a uma lista revisada. Duas das quatro CVEs aqui foram falhas de fluxo OAuth em clientes MCP: o handshake é uma fronteira, não uma formalidade.
• Transforme o momento do plano no portão de revisão. Faça os agentes compilarem a intenção em um plano revisável e leia-o como um modelo de ameaças antes da execução. Um script que nomeia suas ferramentas e seus arquivos se audita em um minuto; dez mil chamadas de ferramenta ao vivo, não.
• Aponte o scanner para você primeiro. A capacidade que produz essas CVEs também as encontra. Rode varreduras de segurança assistidas por agentes no seu próprio código e nas suas dependências antes que outra pessoa rode as dela contra você.

FAQ

Os servidores MCP são seguros?

Não por padrão, e não de forma uniforme. MCP é um protocolo; sua segurança depende de como cada servidor e cada cliente o implementam. As divulgações de 2025 contra o mcp-remote (CVSS 9,6) e o MCP Inspector da Anthropic (CVSS 9,4) mostram que até as ferramentas de referência saíram com falhas críticas de RCE.³⁴ A especificação documenta as principais classes de ataque — delegado confuso, repasse de tokens, SSRF, comprometimento do servidor local — e prescreve mitigações concretas.⁵ Trate cada servidor como uma integração privilegiada: rode só os que você considera confiáveis ou que já auditou, coloque-os explicitamente em lista de permissões e assuma que qualquer servidor ao qual você se conecte pode influenciar o seu agente.

O que é prompt injection?

Prompt injection é quando um atacante contrabandeia instruções para dentro da entrada não confiável que um sistema de IA lê, e o modelo as segue como se viessem de você. Simon Willison cunhou o termo em setembro de 2022 por analogia à injeção de SQL: instruções confiáveis e entrada não confiável concatenadas em um único prompt que o modelo então interpreta, sem jeito confiável de dizer qual parte era a do atacante.⁶ Para agentes isso é especialmente perigoso porque o dado vira um vetor, e escapar caracteres não resolve, já que o interpretador é um modelo de linguagem.

O que é o trio letal?

É o nome dado por Simon Willison, em junho de 2025, às três capacidades que juntas tornam um agente explorável: acesso aos seus dados privados, exposição a conteúdo não confiável e a capacidade de se comunicar externamente.⁷ Um agente com as três pode ser manipulado por conteúdo injetado para ler seus segredos e enviá-los a um atacante. A maioria dos agentes capazes tem as três por padrão, e é por isso que a jogada é proteger cada capacidade em vez de torcer para o modelo resistir.

Como proteger um agente que roda na minha máquina?

Comece pela fronteira que o modelo não controla. Use regras de permissão e hooks avaliados antes de uma ferramenta rodar, para que um prompt comprometido não consiga negociar seu caminho até uma ação que você proibiu. Coloque ferramentas e servidores MCP em lista de permissões, exija consentimento antes de um novo servidor local executar e dê a cada credencial o menor privilégio possível, para que um token roubado tenha um raio de dano pequeno. Bloqueie requisições de saída para faixas de IP privadas e link-local para fechar o caminho de exfiltração. Depois revise o plano do agente antes de operações grandes, que é onde se pega a injeção que sobreviveu à fronteira de leitura.

Fontes