What is the CVSS score of EUVD-2026-25794?

EUVD-2026-25794 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of Apache Camel are affected by EUVD-2026-25794?

Apache Camel's JMS-family components contain a critical remote code execution vulnerability allowing attackers with message queue access to execute arbitrary code through unsafe deserialization.. A patch is available.

How to fix or mitigate EUVD-2026-25794?

Within 24 hours, identify all systems using Apache Camel JMS components (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) that process external or untrusted JMS messages. Within 7 days, obtain the patched version from Apache Camel's official advisory, validate in a staging environment, and deploy to production. Within 30 days, confirm all affected systems are patched and implement strict access controls limiting JMS message publishing permissions to authenticated, trusted internal services only.

Apache Camel EUVD-2026-25794

| CVE-2026-40860 CRITICAL

Deserialization of Untrusted Data (CWE-502)

2026-04-27 security@apache.org

Deserialization RCE Apache Camel

9.8

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

8.1 HIGH

Network-reachable JMS with no auth to Camel (PR:N), but AC:H because exploitation depends on a classpath gadget chain and publish access to a consumed destination; successful RCE yields full C/I/A:H.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 24, 2026 - 02:06 vuln.today

Patch released

Apr 28, 2026 - 19:42 nvd

Patch available

CVSS changed

Apr 27, 2026 - 16:22 NVD

9.8 (CRITICAL)

Patch available

Apr 27, 2026 - 10:01 EUVD

EUVD ID Assigned

Apr 27, 2026 - 09:22 euvd

EUVD-2026-25794

CVE Published

Apr 27, 2026 - 09:16 nvd

CRITICAL 9.8

DescriptionCVE.org

JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6.

This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.

Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.

AnalysisAI

Remote code execution in Apache Camel's JMS-family components (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) allows an attacker who can publish a crafted JMS ObjectMessage to a consumed queue or topic to execute arbitrary code, because JmsBinding.extractBodyFromJms() calls ObjectMessage.getObject() with no ObjectInputFilter, allowlist, or denylist. Exploitation requires a usable deserialization gadget chain on the application classpath and is reachable in the default configuration (mapJmsMessage enabled) whenever Camel acts as a JMS consumer. There is no public exploit identified at time of analysis and the vulnerability is not on CISA KEV; EPSS is low at 0.30% (53rd percentile).

Technical ContextAI

The flaw is a classic CWE-502 unsafe deserialization of untrusted data. Java's native serialization (java.io.ObjectInputStream) reconstructs arbitrary object graphs from a byte stream; when the target application contains gadget classes (e.g., from Commons-Collections, Spring, or similar libraries on the classpath), a crafted stream can be coerced into invoking dangerous methods during deserialization, yielding RCE. In Camel, the JMS message-conversion layer (JmsBinding.extractBodyFromJms in camel-jms and the equivalent class in camel-sjms) unwraps javax.jms.ObjectMessage bodies by calling getObject(), which triggers this deserialization without any ObjectInputFilter or class filtering. Because Sjms2Endpoint extends SjmsEndpoint, AMQPJmsBinding extends JmsBinding, and camel-activemq/activemq6 are built on JmsComponent, the same vulnerable path is inherited transitively across the JMS component family. The CPE data (cpe:2.3:a:apache:camel) confirms Apache Camel itself as the affected product across the listed version ranges, including the explicitly enumerated 4.19.0.

RemediationAI

Vendor-released patch: upgrade to Apache Camel 4.20.0, which fixes the issue; users on the 4.14.x LTS stream should upgrade to 4.14.7 and users on the 4.18.x stream should upgrade to 4.18.2 (per https://camel.apache.org/security/CVE-2026-40860.html). Red Hat consumers should apply RHSA-2026:17668 or RHSA-2026:22453. Where immediate patching is not possible, disable the mapJmsMessage option on affected JMS consumer endpoints so Camel does not auto-convert ObjectMessage bodies (trade-off: routes that rely on automatic JMS body mapping will need explicit handling and may break). Additionally, prevent producers from sending serialized Java objects by avoiding or refusing ObjectMessage on consumed destinations, and configure a JVM-wide deserialization filter (jdk.serialFilter / ObjectInputFilter) to allowlist only expected classes (trade-off: over-tight filters can block legitimate payloads). Restrict who can publish to Camel-consumed queues and topics via broker authentication and ACLs, and remove known deserialization gadget libraries from the classpath where feasible to eliminate exploitable chains.