En janvier 2026, OPSWAT a publié une analyse de la faille CVE-2025-66516, une vulnérabilité critique d’Apache Tika déclenchée par un fichier PDF malveillant parvenant jusqu’à un analyseur syntaxique en arrière-plan. La solution était simple : nettoyer le fichier avant qu’il n’atteigne l’analyseur syntaxique, de sorte que celui-ci ne voie jamais la charge utile. Cela a fonctionné car il n’y avait qu’un seul analyseur syntaxique, un seul type de fichier et une seule bibliothèque connue.
Mais que se passe-t-il si le fichier XML n'est pas un PDF, mais un fichier de configuration importé dans une plateforme SSO (Single Sign-On), une définition de workflow envoyée à un moteur d'automatisation financière, ou une charge utile de données de santé traitée par un système d'intégration hospitalier ? Ces fichiers circulent quotidiennement entre les organisations, les sous-traitants, les autorités de régulation et les partenaires, et parviennent via des systèmes de transfert de fichiers gérés et des portails partenaires en tant que données métier fiables. La plupart des solutions de nettoyage de données ne les inspectent jamais.
Le XML est le langage de l'industrie, et c'est là que réside le problème
Les attaques XXE (XML External Entity) de type PDF et SVG suivent toutes le même schéma : un utilisateur télécharge un fichier ; une bibliothèque côté serveur l'analyse ; l'analyseur exécute la charge utile. Le point d'entrée est visible.
Les fichiers XML sectoriels sont différents. Il s'agit de transferts interentreprises, d'importations de configurations et de données échangées de système à système provenant de partenaires, d'autorités de régulation, de sous-traitants et de fournisseurs connus. C'est précisément cette légitimité apparente qui leur permet de contourner les contrôles appliqués aux téléchargements sur le Web.
Le langage XML fait partie intégrante du fonctionnement de nombreux secteurs d'activité :
- Services financiers : les messages SWIFT, les instructions FIX (Financial Information eXchange) et les paiements ISO 20022 sont tous au format XML.
- Santé : HL7 (Health Level Seven) et FHIR (Fast Healthcare Interoperability Resources), les protocoles standard d'échange de données de santé, sont basés sur le langage XML. Une entité malveillante présente dans une charge utile FHIR parvient à passer à travers tout système qui vérifie la structure mais pas le DOCTYPE.
- Informatique d'entreprise : les plateformes d'identité et d'authentification unique (SSO) importent des fichiers de configuration XML lors de l'intégration, de la migration et de la mise en service. Une seule importation peut concerner toutes les applications authentifiées par la plateforme.
- OT : Les systèmes SCADA et de gestion de l'énergie échangent des données dans des formats XML définis par les normes CEI 61968 et 61970, souvent au-delà des frontières entre les réseaux IT et OT, où les contrôles sont minimes.
Dans tous les cas, la charge utile n'est ni un script ni une macro, mais se trouve dans la couche de contenu du XML : il s'agit d'une déclaration DOCTYPE faisant référence à une entité externe qui pointe vers un chemin d'accès local ou un point de terminaison interne. Lorsque l'analyseur traite le fichier, il récupère ce contenu.
Bien que le fichier soit structurellement valide selon la vérification du schéma, son contenu nécessite un niveau de validation plus approfondi, par exemple en ce qui concerne la déclaration DOCTYPE ou la destination des entités.
Ce n'est pas un problème lié à l'héritage
La vulnérabilité XXE a été décrite en 2003 et ajoutée au Top 10 de l'OWASP en 2017, ce qui conduit parfois les équipes à la considérer comme résolue. Les données de 2025 et 2026 indiquent toutefois le contraire, et les cas qui comptent pour la sécurité des fichiers sont ceux où la charge utile arrive sous forme de fichier.
- lxml (CVE-2026-41066) : la configuration par défaut de l'analyseur syntaxique d'une bibliothèque Python XML très répandue permettait à du code XML non fiable d'accéder à des fichiers locaux. lxml est la bibliothèque utilisée par svglib pour analyser les fichiers SVG (Scalable Vector Graphics) ; l'OPSWAT e de chemin d'accès via un fichier a été démontrée dans son article de blog de 2024 intitulé « SVG XXE ». La validation du fichier permet de supprimer l'entité avant que l'analyseur syntaxique ne la détecte.
- Atlassian Crowd (CVE-2026-21569, CVSS 7,9 – Risque élevé) : plateforme d’authentification unique (SSO) et de gestion des identités. Une charge utile XML spécialement conçue permet à un attaquant d’accéder à des fichiers en local ou à distance ; la note « Scope:Changed » attribuée par le CVSS signifie qu’une exploitation réussie affecte toutes les applications authentifiées par Crowd. Le fichier XML est transmis sous la forme d’un fichier de configuration ou d’importation d’intégration provenant d’un partenaire ou d’un poste de travail administrateur.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 Élevé) : IBM BAW traite des fichiers XML dans le cadre de workflows tels que la souscription de prêts et le traitement des demandes d'indemnisation. Cette faille permet la divulgation de fichiers et une attaque SSRF (Server-Side Request Forgery), permettant ainsi à un attaquant d'accéder à des terminaux internes ; de plus, la même structure DOCTYPE peut entraîner une expansion d'entité et provoquer une attaque par déni de service (DoS). Les fichiers XML proviennent, via des portails partenaires, d’experts en sinistres, d’autorités de régulation et d’intégrateurs.
Tout converge vers un même schéma : un fichier XML professionnel fiable contenant une charge utile de type DOCTYPE, qui suit un flux de travail bien établi avant d'atteindre un analyseur syntaxique vulnérable.
Remarque concernant le champ d’application : cet article traite des attaques XXE provenant d’un fichier. Les fichiers XML et les formats basés sur XML, tels que SVG, les PDF avec XFA et les fichiers Office, qui passent par un processus de nettoyage, sont reconstitués sans risque. Les cas liés à des fichiers sont les plus courants : téléchargements, importations de configurations, échanges de données avec des partenaires et pièces jointes aux e-mails. Une attaque XXE exploitée via le corps brut d’une requête API ou un appel de parsing intégré au code n’implique aucun fichier en transit ; par conséquent, aucune passerelle de nettoyage de fichiers ne se trouve sur ce chemin.
Comment la technologie Deep CDR™ gère les fichiers XML autonomes
La technologie Deep CDR™ prend en charge les normes XML 1.0 et 1.1, ainsi que les formats associés basés sur XML, notamment ZEI, JNLP, TDS, RDF, BML, MPD et TTML, le tout au sein d'un même moteur.
Pour les fichiers XML, les références pointant vers l'extérieur du document sont refusées par défaut, et le DOCTYPE ainsi que ses références à des entités externes ne sont pas conservés dans le fichier reconstruit. Aucun de ces deux comportements ne relève d'une politique qu'il faudrait identifier et ajuster. Tant que le contenu XML externe passe par le workflow de nettoyage d'MetaDefender Core™, la protection s'applique.
Outre cette suppression par défaut des balises DOCTYPE, les opérateurs disposent de paramètres supplémentaires qu'ils peuvent configurer en fonction de leur environnement.
- Supprimer les macros : supprime les macros VBA intégrées dans les formats Office basés sur XML
- Supprimer les sections CDATA : quatre options de politique graduelles, allant de « Ne rien faire » à « Tout supprimer », permettant aux équipes de contrôler le niveau d'intervention appliqué aux sections CDATA en fonction du degré de sensibilité du flux de travail
- Suppression des injections : traite les injections XML et le code JavaScript de la couche de contenu intégré dans les valeurs des éléments
- Traitement des données encodées en Base64 : gère les charges utiles encodées intégrées dans des valeurs XML, y compris les modèles de schéma d'URL de données
Une protection connexe couvre l'autre aspect de ce même phénomène. Les structures conçues pour s'étendre jusqu'à épuiser la mémoire sont détectées et supprimées ; ainsi, un petit fichier ne peut pas devenir un fichier gigantesque au cours de son traitement, d'où le nom de « XML Bomb » (ou « Billion Laughs ») donné à ce phénomène.
Chaque opération de nettoyage est consignée dans un rapport JSON d'analyse forensic. Ce rapport comprend le nom de l'objet, le contenu supprimé (limité à 5 000 caractères par entrée) et le hachage SHA-256 de l'objet supprimé. Les équipes de sécurité disposent ainsi d'une piste d'audit complète pour les contrôles de conformité et la reconstitution des incidents, sans avoir à réexaminer le fichier d'origine.
Pour une explication détaillée de l'injection XML, de l'injection CDATA, des « bombes XML » et des mécanismes d'attaque XML associés, consultez notre analyse technique approfondie des vecteurs d'attaque des documents XML.
Protégez vos flux de travail liés aux fichiers XML
Lorsqu'un analyseur fiable est confronté à un fichier XML malveillant, c'est le fichier qui l'emporte. Apache Tika, Atlassian Crowd, IBM BAW et le chemin d'analyse SVG en sont la preuve, que ce soit dans les pipelines de documents, les plateformes d'identité ou les moteurs de workflow.
Ces fichiers ne sont pas considérés comme des menaces. Ils proviennent de partenaires connus, via des processus de travail bien établis, et contiennent du contenu légitime, ce qui explique leur efficacité. La solution reste la même d’une vulnérabilité CVE à l’autre : intercepter les fichiers au niveau de la couche de transfert, les nettoyer avant qu’ils n’atteignent l’analyseur syntaxique, et s’assurer que la protection couvre les fichiers XML externes, et pas seulement les pièces jointes aux e-mails et les fichiers téléchargés sur le Web.
