Um único documento Word bastou para transformar o Microsoft 365 Copilot num ponto de entrada para a infraestrutura de nuvem que o suporta. A investigação, batizada ChatMate e apresentada na conferência Black Hat USA 2026, descreve uma cadeia de falhas que começa com instruções escondidas num ficheiro aparentemente inofensivo e termina com um atacante a conversar, em nome da vítima, com o assistente de IA da empresa. Os Rubrik Zero Labs classificam o resultado como remote prompt execution (execução remota de prompt) e apresentam o caso como a primeira instância documentada deste tipo de ataque, em que um documento malicioso conduz a uma fuga do sandbox.
Resposta rápida: Investigadores demonstraram que instruções escondidas num documento Word podiam escapar do ambiente isolado onde o Microsoft 365 Copilot executa código e dar a um atacante uma sessão interativa dentro do assistente da vítima, com acesso a e-mails, ficheiros e calendário. A Microsoft foi notificada e corrigiu as falhas específicas do lado do servidor, sem ação necessária dos clientes. A classe de ataque — injeção indireta de prompt — continua, porém, sem solução definitiva. A recomendação prática é tratar todos os documentos externos como conteúdo não confiável antes de os dar a ler a um assistente de IA.
O que os investigadores demonstraram
O ponto de partida é banal: alguém carrega um documento no Copilot e pede um resumo ou uma análise. Segundo a equipa, bastava conseguir que a vítima carregasse um único ficheiro Word malicioso para escapar silenciosamente ao sandbox de execução de código da IA, obtendo uma “prompt shell” interativa dentro da sessão do Copilot da vítima e a possibilidade de consultar e-mails, ficheiros, calendários e informação financeira em nome dela.
A parte mais desconfortável é o método. O assistente foi usado contra si próprio: a injeção de prompt levou o Copilot a executar código no seu próprio ambiente Python e a expor detalhes internos que abriram caminho à escalada de privilégios. A cadeia descrita passa por injeção de prompt no sandbox Python do Copilot, escalada de privilégios através de um ponto de entrada com permissões de escrita para root e, por fim, uma travessia de diretórios num serviço Azure não documentado, convertida numa shell interativa no assistente de IA de outra pessoa.
A apresentação, feita pelo investigador Ori Lahav, foi descrita como a primeira fuga documentada do sandbox do Copilot para o sistema anfitrião, com um simples carregamento de documento como vetor e sem necessidade de interação adicional do utilizador. O resultado é a execução remota de prompt, com raio de impacto que se estende a vários serviços Azure.
Cronologia da divulgação
| Data | Acontecimento |
|---|---|
| Fevereiro de 2026 | Descoberta da falha pelos Rubrik Zero Labs, seguida de divulgação responsável junto da Microsoft |
| Meados de março de 2026 | Microsoft corrige a vulnerabilidade |
| Junho de 2026 | Segundo o resumo divulgado da investigação, a falha do lado do Azure é corrigida na atualização de segurança de junho |
| 6 de agosto de 2026 | Sessão dos Rubrik Zero Labs na Black Hat USA, às 11h05 |
| 17 de agosto de 2026 | Detalhe adicional em entrevista, incluindo o percurso técnico até aos CVE identificados |
Identificadores e detalhes técnicos
Nem todos os detalhes técnicos estão consolidados em fontes coincidentes, pelo que convém prudência na leitura dos números. O resumo público da apresentação descreve uma cadeia de cinco fases que junta a injeção de prompt via documento Word a uma travessia de diretórios em infraestrutura Azure, identificada como CVE-2026-32193 com CVSS 8.8 e recompensada com 48 000 dólares, resultando numa shell bidirecional persistente que herda as permissões do utilizador em Microsoft 365 e Azure. A mesma descrição aponta o componente ACA-Session-Interpreter, ligado às sessões dinâmicas do Azure Container Apps, como alvo da travessia de diretórios. Em paralelo, o responsável dos Rubrik Zero Labs refere oito CVE críticos identificados ao longo do trabalho — número que não conseguimos confirmar em avisos individuais da Microsoft e que, por isso, deve ser lido como afirmação dos investigadores.
Há um aspeto que merece atenção de quem gere risco: a vulnerabilidade concreta está corrigida, mas a técnica subjacente — sair do sandbox do Copilot para chegar ao backend do Azure — pode aplicar-se a outros copilotos de IA. Segundo o responsável da equipa, o controlo obtido permitiria comando e controlo sobre um volume potencialmente muito elevado de ficheiros de utilizadores, SharePoint e OneDrive existentes no tenant.
Não é um caso isolado
O ChatMate junta-se a uma série de demonstrações sobre a mesma fragilidade estrutural. O EchoLeak (CVE-2025-32711, CVSS 9.3) foi uma injeção indireta de prompt sem cliques no Microsoft 365 Copilot, divulgada pela Aim Security em 2025, em que um único e-mail preparado levava o assistente a aceder a ficheiros internos e a exfiltrar conteúdos para um servidor do atacante; a Microsoft corrigiu do lado do servidor e não observou exploração. Já em 2026, a Microsoft atribuiu CVE-2026-21520, com CVSS 7.5, a uma injeção indireta de prompt no Copilot Studio, descoberta pela Capsule Security e corrigida a 15 de janeiro.
E há o caso do “verme” documental. Instruções escondidas num documento Word podem, quando incluídas no contexto do Copilot para Word, alterar o resultado produzido e copiar-se para novos ficheiros criados a partir desse documento, sem o utilizador dar por isso — problema divulgado publicamente pelo investigador norueguês Håkon Måløy. Uma das correções, a 14 de julho, passou por atualizar o modelo subjacente para o GPT‑5.5; no dia seguinte, o investigador voltou a contornar a proteção com o GPT‑5.6. Uma segunda falha, indexada como CVE-2026-55145, cobria três formas de manipular o Copilot no Outlook a partir de instruções escondidas em e-mails externos, incluindo alterar horas no resumo diário e forjar um resultado de chamada de ferramenta que fazia o assistente reportar um ciberataque inexistente.
O que as organizações podem fazer já
Como estas falhas são corrigidas no serviço gerido, não há “patch” para instalar. O trabalho das equipas internas está na redução da superfície de exposição:
- Tratar documentos e e-mails de origem externa como conteúdo não confiável antes de os submeter a assistentes de IA.
- Rever permissões em SharePoint e OneDrive: o assistente vê aquilo que o utilizador vê, pelo que acessos excessivos multiplicam o impacto de qualquer injeção.
- Ativar e monitorizar as proteções específicas. O Microsoft Defender para Office 365 Plano 2 deteta conteúdo de injeção de prompt em e-mail de entrada antes de chegar ao utilizador ou ao assistente, na mesma inspeção de fluxo de correio que protege contra phishing e malware, sem configuração adicional. As deteções ficam classificadas como phishing de elevada confiança, com um novo valor de tecnologia de deteção.
- Acompanhar o calendário da funcionalidade: segundo a mensagem MC1422060, de 9 de julho de 2026, a proteção está em pré-visualização pública e aponta para disponibilidade geral no início de setembro de 2026.
- Não esquecer as caixas de correio partilhadas. Como podem receber correio externo e o Copilot lhes acede por permissões delegadas, passam a fazer parte da superfície de ataque.
- Inventariar agentes de IA em uso. A investigação dos Rubrik Zero Labs indica que apenas 23% dos responsáveis de segurança têm visibilidade total sobre os agentes de IA já em funcionamento no seu ambiente.
Porque é que isto importa em Portugal
O Microsoft 365 é a espinha dorsal administrativa de uma boa parte das empresas e organismos públicos portugueses, e o Copilot está a ser ativado em muitas dessas subscrições sem uma avaliação de risco formal. Um ataque que herda as permissões do utilizador não deixa rasto de malware, não exige credenciais roubadas e dificilmente é detetado por controlos tradicionais de endpoint — o que o torna particularmente incómodo para PME sem equipa de segurança dedicada.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de risco da cadeia de fornecimento e a segurança na aquisição e utilização de sistemas de TIC incluem, inevitavelmente, os assistentes de IA integrados nas ferramentas de produtividade. Isso implica documentar que dados o assistente pode alcançar, com que permissões e com que registos de auditoria — e ter um caminho claro de notificação ao CNCS/CERT.PT caso um incidente relevante ocorra. Se houver acesso indevido a correio eletrónico ou a ficheiros com dados pessoais, aplicam-se ainda as obrigações do RGPD, incluindo a avaliação de notificação à CNPD e, quando o risco for elevado, aos titulares dos dados.
A conclusão prática é menos dramática do que os títulos sugerem, mas mais exigente: a injeção de prompt não se resolve com um botão. A própria Microsoft assume que proteger fluxos de trabalho de IA exige defesas em mais do que uma camada, combinando filtragem de entrada, separação entre conteúdo do utilizador e instruções de sistema, limites de acesso e filtragem de saída. Enquanto o modelo tiver de ler conteúdo não confiável para decidir se é seguro, o perímetro de confiança tem de ser desenhado à volta dele — nos dados, nas permissões e na monitorização.
Perguntas frequentes
O que é a execução remota de prompt?
É a designação dada pelos investigadores a um ataque em que instruções escondidas em conteúdo processado por um assistente de IA lhe permitem, além de manipular respostas, obter uma sessão interativa dentro do assistente da vítima. Na prática, o atacante passa a poder instruir o assistente a executar ações em nome do utilizador comprometido.
A falha já está corrigida?
Sim: a descoberta ocorreu em fevereiro de 2026, houve divulgação responsável junto da Microsoft e a correção foi aplicada até meados de março, embora a técnica subjacente possa ser aplicável a outros assistentes de IA. Não é necessária qualquer atualização por parte dos clientes, porque a correção é feita no serviço.
Como reduzir o risco de injeção indireta de prompt?
Limitando o que o assistente alcança e o que ingere. Rever permissões em SharePoint, OneDrive e caixas partilhadas, tratar ficheiros externos como não confiáveis e ativar deteções específicas de injeção de prompt no correio eletrónico são as medidas com melhor relação esforço/benefício. A defesa passa por limitar o âmbito dos dados antes de o assistente lhes chegar, e não apenas por corrigir vulnerabilidades individuais.
Um ataque destes é um incidente de dados pessoais?
Depende do que for acedido. Se houver acesso não autorizado a e-mails, ficheiros ou registos com dados pessoais, a organização tem de avaliar a existência de uma violação de dados nos termos do RGPD e, se aplicável, notificar a autoridade de controlo. As entidades abrangidas pelo regime de cibersegurança devem ainda avaliar o dever de notificação de incidentes ao CNCS.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelos Rubrik Zero Labs, pela Microsoft e por investigadores independentes de segurança.