As ferramentas MCP precisam de autorização em nível de ação

Em 17 de maio de 2026, o NVD publicou o CVE-2026-8719 para o AI Engine 3.4.9, um plugin do WordPress que expõe recursos de IA e MCP para sites WordPress.¹³

O modo de falha deveria incomodar qualquer pessoa que constrói com MCP. A Wordfence descreveu a ausência de uma verificação de capacidade do WordPress no caminho de autorização OAuth com token bearer do MCP: qualquer token OAuth válido conseguia acessar ferramentas MCP de nível administrativo sem verificar privilégios de administrador.² A Wordfence classificou o problema como 8,8 Alto e marcou a versão 3.5.0 como a versão corrigida.² O changelog do plugin diz que a versão 3.5.0 corrigiu a autorização OAuth e a validação de tokens do MCP ao exigir capacidade de administrador.³

A autorização do MCP falha quando um servidor trata a posse de um token bearer como permissão para usar todas as ferramentas. OAuth pode provar que um token chegou por meio de um fluxo de autorização. O servidor MCP ainda precisa decidir se aquela identidade pode executar aquela ferramenta, naquele recurso, com aquele raio de impacto.

Resumo

A especificação de autorização HTTP do MCP dá aos desenvolvedores uma base necessária: metadados de recurso protegido, fluxos OAuth 2.1, tratamento de tokens bearer, validação de tokens, verificações de audiência e respostas explícitas 403 Forbidden para escopos ou permissões insuficientes.⁴ O tutorial de segurança do MCP enquadra a autorização como a camada de proteção para recursos e operações sensíveis expostos por servidores MCP.⁵ Esses mecanismos não removem a decisão de autorização no nível da aplicação. O servidor ainda precisa mapear o token para um usuário, função, tenant, ferramenta, recurso, ação e política.

O CVE-2026-8719 transforma essa diferença em uma falha concreta. O AI Engine adicionou OAuth 2.1 e Dynamic Client Registration ao seu servidor MCP na versão 3.4.9, em 12 de maio, e depois corrigiu a autorização OAuth e a validação de tokens do MCP na versão 3.5.0, em 16 de maio, exigindo capacidade de administrador.³ A lição vai além do WordPress: todo servidor MCP que consegue alterar dados, publicar conteúdo, mudar configurações, ler registros privados, gastar dinheiro ou chamar APIs privilegiadas precisa de autorização em nível de ação abaixo do modelo e abaixo do cliente.

A distribuição de ferramentas aumenta o risco. Um artigo de maio de 2026 sobre clonagem de ferramentas analisou 8.861 repositórios de MCP e Skills, com 100.011 entradas de ferramentas, e encontrou altas taxas de clones verificados em faixas de alta similaridade.⁶ Modelos reutilizados podem espalhar bons padrões. Também podem espalhar verificações ausentes.

Principais pontos

Para quem constrói servidores MCP: - Valide tokens e depois autorize a ação concreta. Trate isso como barreiras separadas. - Retorne 401 para tokens inválidos ou ausentes e 403 para tokens válidos sem escopo ou permissão. - Teste tokens de baixo privilégio contra toda ferramenta de administração, escrita, publicação, exclusão, exportação e configuração.

Para equipes de segurança: - Revise servidores MCP como endpoints de aplicação, não como plugins de chat. - Pergunte a qual usuário, função, tenant, recurso e ação cada chamada de ferramenta corresponde. - Exija logs que mostrem identidade do token, nome da ferramenta, recurso, veredito de autorização e motivo da negação.

Para equipes de plataformas de agentes: - Contagens de catálogos de ferramentas não provam implementações independentes. - Verificações de similaridade e procedência importam porque ferramentas clonadas podem copiar lógica de autorização vulnerável. - Trate modelos de servidor como infraestrutura sensível à segurança.

