Guide de la vulnérabilité XXE 2025 : Comment les attaques XML persistent

Introduction : La menace “ancienne” qui refuse de disparaître

Dans le paysage en constante évolution de la cybersécurité, où de nouvelles vulnérabilités apparaissent chaque jour, l’injection d’Entity Externe XML (XXE) reste un rappel brutal que les menaces héritées peuvent être tout aussi dangereuses que les exploits de pointe. Bien documentées depuis plus d’une décennie, les vulnérabilités XXE continuent de hanter les applications modernes en 2025, avec des découvertes récentes de haut profil prouvant que même les grandes entreprises technologiques ne sont pas à l’abri.

Au début de 2025, des chercheurs en sécurité ont découvert une vulnérabilité critique XXE dans Akamai CloudTest permettant aux attaquants d’accéder aux fichiers du serveur et d’exfiltrer des données sensibles comme le fichier /etc/passwd. De même, CVE-2025-23195 a révélé une vulnérabilité XXE dans le projet Ambari/Oozie pouvant être exploitée pour lire des fichiers arbitraires ou effectuer des attaques de falsification de requêtes côté serveur. Ces incidents récents soulignent une réalité préoccupante : les organisations continuent de déployer des parseurs XML avec des configurations par défaut peu sécurisées, laissant leurs applications vulnérables à des attaques évitables depuis des années.

Comprendre XXE : Une plongée technique

Qu’est-ce que l’injection XXE ?

L’injection d’Entity Externe XML est une vulnérabilité de sécurité web qui permet aux attaquants d’interférer avec le traitement XML d’une application en exploitant la gestion des entités externes par les parseurs XML. Les entités externes sont des entités XML personnalisées dont les valeurs sont chargées depuis l’extérieur de la Définition de Type de Document (DTD), leur permettant de faire référence à des chemins de fichiers locaux ou à des URL.

Le problème fondamental provient de la spécification XML elle-même. Le processeur XML remplace les occurrences d’entités externes par le contenu récupéré via l’identifiant système, qui peut être un chemin de fichier ou une URL. Lorsqu’une application ne configure pas correctement son parseur XML, les attaquants peuvent manipuler ce mécanisme pour accéder à des ressources qui devraient rester protégées.

L’anatomie d’une attaque XXE

Un payload XXE simple illustre la simplicité mais aussi l’efficacité de cette attaque :

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

Lorsque le parseur XML traite ce payload sans contrôles de sécurité appropriés, il résout l’entité externe et injecte directement le contenu du fichier système dans la sortie XML, exposant potentiellement des données au niveau du système d’exploitation sans nécessiter de crédentials.

Les trois piliers de l’exploitation XXE

1. Attaques de divulgation de fichiers : La mine d’or d’informations

Les attaques de divulgation de fichiers permettent aux adversaires d’accéder à des fichiers locaux du système via des entités XML malveillantes, révélant des informations sensibles telles que des fichiers de configuration, des fichiers de mot de passe ou du code source d’application. Cette capacité transforme ce qui pourrait sembler une vulnérabilité de parsing en un vecteur complet de compromission du système.

Les attaquants ciblent généralement des fichiers de grande valeur tels que : - /etc/passwd et /etc/shadow sur Unix - Clés de registre Windows - Fichiers de configuration d’application contenant des identifiants de base de données - Points de terminaison de métadonnées cloud (AWS, Azure, GCP) - Clés SSH privées et certificats SSL

Le danger dépasse la simple lecture de fichiers. Les attaquants peuvent effectuer une exfiltration de données hors bande en lisant des fichiers locaux et en transmettant leur contenu à des serveurs distants qu’ils contrôlent.

2. Falsification de requêtes côté serveur (SSRF) : Briser les frontières internes

Les vulnérabilités XXE peuvent être exploitées pour réaliser des attaques SSRF, où l’application côté serveur est induite à faire des requêtes HTTP vers n’importe quelle URL accessible par le serveur. Cette capacité est particulièrement dangereuse dans les environnements cloud et réseaux internes.

