Abuso do GitHub MCP: acesso a repositórios privados via MCP

• Foi descoberta uma vulnerabilidade grave na integração do GitHub MCP, que permite a um invasor manipular o agente do usuário por meio de uma GitHub Issue maliciosa e exfiltrar dados de repositórios privados
• Essa vulnerabilidade é um novo tipo chamado Toxic Agent Flow, em que o agente, induzido por prompts maliciosos, expõe dados indesejados em repositórios públicos
• A vulnerabilidade não decorre de uma falha na própria ferramenta, mas de uma limitação arquitetural, e hábitos de uso realistas, como políticas simples de confirmação de uso, ampliam o risco
• Para uma defesa eficaz, é necessário adotar proteções sistemáticas para agentes, como controle granular de permissões e monitoramento contínuo de segurança
• Como o simples alinhamento do modelo não é suficiente, são importantes medidas de segurança em nível de sistema em todo o ambiente de MCP e agentes

---

Visão geral

A Invariant descobriu uma vulnerabilidade extremamente grave na amplamente utilizada integração do GitHub MCP (14.000 stars). Essa vulnerabilidade permite que um invasor crie uma GitHub Issue maliciosa para manipular o agente do usuário e vazar dados de um repositório privado para fora

Este foi o primeiro caso descoberto pelo scanner automatizado de detecção de Toxic Agent Flow da Invariant. Nesses cenários, o agente é induzido a realizar ações não intencionais, causando danos como vazamento de dados ou execução de código malicioso

Como o setor vem adotando amplamente agentes de codificação e IDEs, este é um momento importante para aumentar a conscientização sobre esse tipo de ataque

Cenário de ataque

• Preparação do ataque

  • Parte-se do pressuposto de que o usuário conectou um cliente MCP, como o Claude Desktop, a um servidor GitHub MCP
  • <user>/public-repo: repositório público onde qualquer pessoa pode criar Issues
  • <user>/private-repo: repositório privado, onde ficam armazenados dados internos da empresa etc.
  • O invasor cria uma Issue maliciosa no repositório público, incluindo prompt injection
  • Quando o usuário faz um pedido comum como “mostre a lista de issues do public-repo”, o agente busca as Issues do repositório público e acaba exposto à injeção

• Fluxo do ataque

  • No momento em que lê a Issue maliciosa, o agente traz dados do repositório privado para o contexto e os publica no repositório público na forma de um PR, tornando-os acessíveis a qualquer pessoa
  • Esse processo é definido como Toxic Agent Flow, e pode ser detectado automaticamente em ambientes reais pelo analisador de segurança da Invariant

Demonstração do ataque

• Como exemplo, o ataque foi reproduzido usando o repositório público (ukend0464/pacman) e repositórios privados
• O invasor cria uma Issue maliciosa no repositório público, e a prompt injection é executada quando o agente consulta a lista de Issues desse repositório
• Quando o usuário pede suporte ao Claude 4 Opus, o Claude executa a injeção por meio da integração com o GitHub MCP
  • O Claude Desktop exige confirmação por padrão ao usar ferramentas, mas muitos usuários operam com a política de "sempre permitir" e acabam agindo sem atenção
• O agente extrai dados do repositório privado e os expõe em um PR público
• No experimento, até informações sensíveis como nome de projeto privado, plano de mudança de local de trabalho e salário foram vazadas

Detecção de Toxic Agent Flows

• Essa vulnerabilidade pode ocorrer mesmo sem comprometimento das próprias ferramentas MCP existentes, por causa de informações não confiáveis vindas de uma plataforma externa (GitHub)
• Como analisar e mitigar esse tipo de risco manualmente em sistemas de agentes de grande escala é extremamente complexo, a Invariant desenvolveu um método de detecção automatizado para permitir análise proativa de ameaças

Escopo do impacto e medidas de resposta

• Essa vulnerabilidade não se limita a um agente/cliente específico e afeta todos os agentes que usam servidores MCP
• Não se trata de uma falha no código do próprio servidor GitHub MCP, mas de um problema de projeto, portanto não pode ser resolvido com um patch no servidor GitHub
• São propostas duas estratégias principais de resposta