Para operadores: - Atualize o AI Engine para 3.5.0 ou posterior se você usa o plugin WordPress afetado.²³ - Desative a exposição do MCP até saber quais funções do WordPress conseguem acessar quais ferramentas. - Comece cada nova conexão MCP em modo somente leitura e só amplie a autoridade depois que os testes provarem os caminhos de negação.

O que quebrou no AI Engine

O AI Engine apresenta o MCP como uma forma de conectar Claude Code, Claude, ChatGPT, OpenClaw e outros clientes a um site WordPress por meio de uma URL, um fluxo de login e uma etapa de aprovação.³ A versão 3.4.9 adicionou OAuth 2.1 com Dynamic Client Registration ao servidor MCP, para que clientes conduzidos pelo navegador pudessem se conectar sem um token bearer compartilhado.³

Essa direção de produto faz sentido. Tokens estáticos compartilhados não combinam com integrações MCP voltadas ao usuário. Fluxos OAuth conseguem vincular cliente, usuário e servidor com mais clareza do que segredos copiados e colados.

O bug estava uma camada abaixo. Segundo o NVD e a Wordfence, o caminho vulnerável aceitava qualquer token OAuth válido para acesso ao MCP, sem verificar privilégio de administrador antes de conceder acesso a ferramentas MCP de nível administrativo.¹² A diferença importa:

A descrição da correção na página do plugin WordPress usa a linguagem certa: a autorização OAuth e a validação de tokens do MCP agora exigem capacidade de administrador, impedindo escalonamento de privilégios por usuários não administradores.³ Essa frase nomeia a camada que estava faltando. Um token não substitui uma verificação de capacidade.

OAuth é necessário, mas não suficiente

A especificação de autorização do MCP cobre o fluxo no nível de transporte para transportes baseados em HTTP. A especificação diz que clientes MCP fazem solicitações a servidores MCP restritos em nome de proprietários de recursos, e ancora o fluxo em OAuth 2.1, metadados de recurso protegido, metadados de servidor de autorização, Dynamic Client Registration e uso de tokens bearer.⁴

Essas peças resolvem problemas reais:

A especificação do MCP também alerta sobre riscos de confused deputy e repasse de tokens. Servidores MCP precisam validar que os tokens apresentados têm como destino o servidor MCP e não devem repassar para APIs upstream um token recebido do cliente MCP.⁴ Essa orientação protege a fronteira entre serviços.

A autorização em nível de ação protege a fronteira dentro do servidor MCP.

Um servidor MCP pode expor 10 ferramentas ou 100. Algumas ferramentas leem metadados públicos. Algumas leem registros privados. Algumas rascunham mudanças. Algumas alteram estado de produção. Algumas administram usuários, plugins, pagamentos, tarefas, mensagens ou infraestrutura. Um token válido não deveria alcançar automaticamente todas as ferramentas só porque o servidor aceitou a sessão.

A cadeia correta é esta:

1. Valide emissor, assinatura, expiração, audiência e regras de transporte do token.
2. Resolva o token para uma identidade local: usuário, conta de serviço, organização, tenant ou automação.
3. Carregue a função, os escopos, as concessões, os orçamentos e a política dessa identidade.
4. Classifique a ferramenta MCP solicitada por tipo de ação e risco.
5. Verifique o recurso de destino, não apenas o nome da ferramenta.
6. Retorne 403 quando o token for válido, mas a ação exceder a autoridade.
7. Registre a decisão com detalhes suficientes para revisão.

OAuth leva a solicitação até o ponto de decisão. A autorização decide se a ação pertence ali.

Chamadas de ferramenta precisam de uma matriz de permissões

Ferramentas de agentes tornam hábitos antigos de endpoints mais perigosos. Uma rota web normal costuma ter um caminho de UI estreito ao redor dela. Uma ferramenta exposta ao modelo fica dentro de um planejador. O agente pode tentar de novo, encadear chamadas, inspecionar descrições de ferramentas, combinar resultados de leitura com ações de escrita e carregar instruções de conteúdo não confiável para etapas posteriores.