Grâce à l’exploitation SSRF via XXE, les attaquants peuvent : - Explorer l’infrastructure réseau interne et cartographier les systèmes internes - Accéder aux services de métadonnées cloud pour voler des identifiants - Contourner les règles de pare-feu et accéder à des API internes restreintes - Pivot vers des systèmes exposés à l’extérieur vers des ressources internes

La récente vulnérabilité CVE-2025-30220 de GeoServer a montré comment XXE pouvait être exploité pour tromper l’application afin de faire des requêtes HTTP vers des systèmes internes ou arbitraires, soulignant la pertinence continue de ce vecteur d’attaque.

3. Déni de service : L’attaque “Billion Laughs”

L’attaque “Billion Laughs” exploite des déclarations récursives d’entités pour augmenter exponentiellement la taille des entités lors du parsing, consommant une quantité massive de mémoire et risquant de faire planter les systèmes. Cette attaque est particulièrement dangereuse car le payload lui-même est relativement petit, mais l’expansion lors du parsing peut saturer complètement les ressources du serveur.

Un payload typique “Billion Laughs” crée des définitions d’entités imbriquées qui s’expansent de façon exponentielle :

<!DOCTYPE root [
  <!ENTITY e "e">
  <!ENTITY e1 "&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;">
  <!ENTITY e2 "&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;">
  <!ENTITY e3 "&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;">
]>
<root>&e3;</root>

Lorsqu’il est analysé, ce petit payload peut se développer pour consommer des gigaoctets de mémoire, mettant à genoux les systèmes en production.

Pourquoi les API SOAP restent la cible principale du XXE

La dépendance SOAP-XML

Les API SOAP reposent presque universellement sur l’analyse XML, ce qui les rend intrinsèquement vulnérables aux attaques XXE et à l’injection XPath. Contrairement aux API REST modernes qui utilisent principalement JSON, la stricte conformité de SOAP à XML crée une surface d’attaque élargie que de nombreuses organisations ne sécurisent pas correctement.

SOAP continue de soutenir des opérations critiques dans les secteurs de la finance, de la santé et du gouvernement en raison de sa fiabilité, de sa traçabilité et de son intégrité transactionnelle. Cette utilisation répandue dans des systèmes de grande valeur en fait des cibles privilégiées pour des attaquants sophistiqués.

Étude de cas Akamai CloudTest

La récente découverte de CVE-2025-49493 dans Akamai CloudTest a révélé que plusieurs points de terminaison SOAP sous /concerto/services étaient vulnérables aux attaques XXE. Les chercheurs en sécurité ont constaté que la plupart des points de terminaison dans ce chemin partageaient la même vulnérabilité, démontrant comment une seule mauvaise configuration peut exposer toute une infrastructure de services.

Le cas d’Akamai est instructif car il met en évidence plusieurs points clés : - Exposition systématique : Lorsqu’un point de terminaison SOAP est vulnérable, souvent plusieurs autres le sont aussi - Découverte tardive : Malgré la position de leader technologique, la vulnérabilité a persisté jusqu’en 2025 - Impact réel : Les attaquants pouvaient accéder à des fichiers sensibles du serveur et à des variables d’environnement

La vulnérabilité a finalement été corrigée en désactivant complètement le traitement DTD au niveau du parseur, empêchant ainsi les attaques XXE à leur source.

Systèmes hérités et dette technique

De nombreux API SOAP restent figés, fonctionnant sur des bibliothèques et frameworks obsolètes datant de plus d’une décennie. Des recherches récentes ont montré que des vulnérabilités XSW dans le système de Dossier de Santé Personnel en Allemagne pouvaient être exploitées pour contourner l’authentification, illustrant les conséquences concrètes de ces menaces.

Le problème est aggravé par le fait que les services SOAP opèrent souvent profondément dans l’infrastructure organisationnelle : - Systèmes bancaires centraux traitant des millions de transactions - Systèmes de santé gérant des dossiers patients - Intégrations de la chaîne d’approvisionnement connectant plusieurs entreprises - Systèmes gouvernementaux anciens difficiles à remplacer

Fonctionnalités de téléchargement de fichiers : La voie d’attaque négligée

Fichiers SVG comme vecteurs XXE

Certains formats de fichiers courants utilisent XML ou contiennent des sous-composants XML, le SVG étant un exemple principal. Une application pourrait permettre aux utilisateurs de télécharger des images et de les traiter sur le serveur, mais si la bibliothèque de traitement d’images supporte le format SVG, les attaquants peuvent soumettre des images SVG malveillantes pour atteindre des surfaces d’attaque XXE cachées.

Un fichier SVG malveillant peut contenir des payloads XXE déguisés en balises d’image légitimes :

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE test [ 
  <!ENTITY xxe SYSTEM "file:///etc/hostname"> 
]>
<svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg">
  <text font-size="16" x="0" y="16">&xxe;</text>
</svg>

Lors du traitement de ce SVG, le contenu de fichiers sensibles peut être affiché directement dans l’image rendue, rendant la détection plus difficile.

XXE de second ordre : La menace différée

Les injections XXE de second ordre représentent une variante plus sophistiquée où les payloads malveillants sont d’abord stockés puis récupérés et exécutés ultérieurement. Ces vulnérabilités sont particulièrement courantes dans les fonctionnalités d’import/export qui s’exécutent de manière asynchrone, où des fichiers XML fournis par l’utilisateur sont mis en file d’attente pour traitement en arrière-plan.

Ce modèle d’exécution différée crée plusieurs défis : - Les tests de sécurité traditionnels peuvent ne pas déclencher la vulnérabilité - Le point d’injection et le contexte d’exécution sont séparés - Les payloads peuvent persister dans des bases de données ou des systèmes de fichiers - L’attribution devient plus difficile

Au-delà de SVG : autres formats de fichiers basés sur XML

Les visualiseurs et convertisseurs de documents traitant des documents XML comme les fichiers DOCX et XLSX sont des cibles courantes pour l’exploitation XXE. Les formats modernes de documents Office sont essentiellement des archives ZIP contenant des fichiers XML. Lorsqu’une application extrait et analyse ces composants XML sans validation appropriée, elle devient vulnérable aux attaques XXE.

Même les fichiers audio peuvent être exploités, comme le montre CVE-2021-29447 dans WordPress, où des fichiers MP3 utilisant la bibliothèque ID3 pour l’analyse des métadonnées étaient vulnérables aux attaques XXE.

Pourquoi XXE persiste en 2025 : causes profondes

Configurations par défaut peu sécurisées des parseurs

La plupart des parseurs XML traitent par défaut les entités externes, ce qui entraîne l’exécution par les serveurs du code système intégré dans des éléments XML malveillants, sauf configuration explicite pour l’éviter. Ce choix de conception “insecure by default” crée une situation où les développeurs doivent renforcer activement leurs parseurs plutôt que de bénéficier de paramètres sécurisés par défaut.

Traitement XML invisible

Certains API REST sont involontairement configurés pour accepter des données dans plusieurs formats, y compris XML, même si les développeurs pensent qu’ils ne traitent que du JSON. Les applications peuvent accepter Content-Type: application/xml ou convertir automatiquement entre formats, créant des surfaces d’attaque XXE cachées dont les développeurs ignorent l’existence.

Architectures d’applications complexes

Les applications web peuvent contenir de nombreux composants, chacun pouvant inclure un parseur XML, rendant difficile de déterminer quelles parties traitent XML. Dans certains cas, les propriétaires d’applications n’ont pas accès à la configuration des parseurs XML utilisés par des composants tiers.

