Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain MITM on plaintext producer link or compromise backend
-
DeliveryReturn 5xx with x-java-serialized-object body
-
ExploitCamel deserializes via raw ObjectInputStream
-
ExecutionTrigger classpath gadget chain
-
ImpactExecute arbitrary code on Camel host
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires ALL of: the camel-vertx-http producer endpoint configured with transferException=true (or component-level allowJavaSerializedObject=true); throwExceptionOnFailure left at its default true; the backend returning an HTTP 5xx status with Content-Type application/x-java-serialized-object; a usable deserialization gadget chain present on the Camel application classpath; and an attacker position that can control the response - either a man-in-the-middle on an unencrypted (plain HTTP) producer connection or a compromised/attacker-controlled backend service. Limiting factors: the path is explicitly NOT reachable in the default configuration (transferException is false by default), so a deliberate non-default setting is mandatory; TLS on the producer connection defeats the MITM route; and absent a suitable gadget chain the deserialization does not yield code execution. Although the CVSS vector is PR:N (no authentication against the Camel app), the combined configuration, network-position, and classpath requirements are why complexity is rated AC:H. |
| Impact | The signals are mixed and should be read carefully. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, base 8.1 High) shows full confidentiality/integrity/availability impact and no authentication, but crucially AC:H reflects the significant preconditions: a non-default configuration plus either a man-in-the-middle position on plaintext HTTP or a compromised backend, plus a usable gadget chain. EPSS is low (0.39%, 31st percentile), and the vulnerability is NOT in CISA KEV, consistent with a targeted-rather-than-opportunistic profile. There is no SSVC record or POC in the provided data. The most important caveat is that PR:N can overstate accessibility: the description explicitly states the path 'is not reachable in the default configuration,' so real-world exposure depends on an operator having enabled transferException/allowJavaSerializedObject and on the presence of a gadget chain - verify these before treating this as internet-facing unauthenticated RCE. Net: a genuine high-severity RCE for the subset of deployments that opt into Java-serialized transfer over untrusted/plaintext channels, but low broad-exploitation likelihood otherwise. |
| Exploit ScenarioDerived | An organization runs a Camel route whose vertx-http producer is configured with transferException=true and talks to an internal service over plain HTTP. An attacker on the network path (MITM) or who has compromised that backend returns a 5xx response with Content-Type application/x-java-serialized-object and a crafted gadget-chain payload; Camel deserializes it and executes attacker code on the Camel host. No public exploit is identified at time of analysis, and the AC:H rating reflects the MITM/backend-control and gadget-chain prerequisites. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jul 06, 2026
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).
Earlier versions of this analysis (2)
Remote code execution in Apache Camel's camel-vertx-http component allows an attacker who controls or intercepts a backend HTTP response to run arbitrary code on the Camel host. The flaw stems from deserializing 5xx response bodies marked application/x-java-serialized-object through a raw ObjectInputStream with no class filtering, but only when producers are configured with transferException=true (or allowJavaSerializedObject=true) and throwExceptionOnFailure left at its default. Reported by Apache with a CVSS of 8.1; there is no public exploit identified at time of analysis and EPSS is low at 0.39%, reflecting the non-default configuration and high attack complexity.
Unrestricted Java deserialization in Apache Camel's camel-vertx-http component allows an attacker who controls the backend HTTP service - via man-in-the-middle on a plain HTTP connection or direct backend compromise - to achieve remote code execution on the Camel application host. The vulnerable path is reached only when transferException=true (or allowJavaSerializedObject=true) is configured on a producer endpoint and the backend returns a 5xx response with Content-Type: application/x-java-serialized-object; a raw java.io.ObjectInputStream without any ObjectInputFilter then deserializes the body with no class restrictions, enabling gadget-chain-based RCE. No public exploit has been identified at time of analysis, but the conditions for exploitation - non-default configuration and gadget chain availability - are realistic in enterprise Java middleware environments where Apache Commons or similar libraries are on the classpath.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
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.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.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
Executive ViewAI
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 attacker intercepts or controls HTTP responses; no public exploit has been identified at time of analysis. Organizations using affected versions risk complete application server takeover and potential data breach. A vendor patch is available and should be prioritized given the severe nature of code execution vulnerabilities.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMat
Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelca
Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern b
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constr
EUVD-2026-41824
GHSA-6qw3-4796-5984
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB