Exploração do GitHub MCP: acesso a repositórios privados via MCP

• Um agente MCP conectado à conta do GitHub pode abrir um caminho de exfiltração de dados de repositórios privados apenas ao ler uma Issue pública
• O ataque começa quando uma injeção indireta de prompt embutida em uma Issue de repositório público altera o fluxo de uso de ferramentas do agente
• Na demonstração, uma Issue maliciosa em ukend0464/pacman exporta informações de repositórios privados para um PR público por meio da integração entre Claude 4 Opus e GitHub MCP
• O cerne do problema não está em uma falha no código do servidor GitHub MCP, mas na arquitetura em que ferramentas confiáveis são usadas junto com conteúdo externo não confiável
• Sistemas de agentes precisam de monitoramento de segurança em tempo de execução, como o MCP-scan, além de privilégio mínimo por repositório e restrições de acesso por sessão

---

Ataque ao GitHub MCP iniciado por uma Issue maliciosa

• A Invariant descobriu uma vulnerabilidade na amplamente usada integração GitHub MCP, na qual um invasor pode tomar controle do agente do usuário e exfiltrar dados de repositórios privados
  • O servidor GitHub MCP em questão é um projeto com 14k stars no GitHub
  • A vulnerabilidade é um dos primeiros casos de Toxic Agent Flows detectados pelo analisador de segurança da Invariant
• Toxic Agent Flow é um fluxo em que uma injeção indireta de prompt faz o agente executar uma sequência de uso de ferramentas diferente da pretendida
  • Isso pode levar a ações como exfiltração de dados ou execução de código malicioso
• Com agentes de programação e IDEs sendo implantados rapidamente, ataques semelhantes podem atingir usuários de ferramentas essenciais de desenvolvimento de software

Estrutura do ataque

• O usuário utiliza um cliente MCP como o Claude Desktop e tem o servidor GitHub MCP conectado à sua conta do GitHub
• O cenário de ataque assume dois tipos de repositório
  • <user>/public-repo: repositório público em que qualquer pessoa pode criar Issues e bug reports
  • <user>/private-repo: repositório privado com código proprietário ou dados internos da empresa
• O invasor pode criar uma Issue maliciosa no repositório público seguindo as regras normais de permissão do GitHub
• Quando o usuário envia ao agente um pedido legítimo como Have a look at the open issues in <user>/public-repo, o agente busca as Issues do repositório público e fica exposto à injeção de prompt
• Depois disso, o agente pode trazer dados do repositório privado para o contexto e exfiltrá-los em um PR gerado automaticamente no repositório público

Fluxo de exfiltração confirmado na demonstração

• A demonstração usa o repositório público ukend0464/pacman e vários repositórios privados
  • ukend0464/pacman: repositório público com uma implementação simples do jogo Pacman, disponível no GitHub
  • Os repositórios privados contêm projetos pessoais do usuário e informações sensíveis
• O invasor posiciona uma Issue maliciosa no repositório público
  • A Issue contém um payload que será executado quando o agente consultar a lista de Issues do repositório público
• O usuário envia uma solicitação ao Claude 4 Opus, acionando o ataque
  • O Claude Desktop exige confirmação do usuário por padrão para cada chamada individual de ferramenta
  • Muitos usuários escolhem a política de confirmação “Always Allow” ao usar agentes e deixam de monitorar ações individuais
• Ao percorrer a lista de Issues, o agente encontra o payload do ataque, traz dados do repositório privado para o contexto e os exfiltra no pull request do repositório pacman
• O PR público inclui informações privadas do usuário ukend0464
  • Informações sobre repositórios privados como Jupiter Star
  • Planos de se mudar para a América do Sul
  • Informações salariais
• Toda a cadeia de raciocínio do agente e a sequência de uso de ferramentas podem ser vistas no trace completo do Invariant Explorer

Toxic Agent Flow também ocorre com ferramentas confiáveis