Les applications modernes intègrent souvent : - Plusieurs microservices avec leurs propres parseurs XML - Bibliothèques et frameworks tiers - Composants hérités avec un traitement XML non documenté - Services cloud pouvant accepter des entrées XML

Fausses impressions de sécurité

La verbosité structurée du XML crée une illusion de sécurité, mais la complexité du parsing XML introduit en réalité sa propre surface d’attaque. Il est dangereux de penser que les services SOAP internes fonctionnent en toute sécurité simplement parce qu’ils résident derrière un pare-feu.

Les organisations font souvent des hypothèses erronées : - “Nous utilisons uniquement JSON, donc nous sommes à l’abri du XXE” - “Nos points de terminaison XML sont internes uniquement” - “Nous avons désactivé les entités externes il y a des années” (sans vérifier tous les parseurs) - “Notre WAF protège contre les attaques XXE”

Techniques avancées XXE : contourner les défenses

Exploitation XXE aveugle

De nombreuses vulnérabilités XXE sont aveugles, ce qui signifie que l’application ne retourne pas les valeurs des entités externes définies dans ses réponses, rendant impossible la récupération directe de fichiers côté serveur. Cependant, XXE aveugle peut toujours être détecté et exploité via des techniques hors bande pour exfiltrer des données et provoquer des erreurs de parsing XML qui divulguent des informations sensibles.

Contournement DTD externe

Lorsque les filtres de sécurité bloquent le protocole file://, les attaquants peuvent déclarer leur DTD dans un fichier externe pour contourner le filtrage. En créant des payloads XXE qui amènent les applications vulnérables à contacter des serveurs contrôlés par l’attaquant pour charger des fichiers DTD malveillants, ils peuvent exécuter des payloads sans spécifier directement des protocoles bloqués.

Exploitation des entités paramètre

Les entités paramètre peuvent être utilisées pour contourner les protections et filtres qui bloquent les entités externes classiques. Cette technique consiste à définir des entités paramètre dans des DTD externes, qui sont ensuite traitées pour construire le payload d’attaque final.

Stratégies de défense complètes

Renforcement au niveau du parseur

Les parseurs XML doivent être configurés avec des paramètres de sécurité prioritaires, notamment en désactivant le traitement DTD lorsque ce n’est pas nécessaire. Pour la plupart des applications, désactiver complètement le traitement DTD est la meilleure défense :

Pour les applications Java :

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

Pour les applications .NET :

XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
settings.XmlResolver = null;

Pour PHP :

libxml_disable_entity_loader(true);

Validation et assainissement des entrées

Les systèmes doivent vérifier la présence de déclarations d’entités externes et de références d’entités suspectes lors de la validation du schéma XML. Les documents doivent être validés selon des schémas pour s’assurer qu’ils respectent les formats attendus avant traitement.

Mettre en œuvre une validation basée sur une liste blanche : - Définir les structures XML autorisées et rejeter les déviations - Supprimer les déclarations DOCTYPE avant traitement - Valider contre des schémas de référence - Rejeter les XML contenant des déclarations d’entités

Contrôles au niveau réseau

Segmenter le réseau pour isoler les systèmes de traitement XML des ressources internes sensibles, limitant ainsi l’impact potentiel des attaques XXE. Cette approche de défense en profondeur inclut :

Placer les services de traitement XML dans des réseaux DMZ
Restreindre les connexions sortantes des parseurs XML
Mettre en œuvre un filtrage strict des sorties
Bloquer l’accès aux points de terminaison de métadonnées cloud (169.254.169.254)
Surveiller les comportements inhabituels d’accès aux fichiers et aux requêtes réseau

Améliorations de l’architecture applicative

Les politiques de sécurité du contenu doivent être appliquées pour empêcher l’accès non autorisé aux ressources et limiter les capacités de traitement XML. Les architectures modernes doivent :

Minimiser l’utilisation de XML au profit de JSON lorsque possible
Isoler le traitement XML dans des services dédiés et renforcés
Mettre en œuvre des contrôles d’accès avec le principe du moindre privilège
Utiliser des bibliothèques de traitement XML sécurisées et régulièrement mises à jour
Effectuer des audits de sécurité réguliers du code de traitement XML

