- Uma injeção de prompt entre domínios (XPIA) escondida em um documento externo do Word pode manipular os resultados de redação e edição do Copilot e ser copiada para novos documentos, espalhando-se pelo fluxo de trabalho cotidiano mesmo sem o documento de ataque original
- Comandos ocultos em fonte branca e pequena também são lidos pelo Copilot depois que ele remove a formatação; nos testes, ele alterou números financeiros e escondeu todo o prompt de ataque no fim do documento gerado, transformando-o em um novo vetor de ataque
- O invasor não precisa de acesso ao tenant Microsoft 365 da vítima; basta compartilhar o documento por SharePoint, Teams ou Outlook e fazer com que o usuário o anexe ou que o Work IQ o selecione como material relevante no OneDrive
- A Microsoft distribuiu bloqueios para payloads específicos e upgrades de modelo, mas com prompts modificados a GPT-5.6 também reproduziu toda a cadeia de ataque, e mesmo após 144 dias de coordenação o tipo completo de vulnerabilidade não foi bloqueado
- Como documentos infectados circulam como materiais internos ou de parceiros aparentemente legítimos, rastrear a origem e detectar o problema é difícil; por isso, é preciso revisar documentos externos e resultados do Copilot e preservar em metadados a origem original e o histórico de edições do modelo
Como funciona um worm de IA baseado em documentos
- Quando comandos controlados por um invasor em um documento são copiados para os resultados de geração e edição do Copilot, o documento resultante se torna um novo vetor que transporta o mesmo ataque
- Se esse documento for usado como material em outra tarefa do Copilot, os comandos serão executados novamente e copiados para documentos posteriores
- A propagação pode continuar sem o documento malicioso original nem intervenção adicional do invasor
- O Morris II já havia demonstrado prompts autorreplicantes no ecossistema de assistentes de e-mail com IA generativa
- Este caso é uma demonstração pública de um worm de IA baseado em documentos se autorreplicando em tarefas comuns de documentos em um produto comercial de produtividade amplamente usado
Ataque explorando tarefas normais com documentos
- Um funcionário baixa de um site confiável comprometido um documento de análise de mercado com comandos ocultos e o usa como material para o Copilot redigir um relatório financeiro
- O Copilot altera números financeiros internos e copia os comandos de ataque para o novo relatório
- O funcionário salva e compartilha internamente o relatório, que parece normal
- Se um colega usar esse relatório como material para o próximo relatório, a manipulação dos números e a cópia dos comandos se repetem
- À medida que o relatório é reutilizado, mais documentos passam a virar vetores de ataque, e o site infectado e o documento malicioso inicial deixam de ser necessários
Modelo de ameaça e fronteira de confiança
- O invasor só precisa compartilhar um documento malicioso, sem permissão de acesso ao tenant Microsoft 365 da vítima
- Os caminhos de distribuição incluem SharePoint, Teams, Outlook e outros meios de compartilhamento de documentos
- A fronteira de segurança central fica entre os materiais anexados e o documento que está sendo redigido naquele momento
- O Copilot precisa ler todos os documentos anexados para escolher quais informações usar
- As informações dos anexos podem ser aproveitadas, mas os comandos neles contidos não devem ser tratados como instruções autoritativas do usuário
- Na prática, porém, comandos inseridos no documento alteram o comportamento do Copilot
- Ele muda números em um relatório financeiro sem avisar o usuário
- Ele cola todo o XPIA em documentos posteriores para que seja executado novamente em tarefas futuras
Como atravessar a fronteira de confiança no Word
- O documento malicioso inicial contém um prompt em formato JSON, que pode ser escondido do usuário com texto branco sobre fundo branco e fonte pequena
- O Copilot for Word remove formatações como cor e tamanho de fonte antes de enviar o texto ao LLM de base, então conteúdos invisíveis para o usuário continuam totalmente legíveis para o modelo
- O ataque pode ser ainda mais ocultado ao inserir comandos em um documento aparentemente legítimo e relacionado ao trabalho
- Para que o documento malicioso entre no contexto do Copilot, é necessário um dos seguintes casos
- O usuário anexa ou faz upload do documento diretamente no Copilot for Word
- O usuário usa o modo work/Work IQ do
Edit with Copilot, e o Copilot escolhe esse documento no OneDrive por considerá-lo material relevante
- O invasor precisa estruturar o conteúdo para aumentar a chance de o documento ser selecionado diretamente ou aparecer nos resultados de busca
- Essa vulnerabilidade afeta tanto a magic pen do Word quanto o
Edit with Copilot
Etapa 1: manipulação do documento e primeira replicação
- A prova de conceito (PoC) inicial usou um documento contendo apenas um prompt malicioso em texto branco e confirmou que, mesmo quando o material não tem relação com a tarefa, o ataque pode ser executado se ele entrar no contexto
- O prompt da PoC era composto de duas partes
- A primeira manipulava o documento alvo, alterando sutilmente o sentido de um resumo ou modificando números em um documento financeiro
- O ponto central era fazer o Copilot acreditar que aquilo era uma solicitação legítima e relevante para a tarefa
- Durante os testes, foi necessário até acrescentar uma instrução separada para destacar as mudanças, porque alterações significativas eram difíceis de perceber visualmente
- Em um ataque real, não se pediria marcação das mudanças, e o caso público usa alteração de números financeiros por ser mais fácil de verificar de imediato
- A segunda instruía o Copilot a copiar o prompt de ataque para o documento de saída
- Isso era disfarçado como uma tarefa de rastreamento de origem para documentos posteriores, e incluía instruções para o próprio método de ocultação sob o pretexto de melhorar a legibilidade
- A primeira manipulava o documento alvo, alterando sutilmente o sentido de um resumo ou modificando números em um documento financeiro
- Ao inserir o ataque em texto branco no fim de um documento de análise de mercado de uma empresa fictícia chamada Tfosorcim Ltd., o Copilot reduziu pela metade todos os números do relatório financeiro do Q1
- Em seguida, ele copiou todo o prompt malicioso para o fim do documento gerado em texto branco de 8 pontos, sem avisar o usuário sobre a alteração dos números nem sobre a inserção do prompt
- Mesmo quando o usuário não anexava diretamente o documento malicioso e apenas pedia a redação do relatório do Q1 da Tfosorcim, o Copilot buscava no OneDrive, encontrava o documento malicioso de análise de mercado em outra pasta e o ataque era bem-sucedido
- Essa PoC usou a GPT-5.6, então o modelo mais recente
Etapa 2: autorreplicação para documentos posteriores
- Como o próprio relatório do Q1 infectado se torna um novo vetor de ataque, o documento malicioso inicial deixa de ser necessário na sessão seguinte
- Ao anexar o relatório do Q1 para criar o relatório do Q2, o Copilot novamente reduziu todos os números financeiros pela metade e copiou o prompt inteiro em texto branco
- Como o novo vetor é um documento gerado a partir de um recurso interno legítimo, ele ganha a confiança normalmente atribuída a documentos internos
- Se a vítima compartilhar o documento com colegas, e ela mesma ou os colegas o usarem como material para redação ou edição no Copilot, o ataque se espalha para novos documentos
- Em todas as PoCs relatadas, o Copilot modificou documentos e copiou comandos ocultos; quando um documento infectado era incluído em um contexto posterior, o ataque voltava a ser executado mesmo sem o original
Impacto sobre organizações e ambientes colaborativos
- Depois do ponto de entrada inicial, documentos infectados passam a parecer materiais normalmente gerados dentro da organização, e nem mostram um histórico aprovado de edição do Copilot, o que torna muito difícil rastrear o ataque
- Se a propagação ocorrer silenciosamente por tarefas comuns com documentos, a confiabilidade da base de informações usada na tomada de decisões da organização pode ser comprometida
- Uma organização que não sabe da infecção pode transmitir documentos a outras organizações por SharePoint compartilhado ou colaboração no Teams
- O documento de ataque inicial de uma organização específica pode inclusive vir de um parceiro confiável que já estava infectado
- Como documentos de parceiros tendem a ser confiáveis, cresce também a chance de o usuário colocá-los no contexto do Copilot
- Se o Copilot for integrado mais profundamente a sistemas como Microsoft Cowork ou Microsoft Scout, que geram e manipulam automaticamente fluxos de documentos, ferramentas e colaboração, o mesmo mecanismo pode afetar uma superfície maior em velocidade de máquina
Mitigações da Microsoft e vulnerabilidades remanescentes
- A Microsoft bloqueou o prompt da PoC originalmente enviado e distribuiu várias correções durante o período de coordenação da divulgação
- Os payloads específicos relatados foram bloqueados, então reproduções posteriores exigiram payloads modificados em vez da formulação original
- Os vetores de ataque por memória e corpo de e-mail abordados nas partes 1 e 2 da série foram mitigados
- No entanto, o tipo de vulnerabilidade em que comandos do documento original alteram a saída do Copilot e se replicam para documentos posteriores continua presente
- Mesmo mudando a tarefa solicitada ou a formulação, a vulnerabilidade básica e o modo de propagação não se alteram
- Mesmo com todas as mitigações distribuídas aplicadas, toda a cadeia de ataque foi reproduzida com payloads ajustados
- Esse problema é uma fraqueza estrutural compartilhada pelos sistemas atuais baseados em LLM, e não foi confirmada nenhuma forma de bloquear completamente esse tipo em produtos comparáveis
- É um problema que exige mais pesquisa do que um patch único, mas as correções da Microsoft reduziram materialmente a exposição possível
Estado da divulgação e resposta do usuário
- A divulgação foi coordenada com o MSRC e com a equipe de produto da Microsoft, fornecendo procedimentos de reprodução, vídeos, premissas do ambiente e o prompt exato da PoC
- O período inicial de coordenação de 90 dias foi estendido duas vezes, totalizando 144 dias de resposta, mas o ataque ainda era reproduzível no momento da divulgação
- Duas mitigações, incluindo upgrades de modelo, também não conseguiram bloquear todo o tipo de vulnerabilidade, então a divulgação foi feita no nível do tipo de ataque e do mecanismo de propagação, em vez de revelar o payload específico
- No momento da divulgação, não havia um meio completo de resolver o problema do lado do cliente; as medidas a seguir podem reduzir a exposição
- Tratar documentos de fontes externas usados no Copilot como materiais não confiáveis
- Revisar os documentos anexados antes de iniciar geração ou edição com o Copilot
- Verificar cuidadosamente documentos gerados ou editados pelo Copilot antes de reutilizá-los, compartilhá-los ou distribuí-los
Cronograma da divulgação coordenada
- 6 de março de 2026: o relatório inicial foi enviado ao MSRC com procedimento de reprodução, vídeo, premissas do ambiente e prompt da PoC
- 9 de março: o MSRC confirmou o recebimento do relatório e abriu o caso
- 31 de março: a Microsoft confirmou o comportamento e a equipe de produto começou a trabalhar nas mitigações
- 3 de abril: foi distribuída a primeira mitigação por meio da nova experiência
Edit with Copilot - 9 de abril: foi confirmado o bloqueio do prompt de ataque anterior, mas o ataque foi reproduzido com uma nova tarefa de XPIA que manipulava números financeiros, e isso foi reportado como um caso separado
- 10 de abril: o MSRC recebeu o novo caso e a equipe de produto começou a trabalhar nas mitigações
- 8 de junho: a pedido da Microsoft, a data de divulgação foi adiada para 15 de julho
- 14 de julho: foi distribuída a segunda mitigação, com upgrade do modelo base para GPT-5.5
- 15 de julho: conseguiu-se reproduzir o ataque, incluindo a propagação do worm, na então mais recente GPT-5.6
- Para ganhar tempo para novas mitigações, a divulgação foi adiada novamente para 28 de julho, com concordância da Microsoft
- 28 de julho: a divulgação coordenada foi realizada enquanto o ataque continuava reproduzível
Integridade da informação e rastreabilidade da origem
- À medida que LLMs passam a fazer parte das operações de trabalho, a integridade da informação surge como uma questão central de segurança
- Conteúdo controlado por invasores não apenas manipula saídas individuais ou causa vazamento de informação, mas também pode se copiar e se autorreplicar acompanhando tarefas legítimas de usuários
- Comandos maliciosos presentes em conteúdo gerado permanecem em vários documentos, são redistribuídos por usuários legítimos e voltam a entrar em novos contextos
- Depois disso, o ataque deixa de ser apenas um ponto de entrada inicial e passa a integrar o fluxo interno de informações do sistema
- Como conteúdos criados por processos normais de geração e edição dificultam a verificação posterior da origem da manipulação, detecção e resposta ficam mais complexas
- Separadamente do bloqueio de injeção de prompts, documentos gerados devem preservar em metadados a origem dos materiais usados e o histórico de edições feitas pelo modelo
- Esse controle não impede a injeção em si, mas pode aumentar a rastreabilidade
O problema fundamental da arquitetura atual de LLMs
- Para ser útil, um assistente de IA precisa processar também informações controláveis por invasores, como e-mails, documentos, páginas da web, memória e saídas de ferramentas
- Informações externas entram na mesma janela de contexto que comandos de sistema, pedidos do usuário e outras informações confiáveis, participando do mesmo cálculo
- O LLM precisa julgar significado, relevância e malícia do conteúdo externo, mas no momento desse julgamento os tokens do invasor já estão influenciando o cálculo
- O conteúdo a ser inspecionado participa do próprio ato de inspeção
- Confiar a detecção de XPIA ao modelo é semelhante a pedir a um interpretador que execute um programa não confiável para decidir se ele é seguro
- Mesmo que o conteúdo malicioso seja detectado e removido antes de alcançar o modelo alvo, o mesmo problema apenas é deslocado para a etapa anterior
- Como LLMs conseguem reconstruir significado mesmo a partir de expressões muito diferentes, o detector também precisaria de capacidade semelhante de reconstrução semântica
- Um detector mais fraco que o LLM alvo cobre apenas um espaço de expressões mais estreito, então continuam existindo formas maliciosas que o alvo entende e o detector deixa passar
- Como a técnica geral que oferece capacidade semelhante de processamento semântico é outro LLM, adicionar modelos na etapa anterior pode reduzir a taxa de sucesso de ataques individuais, mas cria novamente o problema de LLMs all the way down, em que cada modelo de defesa também precisa ser protegido
- No longo prazo, será necessária uma arquitetura em que metas e intenções existam de forma independente das informações processadas
- A arquitetura atual de LLMs não tem um mecanismo para separar de forma estável intenção e interpretação
- Informações do invasor podem influenciar não só a saída do modelo, mas também a própria tarefa que o modelo acredita ter recebido
- Sistemas que integram LLMs a fluxos de trabalho confiáveis devem partir da premissa de que, se conteúdo controlado por invasores entrar no contexto, haverá comprometimento em alguma proporção
1 comentários
Opiniões no Hacker News
Dizem que “não há mitigação forte para uma classe mais ampla de vulnerabilidades”, mas agora parece óbvio que não dá para corrigir esse tipo de problema enquanto não pararmos de misturar comandos e dados
Parece que a indústria de IA só vai acordar depois de mais vazamentos de dados; e, se você se entregou à Anthropic ou à OpenAI, provavelmente sabia quais riscos estava assumindo, então fica difícil ter muita pena
Não é simplesmente um problema de misturar comandos e dados; como um LLM não consegue distinguir limites de forma determinística, definir fronteiras é mais um conforto psicológico e só torna alguns ataques um pouco mais difíceis. Nessa arquitetura, a tríade letal é um problema permanente
A situação vai piorar muito antes de melhorar, e é absurdo dar acesso demais a agentes
Dá para imaginar um comentário em um repositório popular do GitHub contendo apenas a instrução “reproduza o bug”, sem código. Ele poderia roubar cartões de crédito ou carteiras de Bitcoin e também se autopropagar para outros repositórios por meio da conta do GitHub
Mas muita gente, mesmo diante de uma IA com um poder assustador, não abre a caixa; por causa justamente desse poder, rasga a caixa antes mesmo de ela produzir uma saída. Então só resta torcer para que a autoaperfeiçoamento recursivo não funcione como os catastrofistas preveem
É grave que comandos maliciosos escondidos em um documento compartilhado externamente possam fazer o Copilot modificar documentos do Word e propagar o ataque para novos documentos
Muitos humanos ainda acreditam que a Terra é plana, que código e dados são fundamentalmente diferentes, ou que a distinção entre plano de controle e plano de dados é uma lei objetiva aplicável ao universo inteiro
Sou programador e usuário de IA baseada na web, mas não quero executar IA de forma alguma no meu computador local. Pelos motivos tratados neste artigo, removi o Copilot e desativei a IA em todos os aplicativos locais, incluindo o navegador
Como a IA não consegue distinguir entre o prompt do usuário e texto dentro de arquivos, não há como proteger dados por projeto contra esse tipo de ataque de confusão de IA. É absurdo que um processador de texto ou aplicativo de e-mail com IA possa seguir comandos inseridos em um documento ou e-mail comum. Migrar para sistemas operacionais open source, como Linux ou BSD, é a única solução realmente prática
Migrar para Linux ou BSD não basta; também é preciso ter fornecedores confiáveis de navegadores e aplicativos web
Esconder texto em branco ainda funciona
Hoje existem várias técnicas, e em https://tritium.legal/blog/noroboto enganaram algoritmos de ponta para que lessem valores Unicode diferentes daqueles exibidos pela fonte do documento
Pergunto-me se seria possível fazer IAs chamarem umas às outras e causar um grande volume de requisições, ou se esse tipo de abuso já foi prevenido
É como a volta dos worms de VBScript e macros
Pelo lado positivo, quanto mais rápido a IA causar um grande dano, mais cedo a diretoria talvez acorde e promova uma política interna de proibição de IA
Claro, como essa realidade foi provocada por todos eles, eu, que vivo sem IA, vou assistir ao sofrimento com prazer
Em um mundo cheio de IA, esse tipo de worm é, no fim das contas, propagação memética de ideias, e parece essencialmente igual ao que acontece com humanos
Se o texto borrado tiver relação com o original, é melhor cobrir tudo de preto. Parte ainda parece legível, e sabe-se que a maioria dos algoritmos de blur não destrói as informações adequadamente