1. Controle granular de permissões

• Em ambientes com integração MCP, é necessário aplicar o princípio do menor privilégio para que o agente só possa acessar os repositórios estritamente necessários
• A autorização tradicional baseada em tokens impõe muitas limitações de usabilidade
• Com uma camada dinâmica de segurança em tempo de execução, como Invariant Guardrails, é possível reforçar o controle de acesso de acordo com o contexto do workflow
  • Exemplo de política: permitir o acesso a apenas um repositório por sessão para evitar vazamento de informações entre repositórios
  • Exemplo de definição de política:

    raise Violation("You can access only one repo per session.") if:
        (call_before: ToolCall) -> (call_after: ToolCall)
        call_before.function.name in (...set of repo actions)
        call_after.function.name in (...set of repo actions)
        call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
        call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    

  • É possível testar políticas no Guardrails Playground

2. Monitoramento contínuo de segurança

• Além de medidas preventivas, é necessário ter ferramentas robustas de monitoramento que façam varredura em tempo real das interações entre agentes e sistemas MCP
• Exemplo: adotar o Invariant MCP-scan para monitoramento e detecção de sinais anômalos
• Usando o modo proxy mais recente, é possível fazer diagnósticos em tempo real apenas desviando o tráfego MCP pelo proxy, sem alterar a infraestrutura atual
• Com monitoramento abrangente, é possível detectar vulnerabilidades, registrar tentativas de comprometimento e bloquear fluxos maliciosos precocemente

Por que o alinhamento do modelo é insuficiente

• Mesmo modelos de linguagem de última geração (por exemplo, Claude 4 Opus) continuam facilmente expostos a ataques simples de prompt injection
• O treinamento básico de alinhamento, por si só, não consegue impedir todos os ataques diversos e dependentes de contexto presentes em ambientes reais de implantação
• Portanto, é indispensável construir mecanismos de detecção de contexto e segurança em nível de sistema separadamente da camada do modelo

Conclusão

• A Invariant demonstrou uma vulnerabilidade grave no servidor GitHub MCP que permite dominar o agente com uma GitHub Issue maliciosa e vazar repositórios privados
• Essa vulnerabilidade é um caso representativo descoberto pelo sistema automatizado de detecção da Invariant, e ataques semelhantes continuam ocorrendo em vários ambientes, incluindo MCP
• O uso de scanners de segurança dedicados, como MCP-scan e Guardrails, é essencial para a adoção e operação seguras de sistemas MCP/agentes

Referência e contato

• Para aplicar medidas adicionais de segurança ou solicitar consultoria, é possível entrar em contato pelo e-mail [e-mail]

Autor:
Marco Milanta
Luca Beurer-Kellner

[crawler]

Parece algo grandioso, mas no fim é só um caso de prompt injection + permissões demais que o MCP pode usar.
Então dá a impressão de que estão promovendo uma ferramenta que permite controlar externamente as permissões do MCP.
Seria bom se as permissões que o MCP pode usar fossem diferentes entre prompts recebidos de fora e prompts inseridos apenas internamente.

[GN⁺]

Opinião do Hacker News

