Uma vulnerabilidade de injeção de prompt em comentários HTML invisíveis permite que atacantes manipulem agentes de revisão de código para exfiltrar dados confidenciais de projetos restritos usando as credenciais do revisor.
| Componente | Servidor oficial Microsoft Azure DevOps MCP (Model Context Protocol), especificamente a ferramenta repo_get_pull_request_by_id |
| Vetor | Injeção de prompt indireto através de comentários HTML ocultos em descrições de Pull Requests que não são sanitizados pela função de spotlighting (createExternalContentResponse) |
| Impacto | Comportamento de confuso-deputado onde o agente de IA executa ações não autorizadas (leitura de wikis, trigger de pipelines, exfiltração de secretos) em projetos externos sob as permissões do usuário vítima |
| Prioridade | Restringir tokens de agente ao princípio de menor privilégio, limitar escopos de domínios MCP (-d) e auditar trilhas de ferramentas para atividades entre projetos |
Uma falha de segurança no servidor oficial do Model Context Protocol (MCP) para o Microsoft Azure DevOps expõe organizações a ataques de injeção de prompt que podem comprometer a integridade de agentes de inteligência artificial. O problema decorre da ausência de mecanismos de proteção contra injeção de prompt em uma função específica que retorna dados de Pull Requests (PRs). Enquanto outras ferramentas do mesmo servidor utilizam uma técnica de defesa conhecida como 'spotlighting' para isolar conteúdo não confiável, a função responsável por buscar detalhes de PRs entrega o texto bruto diretamente ao modelo de linguagem, sem qualquer delimitação ou sanitização.
O cenário explora a discrepância entre o que é renderizado na interface web do Azure DevOps e o que é retornado pela API REST. A interface aceita Markdown, que suporta comentários HTML. Esses comentários são renderizados como espaços em branco ou invisíveis para o revisor humano, mas são preservados integralmente na resposta da API. Quando um agente de IA é acionado para analisar o código, ele interpreta esses comentários ocultos como instruções legítimas. Como o agente opera com as permissões do usuário que o invocou, normalmente um desenvolvedor sênior ou revisor com acessos elevados, o atacante consegue escalar seus privilégios indiretamente, acessando projetos, wikis e pipelines aos quais não teria direito direto.
O ataque se inicia quando um usuário com permissão de escrita em um projeto cria um Pull Request contendo uma carga maliciosa oculta. A carga é inserida na descrição do PR usando a sintaxe de comentário HTML. Na interface visual, o PR parece legítimo, contendo apenas alterações de código aparentemente inofensivas. No entanto, nos bastidores, o parâmetro repo_get_pull_request_by_id do servidor MCP é chamado para recuperar o contexto do PR.
Diferente de outras ferramentas do mesmo servidor, como as de leitura de wiki ou logs de build, essa função específica não invoca o auxiliar createExternalContentResponse. Esse auxiliar é responsável por envolver o conteúdo externo em delimitadores claros, informando ao modelo que o texto subsequente é dado e não instrução. Sem essa camada, o modelo recebe a carga oculta como parte do fluxo de comandos. Se o agente estiver configurado para aprovar automaticamente a execução de ferramentas (auto-approve posture), ele seguirá a instrução oculta, podendo acionar pipelines em outros projetos, ler páginas de wiki confidenciais ou realizar operações de escrita, e posteriormente enviar os dados obtidos de volta para o atacante, por exemplo, postando como comentário no próprio PR malicioso.
A vulnerabilidade afeta ambientes de desenvolvimento que utilizam o servidor MCP do Azure DevOps para integrar agentes de IA aos fluxos de trabalho. O risco é amplificado em configurações onde o agente possui acesso amplo (broad token) e permissão para executar ferramentas sem solicitação de confirmação humana para cada passo. Revisores que possuem privilégios superiores aos dos usuários que abrem os PRs são os alvos primários, pois suas credenciais fornecem o caminho para a escalada de privilégios.
Embora a análise inicial tenha focado no servidor local baseado em PAT (Personal Access Token), a lógica sugere que o servidor remoto hospedado também é suscetível, uma vez que a falha está na lógica de processamento de código do servidor e não no transporte de autenticação. Qualquer workflow automatizado de revisão, triagem ou sumarização que depende de gatilhos automáticos e processamento de conteúdo de PRs está exposto, pois a injeção ocorre sem a necessidade de interação humana em tempo real após a abertura do PR.
- Servidor Azure DevOps MCP (versões verificadas até v2.8.0)
- Ferramentas de AI Code Review (Copilot CLI, Claude Code) integradas ao Azure DevOps
- Revisores com permissões elevadas cross-projeto
- Workflows de CI/CD acionados por agentes via MCP
A detecção dessa atividade maliciosa requer a análise dos logs de rastreamento de ferramentas (tool traces) gerados pelos agentes de IA. Equipes de segurança devem procurar por sequências de operações que não se justificam pelo contexto de uma revisão de código padrão, especificamente chamadas de API que atravessam limites de projetos. A presença de leituras de wiki ou execuções de pipeline em projetos não relacionados ao PR em análise é um forte indicador de comprometimento.
Além da análise de comportamento, é recomendável varrer o banco de dados de Pull Requests em busca de comentários HTML ocultos. Como a interface web mascara esse conteúdo, a varredura deve ser realizada via script consultando a API REST ou diretamente no backend, procurando por padrões como <!-- e --> dentro dos campos de descrição. A identificação de tais artefatos em PRs antigos pode indicar tentativas anteriores de exploração ou testes de conceito realizados por usuários internos ou atacantes.
- Monitorar tool traces para pipelines acionados cross-projeto durante revisões
- Alertar sobre leituras de wiki de projetos restritos por agentes de IA
- Varrer descrições de PRs via API em busca de tags de comentário HTML ocultas
- Auditar comentários postados por agentes que contenham dados sensíveis ou estrutura de wiki
A mitigação imediata envolve a aplicação estrita do princípio do menor privilégio aos tokens utilizados pelos agentes de IA. Os tokens devem ser limitados escopos estritos ao projeto sob revisão, impedindo que o agente atue em outros repositórios ou recursos da organização. Operadores devem configurar o servidor MCP local utilizando a flag -d para carregar apenas os domínios MCP necessários para a tarefa, reduzindo a superfície de ataque disponível para o agente explorar.
Organizações devem desabilitar a postura de auto-aprovação de ferramentas. Requerer confirmação humana para operações sensíveis, especialmente aquelas que envolvem escrita ou acesso a recursos fora do contexto atual, interrompe a cadeia de ataque. Em nível de código, a correção definitiva envolve a aplicação da técnica de spotlighting na função repo_get_pull_request_by_id, garantindo que todo o conteúdo externo seja devidamente encapsulado antes de ser apresentado ao modelo, alinhando-a com as proteções já existentes em outras partes do servidor.
Enquanto aguardam correções oficiais da Microsoft, as equipes devem orientar os revisores para manterem seus agentes de IA desabilitados ao revisar código de fontes não confiáveis ouINAL, até que uma validação manual do conteúdo bruto do PR seja realizada. A instrução da Microsoft de 'revisar as alterações propostas' é tecnicamente ineficaz contra este vetor, pois o payload é projetado para ser invisível na interface de revisão padrão.
- Restringir tokens de agente ao escopo do projeto específico (least privilege)
- Utilizar flag
-dpara limitar domínios MCP carregados pelo servidor - Exigir confirmação humana (per-tool prompts) para ações de alto risco
- Implementar rotinas de varredura de PRs para detecção de HTML/Scripts ocultos
0 Comentários