camel-jms Riproduttore di deserializzazione non sicura di JMS ObjectMessage (CVE-2026-40860)

Questo progetto dimostra una vulnerabilità di deserializzazione Java nel componente camel-jms di Apache Camel (e, transitivamente, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6), identificata come CVE-2026-40860. JmsBinding.extractBodyFromJms() deserializza il payload di un JMS ObjectMessage in arrivo tramite ObjectMessage.getObject() senza ObjectInputFilter, lista di classi consentite o negate. Poiché questo avviene ogni volta che mapJmsMessage=true (impostazione predefinita) e Camel è un JMS consumer, un attaccante in grado di pubblicare un ObjectMessage appositamente costruito su una coda/topic consumata può ottenere esecuzione di codice in remoto quando una catena di gadget è nel classpath.

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

Riepilogo della vulnerabilità

Dettagli tecnici

// 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() esegue il ObjectInputStream.readObject() del provider JMS sul corpo del messaggio. Camel non aggiunge alcun filtro di classi proprio, quindi una catena di gadget presente nel classpath viene eseguita durante la deserializzazione.

Cosa fa la correzione (e i suoi limiti)

La correzione (4.14.7 / 4.18.2 / 4.20.0) aggiunge una allow-list predefinita di ObjectInputFilter (java.**;javax.**;org.apache.camel.**;!*), personalizzabile tramite la nuova opzione di endpoint deserializationFilter o tramite il filtro globale JVM -Djdk.serialFilter. Da notare quanto riportato nel messaggio di commit di Camel per la correzione:

questo controllo viene eseguito dopo che il provider JMS ha già deserializzato il payload. Impedisce che classi inattese vengano propagate alla route, ma da solo non può fermare le catene di gadget il cui readObject() scatta all'interno di ObjectInputStream del provider. Una protezione completa richiede di configurare il filtro di deserializzazione del provider JMS e/o il filtro JVM globale -Djdk.serialFilter.

Quindi la protezione completa = aggiornare Camel + limitare il provider / il filtro JVM. Questa PoC usa un client ActiveMQ con trustAllPackages=true (un'impostazione comune negli ambienti reali) così il provider deserializza il payload; su una versione vulnerabile di Camel non c'è altro a impedirlo.

La route vittima

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

Il semplice ricevimento dell'ObjectMessage attiva la deserializzazione — il corpo della route è irrilevante.

Struttura del repository — attaccante vs. vittima

La vittima è il consumer JMS di Camel. L'attaccante è qualsiasi producer che può pubblicare sulla coda. Entrambi comunicano con un broker reale Apache ActiveMQ Artemis in esecuzione in 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

In un attacco reale, i byte serializzati sono prodotti offline dall'attaccante (ad es. con ysoserial); solo la vittima ha bisogno della catena di gadget nel proprio classpath. Questa PoC costruisce il gadget in-process per comodità, ed è per questo che la JVM viene eseguita con --add-opens java.base/java.util=ALL-UNNAMED — un dettaglio di costruzione del gadget, non correlato alla vulnerabilità.

Prerequisiti

• Java 17+ e Maven 3.8+
• Docker (esegue il broker e l'app)

Passaggi per la riproduzione

Passaggio 1: compilare e avviare tutto

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

Questo avvia un broker Artemis (quay.io/artemiscloud/activemq-artemis-broker) e l'app di riproduzione, che si connette ad esso tramite OpenWire.

Passaggio 2: attivare la deserializzazione (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

Passaggio 3: verifica

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

Pulizia

docker compose down

Vettori d'attacco

Qualsiasi consumer JMS di Camel (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) che legge da una destinazione su cui un attaccante può pubblicare — un broker condiviso, un topic con producer aperti, una coda alimentata da un upstream non attendibile — con mapJmsMessage=true (predefinito).

Condizioni per l'exploit

1. Un consumer JMS di Camel con mapJmsMessage=true (predefinito).
2. L'attaccante può accodare un ObjectMessage alla destinazione consumata.
3. Il provider JMS deserializza il payload (ad es. ActiveMQ con trustAllPackages=true, oppure un provider senza un filtro restrittivo).
4. Una libreria di gadget nel classpath (qui commons-collections:3.2.1).

Correzione consigliata

Aggiornare a 4.14.7 / 4.18.2 / 4.20.0 e limitare la deserializzazione end-to-end:

• Impostare una allow-list a livello JVM: -Djdk.serialFilter=java.**;org.apache.camel.**;!* (oppure la nuova opzione deserializationFilter dell'endpoint).
• Configurare il filtro di deserializzazione del provider JMS stesso (ad es. ActiveMQ trustedPackages; non usare trustAllPackages=true).

Mitigazione

Fino all'aggiornamento:

1. Preferire payload non-ObjectMessage; impostare mapJmsMessage=false dove il messaggio grezzo è accettabile.
2. Bloccare i pacchetti attendibili del provider JMS; mai trustAllPackages=true su destinazioni non attendibili.
3. Applicare -Djdk.serialFilter.
4. Rimuovere le librerie di gadget dal classpath (aggiornare/rimuovere commons-collections 3.x e simili).

Dichiarazione di esclusione di responsabilità

Questo riproduttore è fornito solo per ricerca sulla sicurezza e test autorizzati, per una vulnerabilità pubblicamente divulgata e corretta. Non usarlo contro sistemi senza autorizzazione esplicita.