• Sinto que esse ataque não está sendo totalmente compreendido. Se você der um token de acesso ao Claude, então, independentemente da finalidade que você instruir, ele pode ser induzido a fazer qualquer coisa dentro das permissões desse token. Se você fornece credenciais a um LLM, deve assumir que todas as permissões dessas credenciais podem ser usadas pelo LLM. É preciso ter cuidado especial se as chamadas de uso de ferramentas forem aprovadas automaticamente. Mas o GitHub tem tokens de acesso com permissões granulares, então, se você conceder acesso apenas a um repositório específico, o alcance de um eventual abuso pelo LLM fica limitado. Esse ataque só é possível quando o LLM tem acesso à conta inteira, e o problema é justamente dar esse tipo de credencial arriscada ao Claude

  • A parte importante desse tema é que, como na maioria dos ataques de prompt injection, o LLM é colocado em um ambiente onde tem acesso simultâneo a pelo menos dois de três elementos: dados controlados pelo atacante, informações sensíveis e capacidade de exfiltração de dados. O princípio básico no design de agentes é permitir no máximo dois desses elementos ao mesmo tempo, e projetar com essa regra ajuda a evitar problemas de segurança. Por exemplo, no instante em que você visualiza uma issue criada por alguém não confiável, o contexto do LLM já está contaminado por dados criados pelo atacante. Depois, se ele for acessar informações sensíveis, recursos como conexão com a internet deveriam ser desativados. Seguindo esse modelo, dá para ser seguro mesmo sem tokens por repositório. Infelizmente o MCP não tem ferramentas que garantam isso

  • Existe o problema de permissões amplas demais no token, mas ao mesmo tempo os desenvolvedores não querem manter um token aberto para cada repositório. Então acabam dando permissões amplas ao token e confiando cegamente no LLM. Esse cuidado é sensato, mas na prática muitos atores do ecossistema não seguem isso. Uma razão pela qual este relatório é importante é que ele educa sobre o fato de que um LLM pode ser sequestrado se tiver permissões e dados não confiáveis. A solução é limitar dinamicamente o escopo de uso do token. Estamos pesquisando isso nesta lista

  • Isso é um tipo de problema que pode acontecer em serviços como o Railway. O Railway às vezes exige acesso a todos os repositórios do GitHub mesmo para implantar um único projeto, enquanto o Netlify respeita a escolha de conceder acesso apenas aos repositórios desejados. O GitHub deveria simplesmente impedir a aprovação de aplicativos que não respeitam esse modelo de acesso

  • É o mesmo fenômeno que sempre se repete quando surge uma nova tecnologia. As pessoas agem como se princípios básicos de segurança pudessem ser ignorados num contexto novo. Na realidade, não importa qual tecnologia “brilhante” e da moda você use, princípios básicos de segurança nunca devem ser ignorados. No mundo das criptomoedas também vimos velhos golpes e crimes financeiros sendo reproduzidos exatamente porque lições antigas foram descartadas sob a desculpa de que a tecnologia era diferente

  • Se um chatbot interage com o usuário, você deve presumir que ele fará qualquer coisa dentro do escopo permitido. Um chatbot é apenas uma camada de conveniência sobre APIs, não um mecanismo de segurança em si

• Se você se interessa por MCP e segurança de agentes, há vários materiais que produzimos. Veja o trace de execução do Claude para o cenário completo de ataque (link), o scanner de segurança para conexões MCP (link), o ataque de envenenamento de ferramentas MCP (blog), um caso de exploração do WhatsApp MCP (blog), a camada de segurança Guardrails para agentes (blog) e o AgentDojo, que avalia conjuntamente segurança e utilidade de agentes de IA (blog)

• Fico em dúvida se isso realmente merece ser chamado de “exploit”. Se você dá ao agente um token capaz de acessar repositórios privados, ele vai acessar. O MCP é só um servidor de API. O que você não quer expor por API não deveria sequer receber permissão

  • Como muita gente, eu também li os comentários antes do texto. Pelo conteúdo real do artigo, uma issue maliciosa é registrada no GitHub, e dentro dela há um prompt que usa o LLM para induzir exfiltração de dados. Quando o dono do repositório dispara o agente, ele passa a agir de acordo com esse prompt malicioso

  • Isso é um exploit genuíno de erro humano (ou excesso de confiança). O problema é que as pessoas caem no hype e entregam tranquilamente a um LLM um token privado e sensível com acesso ao GitHub inteiro

  • O assunto é importante, então quero cutucar um pouco: todo mundo precisa entender corretamente o risco da execução de ferramentas por IA. Os agentes hoje executam ferramentas com base em sua atenção atual (contexto), e essa atenção é facilmente influenciada por resultados de ferramentas ou por prompts. Mas nos comentários só se repete a ideia simplista de “isso aconteceu porque deram o token”. Além disso, mesmo depois de o problema ser explicado corretamente, continuam desfocando o ponto com “foi porque o usuário permitiu”. Isso me parece o argumento clássico e equivocado sobre o problema do confused deputy. Também se levanta a tese de “culpa do usuário”, mas na prática o próprio MCP não fornecer controles posteriores de acesso nem logs já é parte do problema. Eu só ficaria tranquilo se houvesse obrigatoriamente logging. E, embora ignorem a pesquisa de segurança chamando isso de “senso comum”, discutir segurança nunca é algo ruim. Uma vulnerabilidade não deixa de merecer discussão só porque é fraca. Dá até para dizer que é como SQL injection. E acho perigoso não entender a ideia de contaminar o sistema indiretamente (entregando payload malicioso por meio de uma issue pública). Por fim, é triste ver gente tão defensiva em vez de aberta a novas perspectivas