Esse comportamento muda o modelo mínimo de permissões. Um servidor não deveria perguntar apenas “este usuário pode acessar MCP?”. O servidor deveria perguntar “este usuário pode executar esta ação por meio desta ferramenta contra este recurso agora?”.

Use uma matriz:

Essa matriz combina com o padrão de chaves de agentes precisam de orçamentos de risco. Credenciais não deveriam se comportar como strings bearer genéricas. Elas deveriam se comportar como objetos de autoridade delimitada, com limites no servidor, logs de atividade, revogação e padrões conservadores.

Ela também combina com o enquadramento de propriedade em a propriedade dos agentes de IA é o primitivo de confiança. Toda chamada privilegiada de ferramenta deveria corresponder a uma conta responsável, sessão, pacote de autoridade, caminho de revisão e caminho de interrupção.

Ferramentas clonadas podem copiar a mesma verificação ausente

O bug do AI Engine importaria mesmo se todo servidor MCP viesse de uma implementação independente e cuidadosa. O ecossistema de ferramentas não parece tão limpo.

Kim, Jiang, Hu, Jia e Gong publicaram, em 10 de maio de 2026, um artigo medindo clonagem de ferramentas em ecossistemas de IA agentiva. O conjunto de dados cobriu 7.508 repositórios MCP com 87.564 ferramentas extraídas e 1.353 repositórios de Skills com 12.447 ferramentas, totalizando 8.861 repositórios e 100.011 entradas de ferramentas.⁶ Os autores usaram similaridade de Jaccard no nível de tokens e similaridade estrutural difusa com ssdeep, depois verificaram manualmente pares amostrados em faixas de similaridade.⁶

O resumo relata que 60% dos candidatos de alto Jaccard e 85% dos candidatos de alto ssdeep no ecossistema MCP foram verificados manualmente como clones.⁶ O artigo argumenta que duplicação oculta pode contaminar divisões de benchmark, propagar implementações vulneráveis, enviesar medições de generalização no uso de ferramentas e levantar preocupações de procedência, atribuição e licença.⁶

Essa descoberta muda como equipes deveriam interpretar o crescimento de catálogos de MCP. Mais ferramentas não significam automaticamente mais revisão de segurança independente. Uma estrutura-base de servidor repetida pode dar consistência ao ecossistema. A mesma repetição pode copiar o mesmo padrão fraco de autenticação e autorização por muitos pacotes.

Por isso, a revisão de segurança deve incluir procedência:

Skills de agentes precisam de gerenciadores de pacotes defendeu distribuição em estilo de pacote, procedência e política ao redor de skills. Servidores MCP precisam da mesma disciplina, mais testes de autorização em tempo de execução.

A suíte mínima de testes para autorização MCP

Todo servidor MCP que toca dados privados ou mutáveis deveria entregar uma suíte de testes de autorização. Testes unitários que confirmam o caminho feliz não bastam. O comportamento perigoso mora nos caminhos de negação.

Comece com estes casos:

O código de status exato pode seguir a política do produto, mas a distinção deve permanecer: credenciais inválidas falham antes da resolução da identidade, e credenciais válidas com autoridade insuficiente falham na barreira de autorização. A especificação do MCP nomeia 401 para autorização ausente ou inválida e 403 para escopos inválidos ou permissões insuficientes.⁴

Para WordPress, a mesma regra fica mais nítida: ferramentas MCP que executam operações administrativas deveriam verificar as mesmas capacidades do WordPress que o painel, a API REST ou o caminho interno em PHP verificariam. Uma função de menor privilégio não deveria ganhar um novo caminho para comportamento administrativo só porque a chamada chegou por um protocolo exposto ao modelo.

O que a revisão de catálogos deveria exigir

Catálogos de MCP e diretórios de plugins deveriam tratar metadados de autorização como dados de pacote de primeira classe. Um usuário decidindo se ativa um servidor precisa de mais do que uma contagem de ferramentas.

Metadados públicos mínimos:

