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

CVE-2026-40859 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.4%.

Which versions of Apache Camel are affected by CVE-2026-40859?

Apache Camel's camel-vertx-http component (versions 4.0.0-4.19.0) contains a critical remote code execution flaw when non-default serialization options are enabled, allowing backend compromise if an…. A patch is available.

How to fix or mitigate CVE-2026-40859?

Within 24 hours: Identify all Camel deployments using camel-vertx-http and audit configurations for transferException=true or allowJavaSerializedObject=true; document affected systems. Within 7 days: Apply patch available per vendor advisory through Apache Camel (consult official release notes for version numbers). Within 30 days: Complete patch validation across production and staging environments, confirm application functionality, and evaluate whether non-default serialization configurations remain necessary.

Apache Camel CVE-2026-40859

EUVD-2026-41824 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-07-06 apache

GHSA-6qw3-4796-5984

Deserialization Java RCE 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

8.1 HIGH

AV:N via HTTP responses and PR:N (no auth on Camel), but AC:H because a non-default config, MITM/backend control, and a classpath gadget chain are all required; full C/I/A on RCE.

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

8.1 HIGH

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 - 20:13 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 06, 2026 - 20:13 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:25 vuln.today

Blast Radius

ecosystem impact

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

13 maven packages depend on org.apache.camel:camel-netty-http (5 direct, 8 indirect)
14 maven packages depend on org.apache.camel:camel-vertx-http (5 direct, 9 indirect)

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

DescriptionCVE.org

Deserialization of Untrusted Data vulnerability in Apache Camel.

The camel-vertx-http component deserializes HTTP response bodies carrying the Content-Type application/x-java-serialized-object using a raw java.io.ObjectInputStream, without applying any ObjectInputFilter (VertxHttpHelper.deserializeJavaObjectFromStream) This deserialization path is reached only when the producer endpoint is configured with transferException=true (or the component-level allowJavaSerializedObject=true) and throwExceptionOnFailure is left at its default value of true; in that case a backend HTTP response with a 5xx status and the application/x-java-serialized-object content type has its body deserialized with no class restrictions. An attacker who controls the backend the Camel producer talks to - through a man-in-the-middle position on an unencrypted (plain HTTP) connection, or by compromising the backend service - can return a crafted serialized Java object and, if a suitable gadget chain is present on the classpath, achieve remote code execution on the Camel application host. The path is not reachable in the default configuration, where transferException is false. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, 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.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, the deserialization performed by both helper utilities is constrained by a default ObjectInputFilter (allow-list java.;javax.;org.apache.camel.;!*), which can be customised through the new deserializationFilter endpoint option or the JVM-wide -Djdk.serialFilter system property. For deployments that cannot upgrade immediately: do not enable transferException=true (or allowJavaSerializedObject=true) on producers that talk to untrusted or network-reachable backends; ensure producer connections use TLS (https) so that a response cannot be substituted by a man-in-the-middle; and, where the option is required, set an explicit -Djdk.serialFilter allow-list (for example java.;org.apache.camel.**;!*) to constrain deserialization.

Articles & Coverage 1

News 6 New Java Vulnerabilities - 6 High Severity, No POC Available Jul 07, 2026

AnalysisAI

Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a producer endpoint deserializes 5xx HTTP response bodies marked application/x-java-serialized-object through a raw java.io.ObjectInputStream with no class filtering. Exploitation is limited to non-default deployments where transferException=true or allowJavaSerializedObject=true is set and throwExceptionOnFailure remains true, letting an attacker who controls or intercepts the backend deliver a malicious serialized object and, given a gadget chain on the classpath, run code on the Camel host. This is a vendor-reported (Apache) issue with a publicly available advisory; there is no public exploit identified at time of analysis and EPSS is low at 0.39% (31st percentile).

Technical ContextAI

The flaw is a classic Java deserialization weakness (CWE-502, Deserialization of Untrusted Data) in the Vert.x-based HTTP producer of Apache Camel, an enterprise integration framework used to route and mediate messages between systems. The specific sink is VertxHttpHelper.deserializeJavaObjectFromStream, which wraps an inbound response body in java.io.ObjectInputStream and calls readObject() without an ObjectInputFilter allow-list, so any serializable class present on the application classpath can be instantiated during deserialization. The affected artifact is Apache Camel (cpe:2.3:a:apache_software_foundation:apache_camel), and the danger materializes only when a suitable 'gadget chain' (e.g., from Commons-Collections, Spring, or similar libraries) is also on the classpath to convert object construction into code execution. The fix introduces a default filter (java.;javax.;org.apache.camel.**;!*), tunable via the deserializationFilter option or the JVM-wide -Djdk.serialFilter property.

RemediationAI

Vendor-released patch: upgrade to Apache Camel 4.20.0, which fixes the issue; users on the 4.14.x LTS stream should move to 4.14.8, and users on the 4.18.x stream should move to 4.18.3. After upgrading, deserialization in the helper utilities is constrained by a default ObjectInputFilter allow-list (java.;javax.;org.apache.camel.;!*), which you can tighten via the new deserializationFilter endpoint option or the JVM-wide -Djdk.serialFilter system property. For deployments that cannot upgrade immediately, do not enable transferException=true or allowJavaSerializedObject=true on producers that talk to untrusted or network-reachable backends (side effect: exceptions from the backend will no longer be transferred as serialized Java objects); ensure producer connections use TLS/https so a response body cannot be substituted by a man-in-the-middle (adds certificate management overhead); and where the serialized-object option is genuinely required, set an explicit allow-list such as -Djdk.serialFilter=java.;org.apache.camel.**;!* to block gadget classes (may break legitimate deserialization of application types outside the allow-list). Full guidance is in the advisory at https://camel.apache.org/security/CVE-2026-40859.html.