Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

FluxContactConfidentialité© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2026-88789 — Preuve de concept exécutable reproduisant la CVE-2026-88789, démontrant XXE et SSRF dans Apache Camel Quarkus camel-quarkus-support-xalan via le XSLT TransformerFactory. | Kitploit
Outils/GitHubGitHub/oscerd/cve-2026-88789
Outils DéfensifsAnalyse des VulnérabilitésExploitationSécurité WebApprentissage et Éducation
GitHuboscerd/cve-2026-88789

CVE-2026-88789

Preuve de concept exécutable reproduisant la CVE-2026-88789, démontrant XXE et SSRF dans Apache Camel Quarkus camel-quarkus-support-xalan via le XSLT TransformerFactory.

Voir le dépôt
il y a 16h 15mPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2026-88789 — Camel Quarkus : le TransformerFactory Xalan forcé annule les restrictions d'accès externe JAXP

Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel Quarkus où l'extension de support XSLT (camel-quarkus-support-xalan) fournit son propre TransformerFactory basé sur Xalan au composant xslt et l'enregistre comme implémentation par défaut JAXP. Xalan-J 2.7.x est antérieur à JAXP 1.5 et ne peut pas honorer javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD ni ACCESS_EXTERNAL_STYLESHEET — setAttribute() lève IllegalArgumentException pour les deux — de sorte que les restrictions d'accès externe qu'Apache Camel applique au TransformerFactory qu'il crée n'ont jamais été effectives.

RuntimeRépertoireStack
Camel Quarkuscamel-quarkus/Camel Quarkus 3.36.0 (Quarkus 3.36.0, Camel 4.20.0)

Camel Quarkus uniquement. Le code vulnérable est une extension Camel Quarkus, pas un composant Camel. Le Camel standard et Camel Spring Boot utilisent le TransformerFactory du JDK, qui honore les deux attributs, il n'y a donc rien à reproduire là-bas — ce dépôt n'a par conséquent pas de variante camel-spring-boot/.

Ce qu'il démontre

Un attaquant qui fournit le document XML en cours de transformation peut lire des fichiers locaux ou atteindre des emplacements réseau internes via une déclaration d'entité externe dans ce document.

cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

Sortie attendue sur une version affectée (abrégée — le pilote exécute six sondes, voir camel-quarkus/README.md) :

1) xslt endpoint, body is a StreamSource, external entity -> file:///tmp/cve-2026-88789-secrets/db-password.txt
     transformation result: [db.password=LOCAL-FILE-s3cr3t-99]
     local file contents in the output: true

2) xslt endpoint, body is a StreamSource, external entity -> http://127.0.0.1:8080/internal/secret
     transformation result: [INTERNAL-SECRET-s3cr3t-42]
     internal endpoint response in the output: true

4) CONTROL - same document as a String body (Camel converts it to a SAXSource itself)
     transformation result: []
     local file contents in the output: false

5) TransformerFactory.newInstance() anywhere in the application
     factory: org.apache.camel.quarkus.support.xalan.XalanTransformerFactory
     setAttribute(ACCESS_EXTERNAL_DTD, ""):        REFUSED, IllegalArgumentException: ...
     identity transform of the same document: [... <data>db.password=LOCAL-FILE-s3cr3t-99</data> ...]

Requests the XML parser made to internal endpoints on its own: [GET /internal/secret, GET /internal/leak.dtd]

>>> PROVEN: ...

Vérifié également contre Camel Quarkus 3.40.0 : chaque sonde qui fuit devient silencieuse, les points de terminaison internes ne reçoivent aucune requête du tout, et le pilote affiche NOT reproduced.

Quels chemins sont affectés

Sur le chemin du composant xslt, seuls les corps qui atteignent le transformateur déjà en tant que javax.xml.transform.Source sont affectés. Les corps d'autres types — String, byte[], InputStream — sont convertis par Apache Camel en un SAXSource avec les entités externes et le chargement de DTD externe désactivés, et ne sont pas affectés. La sonde 4 dans le reproducteur est ce chemin sûr, côte à côte avec le chemin non sûr.

