oscerd/cve-2026-85247Reproducteur exécutable Spring Boot et Quarkus pour CVE-2026-85247, démontrant le repli TLS trust-all de camel-knative et vérifiant le correctif.
Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où l'activation de SSL sur le client HTTP Knative sans configuration d'un truststore revenait à faire confiance à tout certificat présenté plutôt qu'aux ancres de confiance par défaut de la JVM. Un déploiement qui activait TLS sans configurer également un truststore obtenait donc une connexion chiffrée sans authentification du pair, qu'un attaquant positionné sur le chemin réseau peut intercepter et lire. L'état dangereux est atteint par omission, et non par une activation explicite — activer TLS ne devrait pas être ce qui désactive la validation des certificats.
| Runtime | Répertoire | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-knative 4.22.0 (affecté ; corrigé en 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-knative (Camel 4.15.0, affecté ; contrôle corrigé CQ 3.40.0 / Camel 4.22.1) |
Les deux modules démontrent le comportement affecté et le comportement corrigé.
Le déploiement définit camel.knative.client.ssl.enabled=true et ne configure aucun truststore. Le pilote construit le véritable KnativeSslClientOptions à partir de exactement ces paramètres — les mêmes options que celles utilisées par le producteur HTTP Knative — et effectue une requête HTTPS avec celles-ci vers un serveur embarqué qui présente un certificat auto-signé (CN=localhost, absent de tout truststore), représentant un homme du milieu TLS.
KnativeSslClientOptions.getTrustOptions() renvoie TrustAllOptions, donc le client accepte le certificat auto-signé et la requête réussit — chiffrée mais non authentifiée.SunCertPathBuilderException: unable to find valid certification path.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: trusts the self-signed cert; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85247-knative-cert-validation-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: handshake fails; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.15.0): trusts the self-signed cert
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: handshake fails
| Propriété | Valeur |
|---|---|
| Composant | camel-knative (KnativeSslClientOptions.configureOptions) |
| CWE | CWE-295 (Validation de certificat incorrecte) |
| Gravité | MOYENNE |
| Vecteur d'attaque | Attaque de l'homme du milieu sur le réseau contre un client HTTP Knative ayant activé SSL mais configuré aucun truststore |
| Impact | Connexion chiffrée sans authentification du pair : tout certificat est accepté, de sorte que TLS peut être intercepté et lu |
| Versions affectées | À partir de 4.0.0 avant 4.18.5, à partir de 4.19.0 avant 4.22.1 |
| Versions corrigées | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24443 |
| Crédit | Claude Security Scan Tool |
Avis de sécurité : https://camel.apache.org/security/CVE-2026-85247.html
Le fichier server-keystore.p12 fourni est une paire de clés auto-signée jetable (CN=localhost) générée uniquement pour ce
reproducteur.
KnativeSslClientOptions.configureOptions : lorsque SSL est activé sans
keystore, truststore ni chemin de certificat de confiance, les options de confiance sont désormais laissées non définies, de sorte que Vert.x se rabat sur les ancres de confiance par défaut de la JVM — le même repli que SSLContextParameters et le reste de Camel utilisent. TrustAllOptions n'est désormais atteint qu'en définissant explicitement camel.knative.client.ssl.trust.all=true (ce qui reste disponible pour le développement contre un cluster doté d'un certificat auto-signé). Après la mise à niveau, un déploiement qui reposait sur le comportement implicite de confiance totale doit soit configurer un truststore, soit définir délibérément trust.all.
Configurez explicitement un truststore partout où SSL est activé sur le client HTTP Knative.
Ce dépôt est publié à des fins éducatives et défensives : pour aider les utilisateurs d'Apache Camel à comprendre la vulnérabilité, à vérifier s'ils sont affectés et à confirmer que la mise à niveau la résout. Le keystore auto-signé est un élément local inerte. N'utilisez pas ce contenu contre des systèmes que vous ne possédez pas ou n'exploitez pas.