• Do ponto de vista de segurança, quando um LLM vê texto de uma fonte não confiável, deve-se assumir que essa fonte consegue influenciar a geração da saída do LLM da forma que quiser. Se esse resultado leva a uma chamada de ferramenta, então a fonte não confiável passa, na prática, a poder usar essa ferramenta. Procurando mais sobre isso, tive a impressão de que a documentação do Guardrails da invariant labs também tem um lado de marketing. É assustador, em termos de segurança, que a estrutura seja complicada a ponto de exigir produtos de guardrail desse tipo. Dá até uma sensação ruim pensar que, se as empresas de IA tivessem projetado tudo com segurança no centro desde o começo, talvez nem precisássemos desses produtos

  • Isso seria fácil de resolver só separando corretamente os valores de entrada. Basta marcar no prompt com tags como <github_pr_comment> e indicar explicitamente que isso deve ser tratado apenas como leitura, nunca interpretado como comando. Na verdade, esse ataque tem uma estrutura um pouco complexa. Lembra bastante os problemas antigos de prompt injection em chatbots. Agora o MCP também virou parte dessa discussão

  • Fico curioso se seria possível treinar o LLM para ignorar interpretação como instrução em trechos marcados como dados não higienizados (impuros)

  • Na prática, as empresas de IA até pensam em design de segurança. Mas este “exploit” só é possível quando a segurança foi desativada (com alertas bem claros). Por exemplo, o Claude Desktop por padrão exige confirmação explícita para cada chamada de ferramenta. Só que muitos usuários colocam em “sempre permitir” e deixam de monitorar as ações individuais

  • Esse padrão de vulnerabilidade em software se repete tradicionalmente há muito tempo, e é curioso e ao mesmo tempo absurdo como ele volta em toda tecnologia nova. O padrão de “receber entrada do usuário, interpretar e executar como comando num ambiente sem defesas adequadas” continua voltando. Vimos isso em SQL injection, XSS, include de PHP etc., e agora está se repetindo com LLMs

• Não acho que o MCP em si seja algo inovador ou especialmente vulnerável a hacking (embora eu tenha opiniões separadas sobre o MCP). Parece mais uma embalagem de marketing para técnicas de prompt injection. Quando projeto sistemas de agentes, sempre sigo a filosofia de que “tudo a que o agente pode acessar pode ser acessado por qualquer pessoa que consiga acessar esse agente”. Não delego controle de acesso ao LLM e deixo claro que a responsabilidade de segurança pelo que o agente faz é sempre do próprio solicitante. Do começo ao fim deste texto, o que realmente deveríamos observar é a quais recursos estamos de fato permitindo acesso pelo agente. Se você permite acesso a dados de e-mail, e um e-mail com prompt injection induz o LLM a roubar e transmitir um token de segurança, aí sim temos um risco realmente grave

  • Falar de MCP aqui dá a mesma sensação da moda de dez anos atrás de dizer “colocamos isso na blockchain”. A ideia de que “como o LLM é a entidade que aprova e age, então é preciso aplicar com rigor o princípio do menor privilégio” é algo óbvio para qualquer pessoa experiente, mas talvez mais uma geração precise reaprender esse básico

• O caso real de ataque e a reação do agente podem ser vistos aqui. O fato de o agente ter concluído o ataque com sucesso total é quase cômico