Intégration dans le pipeline de développement

Les tests de vulnérabilité XXE doivent être intégrés dans les pipelines d’intégration et de déploiement continus pour s’assurer que les nouvelles modifications de code n’introduisent pas de vulnérabilités. Cela inclut :

Tests de sécurité statiques (SAST) pour identifier les configurations de parseurs non sécurisées
Tests de sécurité dynamiques (DAST) pour détecter les vulnérabilités XXE en temps réel
Analyse de composition logicielle (SCA) pour suivre les bibliothèques XML vulnérables
Revue de code axée sur la sécurité pour toutes les modifications liées à XML
Tests de régression automatisés pour les vulnérabilités XXE

Impact réel : Les CVEs récents racontent l’histoire

CVE-2025-49493 : Akamai CloudTest

Cette vulnérabilité a montré comment les services SOAP sur plusieurs points de terminaison pouvaient partager la même faille XXE, permettant aux attaquants d’exfiltrer des variables d’environnement sensibles et des fichiers système. L’incident a mis en évidence la nature systémique des vulnérabilités XXE dans l’infrastructure SOAP d’entreprise.

CVE-2025-23195 : Apache Ambari

Une vulnérabilité XXE dans le projet Ambari/Oozie est survenue en raison d’un traitement non sécurisé des entrées XML utilisant la classe DocumentBuilderFactory sans désactiver la résolution des entités externes. Ce cas montre que même des projets open-source bien établis peuvent héberger des vulnérabilités XXE.

CVE-2025-30220 : GeoServer WFS

Cette vulnérabilité de haute gravité dans GeoServer provenait d’un traitement incorrect des schémas XML dans la bibliothèque GeoTools, contournant les contrôles de résolution d’entités et créant des vecteurs d’attaque via les points de terminaison WFS. La vulnérabilité a affecté un serveur géospatial largement déployé, soulignant la portée du XXE dans des domaines applicatifs spécialisés.

Défis spécifiques à l’industrie

Systèmes de santé

La migration des dossiers de santé électroniques vers le cloud a soulevé des préoccupations concernant la confidentialité des patients, nécessitant des contrôles d’authentification robustes et de sécurité XML. Les défis spécifiques incluent :

Implémentations héritées HL7 et FHIR utilisant XML
Exigences de conformité HIPAA pour la protection des données
Intégration avec plusieurs systèmes tiers
Disponibilité ²⁴⁄₇ limitant les fenêtres de mise à jour

Services financiers

Les systèmes bancaires centraux utilisent SOAP pour des transactions complexes et à haute fiabilité, où la fiabilité et l’intégrité transactionnelle sont non négociables. Les institutions financières doivent équilibrer :

Exigences de traitement en temps réel
Conformité réglementaire
Intégration avec des systèmes mainframe hérités
Contraintes de mise à niveau sans interruption

Infrastructure gouvernementale

Les systèmes gouvernementaux présentent des risques XXE particulièrement difficiles en raison de : - Systèmes SOAP anciens datant de plusieurs décennies, difficiles à remplacer - Exigences d’intégration multi-fournisseurs - Processus stricts de certification et d’accréditation - Contraintes budgétaires limitant la modernisation - Cibles de haute valeur pour des adversaires étatiques

Surveillance et détection

Journalisation et alertes

Une journalisation et une surveillance complètes doivent être mises en œuvre pour détecter les tentatives d’attaque XXE, notamment les comportements inhabituels d’accès aux fichiers et aux requêtes réseau. La surveillance efficace inclut :

Suivi de toutes les opérations d’analyse XML
Alertes sur la présence de déclarations DOCTYPE dans des entrées non fiables
Surveillance des accès au système de fichiers depuis les processus de parseurs XML
Détection de connexions sortantes inhabituelles depuis les serveurs d’applications
Corrélation des événements de sécurité à plusieurs niveaux