Esses campos não eliminariam ferramentas vulneráveis. Eles tornariam a superfície de revisão real. Operadores poderiam comparar a autoridade declarada com o código de fato, e catálogos poderiam agrupar implementações semelhantes quando um defeito aparecesse.

Essa é a ponte que falta entre a especificação de autorização do MCP e o artigo sobre clonagem de ferramentas. A especificação diz aos implementadores como fazer o fluxo no nível do protocolo. O ecossistema precisa de procedência no nível do pacote e evidência de autorização em nível de ação para que implementações repetidas não repitam as mesmas verificações ausentes.

O que construir no lugar

Construa a autorização do MCP como um pipeline:

1. Barreira de protocolo: verifique metadados de recurso protegido, fluxo OAuth, posicionamento do token, validade do token, expiração, emissor e audiência.
2. Barreira de identidade: mapeie o token para usuário, conta de serviço, função, tenant e espaço de trabalho.
3. Barreira de ferramenta: classifique toda ferramenta por leitura, rascunho, escrita, exclusão, publicação, exportação, administração, execução ou gasto.
4. Barreira de recurso: autorize o objeto de destino exato ou a fronteira de tenant.
5. Barreira de orçamento: aplique limites de taxa, tamanho, gasto, audiência e tempo antes da execução.
6. Barreira de aprovação: exija aprovação humana ou por política para ações de alto risco.
7. Barreira de auditoria: registre vereditos de permissão, negação e revisão obrigatória em um lugar que operadores consigam inspecionar.

As barreiras devem ficar fora do modelo. Uma descrição de ferramenta pode dizer ao agente para evitar ações administrativas. Um prompt pode pedir cautela. Nenhum dos dois deve carregar a fronteira. O servidor deve rejeitar ações não autorizadas mesmo quando o agente pede com educação, confiança ou insistência.

O ambiente isolado do seu agente é uma sugestão chega ao mesmo ponto por outro ângulo: permissões válidas ainda podem se combinar em comportamentos inseguros. Ferramentas MCP precisam de autorização na fronteira da ação porque o agente vai compor ações mais rápido do que uma pessoa consegue simular mentalmente.

FAQ

O MCP exige OAuth?

Não. A autorização do MCP é opcional, e a especificação de autorização HTTP se aplica quando uma implementação oferece suporte a autorização em transportes baseados em HTTP. A mesma especificação diz que transportes STDIO devem recuperar credenciais do ambiente em vez de seguir o fluxo OAuth HTTP.⁴

OAuth resolve a autorização do MCP?

OAuth resolve apenas parte do problema. OAuth pode estabelecer um fluxo de autorização, emitir tokens e permitir que um servidor MCP protegido valide tokens bearer. O servidor MCP ainda precisa decidir se a identidade do token pode executar a ação específica da ferramenta contra o recurso de destino.

O que o CVE-2026-8719 provou?

O CVE-2026-8719 provou que um caminho com token válido ainda pode deixar de aplicar capacidades locais. O NVD e a Wordfence descrevem o AI Engine 3.4.9 como aceitando qualquer token OAuth válido para acesso ao MCP, sem verificar privilégio de administrador antes que ferramentas MCP de nível administrativo ficassem acessíveis.¹²

O que os desenvolvedores de MCP deveriam testar primeiro?

Teste primeiro os caminhos de negação: token de baixo privilégio para ferramenta administrativa, token somente leitura para ferramenta de escrita, token válido para recurso de outro tenant, token expirado, token com audiência errada e ferramenta destrutiva sem aprovação. Passar no caminho feliz do OAuth não prova autorização em nível de ação.

Por que clonagem de ferramentas importa para a segurança do MCP?

Clonagem de ferramentas importa porque implementações repetidas podem repetir o mesmo middleware vulnerável, atalhos de autenticação e autorização e verificações ausentes. O artigo de maio de 2026 sobre clonagem de ferramentas encontrou altas taxas de clones verificados em candidatos MCP de alta similaridade e alertou que duplicação oculta pode propagar implementações vulneráveis.⁶

Referências