What is the CVSS score of CVE-2026-42527?

CVE-2026-42527 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/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 CVE-2026-42527?

Apache Camel versions 4.14.0 through 4.20.x contain a blind out-of-band data exfiltration vulnerability in object deserialization filtering that affects organizations using Camel JMS components.. A patch is available.

How to fix or mitigate CVE-2026-42527?

Within 24 hours: Conduct inventory of all Apache Camel deployments in use, specifically identifying instances running versions 4.14.0-4.20.x with active JMS components. Within 7 days: Patch available per vendor advisory-upgrade to the recommended fixed version per Apache security advisory. Within 30 days: Validate all patched instances in production environments and monitor for anomalous egress DNS activity to detect potential exploitation attempts.

Apache Camel CVE-2026-42527

EUVD-2026-41825 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-07-06 apache

GHSA-8h6p-jvhf-9hcr

Deserialization Apache Apache Camel Red Hat

8.1

CVSS 3.1 · Vendor: apache

Severity by source

Vendor (apache) PRIMARY

8.1 MEDIUM

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

vuln.today AI

3.7 LOW

Network-delivered serialized payload with AC:H (must reach a listening consumer under default filter); PR:N at the Camel layer; demonstrated impact is a blind DNS out-of-band side channel, so only C:L with I/A none.

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

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

Red Hat

5.3 MEDIUM

qualitative

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jul 06, 2026 - 19:58 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 06, 2026 - 19:22 vuln.today

cvss_changed

CVSS changed

Jul 06, 2026 - 19:22 NVD

8.1 (HIGH)

Patch available

Jul 06, 2026 - 10:01 EUVD

Analysis Generated

Jul 06, 2026 - 09:27 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

11 maven packages depend on org.apache.camel:camel-amqp (5 direct, 6 indirect)
12 maven packages depend on org.apache.camel:camel-cassandraql (6 direct, 6 indirect)
10 maven packages depend on org.apache.camel:camel-consul (3 direct, 7 indirect)
14 maven packages depend on org.apache.camel:camel-infinispan (5 direct, 9 indirect)
35 maven packages depend on org.apache.camel:camel-jms (14 direct, 21 indirect)

Ecosystem-wide dependent count for version 4.14.0 and other introduced versions.

DescriptionCVE.org

Deserialization of Untrusted Data vulnerability in Apache Camel.

The default ObjectInputFilter pattern shipped with several Apache Camel components for defense-in-depth deserialization filtering ('java.;javax.;org.apache.camel.;!*', or the no-'javax.' variant in the aggregation-repository components) uses a recursive 'java.**' glob that admits classes whose hashCode/equals/readObject methods perform network I/O, notably java.net.URL and java.net.InetAddress. When an attacker can deliver a Java-serialized payload to an affected Camel consumer, deserialization of a HashMap (or any collection that calls hashCode on its elements) containing java.net.URL keys causes the JVM to issue DNS queries to the attacker-supplied host during the deserialization side-effect. The class-level filter check passes because the resulting object's class (HashMap) is allow-listed; the DNS query is observable on an attacker-controlled DNS server, providing an out-of-band side channel. The exposure is highest on the camel-jms family because JmsBinding.extractBodyFromJms invokes ObjectMessage.getObject() unconditionally when mapJmsMessage=true (default). Affected components: camel-jms, camel-sjms, camel-amqp, camel-mina, camel-netty, camel-netty-http, camel-vertx-http, camel-infinispan, and the aggregation repository components camel-leveldb, camel-cassandraql, camel-consul, camel-sql (JDBC aggregation repository). This issue affects Apache Camel: from 4.14.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to a version that contains the CAMEL-23372 fix once available: 4.21.0 for the 4.21.x line, 4.18.3 for the 4.18.x line, and 4.14.8 for the 4.14.x line. For deployments that cannot upgrade immediately, configure a JMS-provider-side allow-list (Apache ActiveMQ Artemis 'deserializationAllowList' / 'deserializationDenyList', Apache ActiveMQ Classic 'org.apache.activemq.SERIALIZABLE_PACKAGES') as the primary mitigation, and/or override the in-code default via the endpoint-level 'deserializationFilter' option or the JVM-wide '-Djdk.serialFilter' system property with an explicit deny: '!java.net.;java.;javax.;org.apache.camel.;!*' (or '!java.net.;java.;org.apache.camel.;!*' for the aggregation-repository components, which do not include javax.).

AnalysisAI

Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern bundled with several components ('java.;javax.;org.apache.camel.;!*') uses a recursive java. glob that allow-lists java.net.URL and java.net.InetAddress. Remote attackers who can deliver a Java-serialized payload to an affected Camel consumer - most notably the camel-jms family, where JmsBinding.extractBodyFromJms calls ObjectMessage.getObject() by default (mapJmsMessage=true) - can force the JVM to issue DNS queries to an attacker-controlled host during deserialization side-effects, yielding an observable out-of-band channel. Reported by Apache; there is no public exploit identified at time of analysis, EPSS is low (0.31%, 23rd percentile), and it is not listed in CISA KEV.

Technical ContextAI

The flaw is a CWE-502 Deserialization of Untrusted Data issue in Apache Camel's integration components. Camel ships a defense-in-depth ObjectInputFilter (JDK serialization filter) intended to constrain which classes may be deserialized, but the pattern relies on a recursive 'java.**' glob. Because the class-level filter only checks the concrete resulting class (e.g., HashMap, which is allow-listed), it does not prevent element classes like java.net.URL whose hashCode/equals/readObject perform network I/O. Deserializing a HashMap keyed on java.net.URL objects causes the JVM to resolve the URL host during hashCode computation, emitting a DNS query. The CPE cpe:2.3:a:apache_software_foundation:apache_camel:*:*:*:*:*:*:*:* identifies Apache Camel as the sole affected product. Exposure is broadest in camel-jms/camel-sjms/camel-amqp because ObjectMessage bodies are deserialized unconditionally when mapJmsMessage is enabled (the default), and also affects camel-mina, camel-netty, camel-netty-http, camel-vertx-http, camel-infinispan, and the aggregation-repository components camel-leveldb, camel-cassandraql, camel-consul, and camel-sql.

RemediationAI

Vendor-released patch: upgrade to the fixed release containing the CAMEL-23372 fix for your line - 4.14.8 for the 4.14.x line, 4.18.3 for the 4.15.0-4.18.x line, and 4.21.0 for the 4.19.x-4.21.x line. For deployments that cannot upgrade immediately, the primary mitigation is a JMS-provider-side allow-list: on Apache ActiveMQ Artemis use 'deserializationAllowList'/'deserializationDenyList', and on ActiveMQ Classic set 'org.apache.activemq.SERIALIZABLE_PACKAGES'; this blocks dangerous classes at the broker but requires enumerating legitimately-serialized classes and can break applications that rely on Java object messages. Alternatively, override the vulnerable in-code default via the endpoint-level 'deserializationFilter' option or the JVM-wide '-Djdk.serialFilter' property with an explicit deny of the network gadget: '!java.net.;java.;javax.;org.apache.camel.;!*' (or '!java.net.;java.;org.apache.camel.;!*' for aggregation-repository components, which omit javax.) - note the JVM-wide flag affects all serialization in the process, so validate it does not reject classes other workloads legitimately deserialize. Where feasible, also restrict which parties can publish to the affected consumers/queues. See https://camel.apache.org/security/CVE-2026-42527.html.