Em janeiro de 2026, a OPSWAT publicou uma análise do CVE-2025-66516, uma vulnerabilidade crítica no Apache Tika desencadeada por um ficheiro PDF malicioso que chegava a um analisador de back-end. A correção foi simples: sanitizar o ficheiro antes de este chegar ao analisador, de modo a que este nunca visse a carga maliciosa. Isso funcionou porque havia um único analisador, um único tipo de ficheiro e uma única biblioteca conhecida.
E se o XML não for um PDF, mas sim um ficheiro de configuração importado para uma plataforma de SSO (Single Sign-On), uma definição de fluxo de trabalho enviada para um motor de automatização financeira ou um conjunto de dados de saúde processado por um sistema de integração hospitalar? Estes ficheiros circulam diariamente entre organizações, contratantes, entidades reguladoras e parceiros, chegando através de transferências de ficheiros geridas e portais de parceiros como dados empresariais fiáveis. A maioria das soluções de sanitização nunca os inspeciona.
O XML é a linguagem da indústria, e é aí que reside o problema
Os ataques XXE (XML External Entity) em PDF e SVG seguem um padrão semelhante: um utilizador carrega um ficheiro; uma biblioteca de backend analisa-o; o analisador executa a carga útil. O ponto de entrada é visível.
O XML do setor é diferente. Trata-se de transferências entre empresas, importações de configurações e cargas úteis entre sistemas provenientes de parceiros, entidades reguladoras, contratantes e fornecedores conhecidos. É precisamente essa aparente legitimidade que faz com que escapem ao escrutínio aplicado aos uploads na Web.
O XML está presente no funcionamento de vários setores:
- Serviços financeiros: as mensagens SWIFT, as instruções FIX (Financial Information eXchange) e os pagamentos ISO 20022 são todos em formato XML.
- Cuidados de saúde: O HL7 (Health Level Seven) e o FHIR (Fast Healthcare Interoperability Resources), os protocolos padrão para a troca de dados de saúde, baseiam-se em XML. Uma entidade maliciosa presente numa carga útil FHIR consegue passar por qualquer sistema que verifique a estrutura, mas não o DOCTYPE.
- TI empresarial: As plataformas de identidade e SSO importam ficheiros de configuração XML durante a integração, a migração e a implementação. Uma única importação pode abranger todas as aplicações que a plataforma autentica.
- OT: Os sistemas SCADA e de gestão de energia trocam dados em formatos XML definidos pelas normas IEC 61968 e 61970, muitas vezes atravessando as fronteiras entre as áreas de TI e OT, onde os controlos são mínimos.
Em todos os casos, a carga útil não é um script nem uma macro, mas existe na camada de conteúdo do XML: uma declaração DOCTYPE que faz referência a uma entidade externa que aponta para um caminho de ficheiro local ou para um ponto de extremidade interno. Quando o analisador processa o ficheiro, obtém esse conteúdo.
Embora o ficheiro seja estruturalmente válido segundo a verificação do esquema, o seu conteúdo requer um nível mais aprofundado de limpeza, por exemplo, o que o DOCTYPE declara ou para onde a entidade aponta.
Isto não é um problema de sistemas antigos
A vulnerabilidade XXE foi descrita em 2003 e incluída no Top 10 da OWASP em 2017, o que, por vezes, leva as equipas a considerá-la resolvida. Os registos de 2025 e 2026 indicam o contrário, e os casos que importam para a segurança dos ficheiros são aqueles em que a carga útil chega sob a forma de ficheiro.
- lxml (CVE-2026-41066): a configuração predefinida do analisador numa biblioteca XML de Python amplamente utilizada permitia que XML não fiável lesse ficheiros locais. A lxml é a mesma biblioteca que a svglib utiliza para analisar ficheiros SVG (Scalable Vector Graphics), sendo que o caminho transmitido pelo ficheiro OPSWAT foi demonstrado no seu blogue de 2024 sobre SVG XXE. A sanitização do ficheiro remove a entidade antes de o analisador a detetar.
- Atlassian Crowd (CVE-2026-21569, CVSS 7,9 – Alto): uma plataforma de SSO e gestão de identidades. Uma carga XML manipulada permite a um atacante aceder a ficheiros localmente ou remotamente, e a classificação CVSS «Scope:Changed» significa que uma exploração bem-sucedida atinge todas as aplicações que o Crowd autentica. O XML chega sob a forma de uma importação de configuração ou integração proveniente de um parceiro ou de um terminal de administrador.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 Alto): O IBM BAW processa XML em fluxos de trabalho como a concessão de empréstimos e o processamento de reclamações. A falha permite a divulgação de ficheiros e SSRF (Server-Side Request Forgery), permitindo que um atacante aceda a terminais internos, e a mesma estrutura DOCTYPE pode provocar a expansão de entidades para DoS (Denial of Service). O XML chega através de portais de parceiros provenientes de peritos de sinistros, entidades reguladoras e integradores.
Tudo aponta para um padrão comum: um ficheiro XML empresarial fiável que contém uma carga útil DOCTYPE, que passa por um fluxo de trabalho estabelecido antes de chegar a um analisador vulnerável.
Uma nota sobre o âmbito: este blogue aborda o XXE que chega na forma de ficheiro. Os ficheiros XML e os formatos baseados em XML, como SVG, PDF com XFA e ficheiros do Office, que passam por um fluxo de trabalho de sanitização, são reconstruídos sem problemas. Os casos transmitidos por ficheiros são os mais comuns: uploads, importações de configurações, troca de dados com parceiros e anexos de e-mail. O XXE acedido através do corpo bruto de um pedido API ou de uma chamada de análise no código não envolve a transferência de ficheiros, pelo que não existe um gateway de sanitização de ficheiros nesse percurso.
Como a tecnologia Deep CDR™ lida com ficheiros XML autónomos
A tecnologia Deep CDR™ suporta XML 1.0 e 1.1, bem como formatos relacionados baseados em XML, incluindo ZEI, JNLP, TDS, RDF, BML, MPD e TTML, no mesmo motor.
No caso dos ficheiros XML, as referências que apontam para fora do documento são rejeitadas por predefinição, e o DOCTYPE e as suas referências a entidades externas não são mantidos no ficheiro reconstruído. Nenhum destes comportamentos constitui uma política que tenha de ser identificada e ajustada. Desde que o XML externo seja encaminhado através do fluxo de trabalho de sanitização no MetaDefender Core™, a proteção aplica-se.
Para além desta remoção automática do DOCTYPE, os operadores dispõem de controlos adicionais que podem configurar de acordo com o seu ambiente
- Remover Macro: elimina as macros VBA codificadas em formatos do Office baseados em XML
- Remover CDATA: quatro opções de política graduais, desde «Não fazer nada» até «Remover tudo», que permitem às equipas controlar o grau de rigor com que as secções CDATA são tratadas, dependendo da sensibilidade do fluxo de trabalho
- Remover injeção: trata da injeção de XML e do JavaScript da camada de conteúdo incorporado nos valores dos elementos
- Processar dados codificados em Base64: lida com cargas úteis codificadas incorporadas em valores XML, incluindo padrões do esquema de URL de dados
Uma proteção relacionada abrange o outro lado da mesma direção. As estruturas programadas para se expandirem até esgotarem a memória são detetadas e removidas, pelo que um ficheiro pequeno não pode tornar-se num ficheiro enorme ao longo do processo — razão pela qual se utiliza a designação «XML Bomb» (ou «Billion Laughs») para se referir a este fenómeno.
Cada ação de sanitização é registada num relatório forense em formato JSON. O relatório inclui o nome do objeto, o conteúdo removido (com um limite máximo de 5 000 caracteres por entrada) e o hash SHA-256 do objeto removido. As equipas de segurança dispõem de uma pista de auditoria completa para a análise de conformidade e a reconstrução de incidentes, sem necessidade de reexaminar o ficheiro original.
Para uma explicação completa sobre a injeção de XML, a injeção de CDATA, as «bombas» de XML e os mecanismos de ataque relacionados com o XML, consulte a nossa análise técnica aprofundada sobre os vetores de ataque a documentos XML.
Proteja os seus fluxos de trabalho com ficheiros XML
Quando um analisador de confiança se depara com um ficheiro XML malicioso, é o ficheiro que leva a melhor. O Apache Tika, o Atlassian Crowd, o IBM BAW e o percurso de análise SVG comprovam esta realidade em pipelines de documentos, plataformas de identidade e motores de fluxo de trabalho.
Estes ficheiros não são considerados ameaças. Provêm de parceiros conhecidos, através de fluxos de trabalho estabelecidos, e contêm conteúdo legítimo, o que os torna eficazes. A solução não varia de um CVE para outro: interceptar na camada de transferência, filtrar antes de o ficheiro chegar ao analisador e garantir que a proteção abrange ficheiros de dados XML externos, e não apenas anexos de e-mail e uploads na Web.
