camel-jms JMS ObjectMessage Désérialisation non sécurisée - Reproducteur (CVE-2026-40860)

Ce projet démontre une vulnérabilité de désérialisation Java dans le composant camel-jms d'Apache Camel (et transitivement dans camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6), référencée sous l'identifiant CVE-2026-40860. JmsBinding.extractBodyFromJms() désérialise la charge utile d'un ObjectMessage JMS entrant via ObjectMessage.getObject() sans ObjectInputFilter, ni liste blanche ou liste noire de classes. Comme cette opération s'exécute chaque fois que mapJmsMessage=true (valeur par défaut) et que Camel est un consommateur JMS, un attaquant capable de publier un ObjectMessage malveillant dans une file d'attente ou un sujet consommé peut obtenir une exécution de code à distance si une chaîne de gadgets est présente dans le classpath.

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

Résumé de la vulnérabilité

Détails techniques

// JmsBinding.extractBodyFromJms(Exchange, Message) - affected version
if (message instanceof ObjectMessage objectMessage) {
    Object payload = objectMessage.getObject();   // <-- deserializes with no ObjectInputFilter
    if (payload instanceof DefaultExchangeHolder holder) {
        ...
    }
    return payload;
}

getObject() exécute le ObjectInputStream.readObject() du fournisseur JMS sur le corps du message. Camel n'ajoute aucun filtrage de classe de son propre chef, donc une chaîne de gadgets présente dans le classpath s'exécute pendant la désérialisation.

Ce que fait le correctif (et ses limites)

Le correctif (4.14.7 / 4.18.2 / 4.20.0) ajoute une liste blanche par défaut via ObjectInputFilter (java.**;javax.**;org.apache.camel.**;!*), personnalisable via la nouvelle option de point de terminaison deserializationFilter ou via le paramètre JVM global -Djdk.serialFilter. Voici le message de validation de Camel concernant le correctif :

cette vérification s'effectue après que le fournisseur JMS a déjà désérialisé la charge utile. Elle empêche la propagation de classes inattendues vers la route, mais elle ne peut pas, à elle seule, arrêter les chaînes de gadgets dont le readObject() est déclenché à l'intérieur du ObjectInputStream du fournisseur. Une protection complète nécessite de configurer le filtre de désérialisation du fournisseur JMS lui-même et/ou le -Djdk.serialFilter global.

Donc la protection complète = mise à jour de Camel + restriction du fournisseur / du filtre JVM. Ce PoC utilise un client ActiveMQ avec trustAllPackages=true (un paramètre courant dans la réalité) afin que le fournisseur désérialise la charge utile ; sur une version affectée de Camel, rien d'autre ne s'interpose.

La route victime

from("jms:queue:evil")            // mapJmsMessage defaults to true
    .log("Consumed: ${body.class.name}");

Le simple fait de recevoir le ObjectMessage déclenche la désérialisation — le corps de la route est sans importance.

Disposition du dépôt — attaquant vs victime

La victime est le consommateur Camel JMS. L'attaquant est tout producteur capable de publier dans la file d'attente. Les deux communiquent avec un courtier Apache ActiveMQ Artemis réel tournant dans Docker.

CVE-2026-40860/
├── pom.xml                 # camel-jms 4.18.1 + activemq-client 6.2.4 + commons-collections 3.2.1 (gadget)
├── Dockerfile              # runs the app (--add-opens only to build the gadget)
├── docker-compose.yml      # Artemis broker (quay.io) + the reproducer app
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── JmsConfig.java          # OpenWire ConnectionFactory (trustAllPackages=true) + jms component
    │   ├── VictimRoute.java        # victim: from("jms:queue:evil")
    │   ├── Gadget.java             # CommonsCollections6 gadget, fires during getObject()
    │   └── ExploitController.java  # attacker: publishes ObjectMessage(gadget) to the queue
    └── resources/
        └── application.properties

Dans une attaque réelle, les octets sérialisés sont produits hors ligne par l'attaquant (par exemple avec ysoserial); seule la victime a besoin de la chaîne de gadgets dans son classpath. Ce PoC construit le gadget en cours d'exécution pour des raisons de commodité, c'est pourquoi la JVM est lancée avec --add-opens java.base/java.util=ALL-UNNAMED — un détail de construction du gadget, sans rapport avec la vulnérabilité.

Prérequis

• Java 17+ et Maven 3.8+
• Docker (exécute le courtier et l'application)

Étapes de reproduction

Étape 1 : Construction et démarrage de tout

mvn clean package -DskipTests
docker compose up -d --build

Cela démarre un courtier Artemis (quay.io/artemiscloud/activemq-artemis-broker) et l'application de reproduction, qui s'y connecte via OpenWire.

Étape 2 : Déclenchement de la désérialisation (RCE)

curl -s http://localhost:8080/exploit/attack
# -> ObjectMessage published to queue 'evil'.
#    camel-jms consumer called ObjectMessage.getObject() -> deserialization.
#
#    >>> RCE proof — /tmp/pwned exists: true

Étape 3 : Vérification

docker exec cve-2026-40860 ls -la /tmp/pwned

Nettoyage

docker compose down

Vecteurs d'attaque

Tout consommateur Camel JMS (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) lisant depuis une destination vers laquelle un attaquant peut publier — un courtier partagé, un sujet avec des producteurs ouverts, une file d'attente alimentée par une source amont non fiable — avec mapJmsMessage=true (valeur par défaut).

Conditions d'exploitation

1. Un consommateur Camel JMS avec mapJmsMessage=true (par défaut).
2. L'attaquant peut mettre en file d'attente un ObjectMessage vers la destination consommée.
3. Le fournisseur JMS désérialise la charge utile (par exemple ActiveMQ trustAllPackages=true, ou un fournisseur sans filtre restrictif).
4. Une bibliothèque de gadgets dans le classpath (ici commons-collections:3.2.1).

Correctif recommandé

Mettez à jour vers 4.14.7 / 4.18.2 / 4.20.0, et restreignez la désérialisation de bout en bout :

• Définissez une liste blanche au niveau JVM : -Djdk.serialFilter=java.**;org.apache.camel.**;!* (ou la nouvelle option de point de terminaison deserializationFilter).
• Configurez le filtre de désérialisation propre au fournisseur JMS (par exemple ActiveMQ trustedPackages, n'utilisez pas trustAllPackages=true).

Atténuation

En attendant la mise à jour :

1. Préférez les charges utiles autres que ObjectMessage ; définissez mapJmsMessage=false lorsque le message brut est acceptable.
2. Verrouillez les packages de confiance du fournisseur JMS ; n'utilisez jamais trustAllPackages=true sur des destinations non fiables.
3. Appliquez -Djdk.serialFilter.
4. Supprimez les bibliothèques de gadgets du classpath (mettez à jour/supprimez commons-collections 3.x et similaires).

Avertissement

Ce reproducteur est fourni uniquement pour la recherche en sécurité et les tests autorisés, pour une vulnérabilité publiquement divulguée et corrigée. Ne l'utilisez pas contre des systèmes sans autorisation explicite.