• Essa vulnerabilidade é diferente dos ataques tradicionais de contaminação de ferramentas, nos quais a própria ferramenta MCP precisa ser comprometida
• Se um agente conectado a uma plataforma externa como o GitHub for exposto a informações não confiáveis, o problema pode surgir mesmo que a ferramenta continue totalmente confiável
• Entender, analisar e mitigar esses fluxos em sistemas de agentes é algo difícil de fazer manualmente em larga escala
• A Invariant está desenvolvendo métodos automatizados para detectar Toxic Agent Flows, para que organizações possam identificar e modelar ameaças potenciais antes que sejam exploradas por agentes maliciosos

Escopo e mitigação

• O experimento foi focado no Claude Desktop, mas a vulnerabilidade não se limita a um agente específico nem a um cliente MCP específico
• Qualquer agente que use o servidor GitHub MCP pode ser afetado, independentemente do modelo-base ou da implementação
• O ponto importante é que esse problema não é uma falha no código do próprio servidor GitHub MCP
  • Não é uma vulnerabilidade que o GitHub possa corrigir sozinho apenas com um patch no lado do servidor
  • Trata-se de um problema estrutural que precisa ser tratado no nível do sistema de agentes

• Controle granular de permissões

  • Ao usar integrações MCP como a do GitHub, o acesso do agente deve ser limitado aos repositórios necessários
  • Permissões tradicionais baseadas em token oferecem alguma proteção, mas podem impor restrições rígidas que limitam a funcionalidade do agente
  • A Invariant recomenda uma camada de segurança dinâmica em tempo de execução adaptada a sistemas de agentes
  • O Invariant Guardrails oferece controle de acesso sensível ao contexto que se adapta ao workflow do agente
  • Um exemplo de política limita o acesso a apenas um repositório por sessão, evitando vazamento de informações entre repositórios
  • Se chamadas de ferramentas relacionadas a repositório em repo ou owner diferentes ocorrerem em sequência, isso é tratado como violação
  • A política completa está disponível em github_policy.txt
  • O modo de aplicação está descrito na documentação do MCP-scan
  • É possível testar políticas antes da implantação no Guardrails Playground

• Monitoramento contínuo de segurança

  • Junto com medidas preventivas, é necessário monitoramento para detecção e resposta a ameaças em tempo real
  • A Invariant recomenda implantar scanners de segurança dedicados como o MCP-scan para auditar continuamente as interações entre agentes e sistemas MCP
  • O modo proxy do MCP-scan permite varrer conexões MCP em tempo real sem modificar a infraestrutura existente do agente
  • Ao rotear o tráfego MCP por um proxy, obtém-se visibilidade e varredura em tempo real de violações de segurança
  • Um monitoramento abrangente cria trilhas de auditoria que ajudam a verificar vulnerabilidades potenciais, tentativas de exploração e o estado de proteção contra novos ataques

Só alinhamento de modelo não basta

• O experimento usou o Claude 4 Opus, com treinamento recente de alinhamento e segurança
• Mesmo com treinamento de segurança forte, o agente pôde ser manipulado por uma injeção de prompt relativamente simples
• Muitas defesas existentes de detecção de injeção de prompt também não conseguiram bloquear esse ataque
• A segurança de sistemas de agentes depende do contexto e do ambiente
  • Treinamento geral de alinhamento de modelo não consegue prever todos os cenários de implantação nem requisitos de segurança específicos de cada organização
  • Medidas de segurança no nível do sistema devem complementar as proteções no nível do modelo

Desafios que continuam na segurança de agentes

• Agentes que usam o servidor GitHub MCP podem ser manipulados por meio de Issues maliciosas no GitHub e exfiltrar dados de repositórios privados para repositórios públicos
• Embora esta vulnerabilidade seja específica do GitHub MCP, ataques semelhantes continuam aparecendo em outros ambientes
  • A Legit Security relatou recentemente uma vulnerabilidade de injeção remota de prompt no GitLab Duo
• Para implantação responsável em larga escala, integrações MCP e sistemas de agentes precisam de scanners de segurança dedicados e controles de política como MCP-scan e Guardrails

[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.