Indicateurs de compromission

Les organisations doivent surveiller : - Payloads XML contenant SYSTEM ou PUBLIC - Requêtes vers les points de terminaison de métadonnées cloud (169.254.169.254) - Accès à des fichiers système sensibles depuis les processus web - Documents XML volumineux ou structures profondément imbriquées - Messages d’erreur révélant des chemins de fichiers ou des détails internes

La voie à suivre : évoluer au-delà du XXE

Adoption de formats de données modernes

Les organisations doivent envisager de migrer du XML vers JSON ou d’autres formats modernes qui ne comportent pas les mêmes risques de sécurité inhérents. Bien que cela ne soit pas toujours réalisable pour les systèmes hérités, les nouveaux développements doivent privilégier des alternatives plus sûres.

Sensibilisation et formation à la sécurité

La véritable sécurité commence avant le code — dans les hypothèses, l’architecture et la culture. Les équipes de développement doivent :

Suivre une formation régulière sur XXE et autres vulnérabilités d’injection
Désigner des champions de la sécurité au sein des équipes d’ingénierie
Rédiger des lignes directrices de codage sécurisé spécifiques à la gestion XML
Organiser des sessions de modélisation des menaces pour les fonctionnalités de traitement XML

Exigences de sécurité pour les fournisseurs

Lors de l’achat de logiciels ou de services, les organisations doivent : - Exiger que les fournisseurs démontrent des protections contre XXE - Inclure des tests XXE dans les critères d’acceptation - Imposer des configurations sécurisées pour les parseurs XML - Demander des évaluations de sécurité et des tests de pénétration réguliers

Conclusion : Une menace “ancienne” aux conséquences modernes

Les vulnérabilités XXE représentent un paradoxe en cybersécurité moderne : une vulnérabilité bien comprise, documentée en détail, qui continue de compromettre les systèmes en 2025. Les CVEs récents affectant de grandes entreprises technologiques et des projets open-source montrent que le XXE reste une menace critique malgré des décennies de sensibilisation.

La persistance des vulnérabilités XXE provient de plusieurs facteurs : configurations de parseurs peu sécurisées, architectures d’applications complexes, contraintes des systèmes hérités, et la nature invisible du traitement XML dans les applications modernes. Les API SOAP continuent de soutenir des opérations critiques dans la finance, la santé et le gouvernement, rendant leur sécurité essentielle. Les fonctionnalités de téléchargement de fichiers, en particulier celles traitant SVG et autres formats XML, créent des surfaces d’attaque supplémentaires que les développeurs négligent souvent.

La solution requiert une approche multicouche : renforcer les parseurs XML, mettre en œuvre une validation robuste des entrées, déployer une segmentation réseau, intégrer des tests de sécurité dans les pipelines de développement, et promouvoir une culture de sécurité. Les organisations ne peuvent pas se permettre de considérer le XXE comme une vulnérabilité “héritée” — le paysage des menaces 2025 le prouve, il est toujours très actif.

En avançant, la leçon est claire : en cybersécurité, “ancien” ne signifie pas “sans importance”. Les fondamentaux comptent, et ne pas traiter des vulnérabilités bien connues comme le XXE peut avoir des conséquences dévastatrices, peu importe la sophistication des autres mesures de sécurité. La hantise des applications modernes par le XXE continuera tant que l’industrie ne s’engagera pas collectivement à des configurations sécurisées par défaut et à des stratégies de défense globales.

Mots-clés : Entity Externe XML, vulnérabilité XXE, sécurité API SOAP, injection XML, vulnérabilités de téléchargement de fichiers, prévention XXE, sécurité application web, falsification de requêtes côté serveur, exploitation XXE, sécurité parseur XML, CVE-2025-49493, XXE aveugle, SSRF XXE, attaque “Billion Laughs”, SVG XXE, sécurité SOAP 2025