Parce que la fabrique est également enregistrée comme implémentation par défaut JAXP (l'extension de support fournit META-INF/services/javax.xml.transform.TransformerFactory), tout autre code de l'application qui obtient une fabrique via TransformerFactory.newInstance() perd les mêmes restrictions, sans erreur. C'est pourquoi l'avis liste des extensions qui ne transforment jamais rien elles-mêmes :

ExtensionExposition
camel-quarkus-xsltle chemin du composant xslt et l'implémentation par défaut JAXP
camel-quarkus-xslt-saxonl'implémentation par défaut JAXP
camel-quarkus-tikal'implémentation par défaut JAXP
camel-quarkus-xmlsecurityl'implémentation par défaut JAXP

Résumé de la vulnérabilité

PropriétéValeur
Composantcamel-quarkus-support-xalan (extension de support XSLT)
CWECWE-611 (Restriction inappropriée de la référence d'entité externe XML)
SévéritéÉlevée
Vecteur d'attaqueUne entité externe ou une DTD externe déclarée dans le document XML en cours de transformation, où le corps atteint le point de terminaison xslt déjà en tant que javax.xml.transform.Source
ImpactLecture de fichiers locaux ; émission de requêtes vers des emplacements réseau internes (SSRF)
Versions affectéesDe 3.2.0 avant 3.33.3, de 3.34.0 avant 3.40.0
Versions corrigées3.33.3 (flux LTS), 3.40.0
Issue GitHubapache/camel-quarkus#9115
CréditDécouvert par analyse interne, à l'aide de Claude Security Tool

Avis : https://camel.apache.org/security/CVE-2026-88789.html

Le correctif

XalanTransformerFactory applique désormais les restrictions lui-même au lieu de s'appuyer sur des attributs que Xalan ne peut pas honorer :

  • Les documents en cours de transformation sont analysés avec un XMLReader qui ne résout ni les entités générales externes ni les entités paramètres externes et ne charge pas les DTD externes — la même configuration que celle utilisée par XmlConverter.createSAXParserFactory() d'Apache Camel pour les corps que camel-xslt convertit lui-même en SAXSource. Un SAXSource portant un XMLReader configuré par l'appelant est utilisé tel quel, et DOMSource et StAXSource sont déjà analysés.
  • Les ressources récupérées au moment de la transformation par la fonction document() sont refusées à moins que le URIResolver propre à l'application ne les résolve, et la restriction est installée sur chaque point d'entrée qui remet quelque chose avec quoi transformer, y compris les points d'entrée push SAX dont les transformateurs ne reçoivent pas la copie du résolveur de fabrique par Xalan. Les applications qui définissent leur propre résolveur — camel-xslt le fait sur chaque échange — continuent de le remplacer comme avant.

Corrigé sur main dans 9a570b64 et 9dd11779, rétroporté vers 3.33.x dans ad9c5236 et 3d886769.

Si vous ne pouvez pas encore mettre à niveau

  • Ne passez pas un javax.xml.transform.Source construit à partir d'une entrée non fiable dans un point de terminaison xslt. Laissez le corps du message en String, byte[] ou InputStream afin qu'Apache Camel le convertisse d'abord en un SAXSource avec les entités externes désactivées.
  • convertBodyTo sur un corps Source existant n'est pas une solution de contournement : cette conversion effectue une transformation identité via la même fabrique. La sonde 5 dans le reproducteur est cette transformation identité, et elle fuit.
  • Le code d'application ou de bibliothèque qui s'appuie sur les restrictions d'accès externe JAXP doit demander l'implémentation du JDK explicitement, en nommant com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl, plutôt que de s'appuyer sur TransformerFactory.newInstance(). La sonde 6 est ce contrôle, et elle refuse la lecture.

Avertissement

Télécharger l’outil