oscerd/cve-2026-85245Preuve de concept Spring Boot exécutable reproduisant CVE-2026-85245, une divulgation de données entre échanges camel-thrift, avec comparaison entre version affectée et version corrigée et notes d'atténuation.
Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où le format de données Thrift démarshalait
dans le defaultInstance partagé du type cible plutôt que dans une copie fraîche, et renvoyait cet objet partagé
comme corps de l'échange. Comme l'instance est partagée à l'échelle du processus, l'état écrit lors du démarshalage d'un message
restait sur l'objet et était visible pour chaque message ultérieur utilisant le même type. Les champs absents d'une
charge utile ultérieure conservaient les valeurs du message précédent, de sorte que le contenu appartenant à un expéditeur pouvait être lu pendant le traitement
du message d'un autre expéditeur, et des échanges concurrents pouvaient observer l'état partiellement écrit de chacun. Dans un
déploiement qui sert plus d'un locataire ou utilisateur via la même route, cela constitue une divulgation des données d'une partie à
une autre.
Spring Boot uniquement. Il n'existe pas d'extension
camel-quarkus-thrift, donc ce reproducteur fournit un unique module Camel Spring Boot. (La faille se trouve dans leThriftDataFormatdu composant, qui est indépendant du runtime.)
| Runtime | Répertoire | Pile |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-thrift 4.22.0 (affecté ; corrigé en 4.22.1) |
Une route définit un seul ThriftDataFormat (adossé au type Thrift généré Work) et le réutilise pour chaque message,
comme le font normalement les routes. Deux locataires envoient un message à travers elle :
Work{num1=1, op=ADD, comment="TENANT-A-SECRET-…"} — le champ optionnel comment transporte des données
sensibles ;Work{num1=3, op=SUBTRACT} — aucun champ comment.La route démarshalait le message du locataire A, puis celui du locataire B.
comment du locataire A — Thrift n'assigne que les
champs présents dans les octets entrants, et les deux messages ont été désérialisés dans (et renvoyés comme) la même instance
partagée, donc le champ manquant de B conservait la valeur de A. Les deux corps sont littéralement le même objet.comment du locataire B est null — chaque échange obtient sa propre copie réinitialisée.cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: B sees A's secret; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85245-thrift-cross-exchange-disclosure-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: B's comment is null; >>> Not exploited
| Propriété | Valeur |
|---|---|
| Composant | camel-thrift (ThriftDataFormat.unmarshal) |
| CWE | CWE-488 (Exposition d'un élément de données à une mauvaise session) |
| Gravité | MOYENNE |
| Vecteur d'attaque | Deux messages du même type Thrift via une même route ; un message ultérieur omettant un champ hérite de la valeur du précédent |
| Impact | Divulgation de données entre échanges / entre locataires ; des échanges concurrents peuvent observer l'état partiellement écrit les uns des autres |
| 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-24442 |
| Crédit | Claude Security Scan Tool |
Avis : https://camel.apache.org/security/CVE-2026-85245.html
Les types Thrift générés (Work, Operation) sont les fixtures de test publiques issues des propres tests camel-thrift
d'Apache Camel.
ThriftDataFormat.unmarshal désérialise désormais dans une copie par échange :
TBase instance = defaultInstance.deepCopy(); instance.clear(); — puis désérialise les octets dans instance et
la retourne. Chaque échange obtient son propre objet réinitialisé, de sorte qu'aucun champ ne se propage entre les messages et que deux échanges ne partagent
pas un même corps.
Copiez le corps désérialisé dans une nouvelle instance immédiatement après l'exécution du format de données, et ne conservez pas de références à l'objet retourné.
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 à jour la résout. Le « secret » est une chaîne de marqueur fictive et inerte. N'utilisez pas ce matériel contre des systèmes que vous ne possédez pas ou n'exploitez pas.