• Eu também usei o agente de programação Jules, do Google, há uma semana, e o pedido de permissão do GitHub OAuth exigia acesso total a todos os repositórios e permissões da conta. Esse design existe em parte por conveniência para desenvolvedores, e o próprio fluxo de autenticação do GitHub OAuth também contribui. Deveria ser muito mais simples conceder permissões limitadas por repositório e depois solicitar permissões adicionais quando necessário. Mas, na prática, a única saída parece ser criar uma conta separada no GitHub para conceder acesso apenas a certos repositórios (exemplo de conta). É bem incômodo. A própria documentação oficial do GitHub recomenda criar esse tipo de usuário máquina separado, mas deveria ser mais fácil definir o escopo padrão por repositório. Se alguém souber de uma maneira melhor, gostaria muito de ouvir

  • Na página de configurações do GitHub, você pode restringir as permissões do Jules a repositórios específicos

• Acho que a tese deste texto está exagerada demais. Sobre a explicação de que uma issue simples levou à exfiltração de dados, na prática isso só foi possível porque o usuário precisou tomar por conta própria várias medidas inseguras. Ou seja, foi preciso configurar um servidor MCP, fornecer credenciais com acesso a repositórios públicos e privados, permitir que o LLM acessasse esse servidor e lesse issues do repositório, além de ler explicitamente a issue maliciosa e configurar a divulgação externa do resultado. É um desfecho ruim, mas na prática isso não parece realmente uma “vulnerabilidade de segurança explorada maliciosamente por terceiros”. Foi o resultado de o próprio usuário mandar ler dados não confiáveis e mandar publicar o resultado em um lugar não confiável. Ainda assim, o GitHub MCP também tem certa responsabilidade. É problemático não impedir tratamento cruzado entre repositórios públicos e privados

  • Essencialmente, não se pode ignorar que até uma instrução simples como “por favor, resuma as issues” já pode levar à execução de comandos embutidos diretamente numa issue maliciosa

  • A perspectiva de marketing do MCP também importa. O protocolo em si deveria ser segmentado para permitir acesso apenas em ambientes ou por usuários confiáveis. O problema é que não existe uma forma padrão de definir escopo ou autenticação para servidores MCP. Tenho a sensação de que o problema de fundo está menos no GitHub MCP em si e mais no modo como a nossa indústria inteira está usando e implementando isso. Na prática, quando usamos servidores MCP customizados, adicionamos informações além da IA (ID, JWT etc.) justamente para bloquear por segurança

  • Com a febre atual de IA, a realidade é que muita gente aplica esse tipo de configuração e fluxo perigosos sem pensar muito. É fácil dizer “isso não deveria ser usado assim”, mas é exatamente por isso que guardrails são necessários. As pessoas frequentemente tomam decisões arriscadas

  • Sobre a ideia de não misturar repositórios públicos e privados, na prática isso são chamadas de ferramenta totalmente separadas. Do ponto de vista do servidor MCP, não há como detectar essa interação

• Percebi que a discussão agora está acontecendo nesta thread do HN

  • Como já foi mencionado lá também, o risco de segurança é claro. Em outras palavras, se você dá a um sistema permissão para acessar dados privados e ao mesmo tempo permite que usuários externos insiram texto arbitrário, acaba, na prática, dando a esses usuários externos acesso indireto aos dados privados. É um problema fácil de evitar se você seguir práticas padrão de segurança

  • Os comentários agora foram movidos e estão reunidos aqui

• MCP é apenas um protocolo; há muitos casos semelhantes, como A2A, ou até abordagens mais primitivas. Você também pode mandar o LLM ler a documentação da API do GitHub e usar a API com um token. Ainda nem todos os LLMs têm esse nível de capacidade, mas em breve terão. Tornar totalmente seguro o mecanismo de registro de ferramentas é algo próximo do impossível na prática. A responsabilidade final pela exfiltração de dados acaba recaindo sobre o LLM. Como os desenvolvedores querem produtividade com LLMs, ou a segurança será garantida, ou vamos acabar num cenário em que todo notebook terá de ganhar um firewall de segurança adicional. O ponto realmente complicado é que, no futuro, talvez vejamos até uma disputa de “LLM pegando LLM mal-comportado” que explora inclusive esses firewalls de segurança