CVE-2026-40859 is a high-severity (CVSS 8.1) Deserialization of Untrusted Data vulnerability in org.apache.camel:camel-vertx-http. A fix is available for org.apache.camel:camel-vertx-http — see the affected versions and patch details below.
Apache Camel: Camel-Vertx-Http: Unsafe Java deserialization of HTTP response bodies via a raw ObjectInputStream when transferException is enabled
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40859.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-40859 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.apache.camel:camel-vertx-http☕org.apache.camel:camel-vertx-http☕org.apache.camel:camel-vertx-http☕org.apache.camel:camel-netty-http☕org.apache.camel:camel-netty-http☕org.apache.camel:camel-netty-httpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.apache.camel:camel-vertx-http | ≥ 4.0.0&&< 4.14.8 | 4.14.8org.apache.camel:camel-vertx-http:4.14.8 |
| ☕Maven | org.apache.camel:camel-vertx-http | ≥ 4.15.0&&< 4.18.3 | 4.18.3org.apache.camel:camel-vertx-http:4.18.3 |
| ☕Maven | org.apache.camel:camel-vertx-http | ≥ 4.19.0&&< 4.20.0 | 4.20.0org.apache.camel:camel-vertx-http:4.20.0 |
| ☕Maven | org.apache.camel:camel-netty-http | ≥ 4.0.0&&< 4.14.8 | 4.14.8org.apache.camel:camel-netty-http:4.14.8 |
| ☕Maven | org.apache.camel:camel-netty-http | ≥ 4.15.0&&< 4.18.3 | 4.18.3org.apache.camel:camel-netty-http:4.18.3 |
| ☕Maven | org.apache.camel:camel-netty-http | ≥ 4.19.0&&< 4.20.0 | 4.20.0org.apache.camel:camel-netty-http:4.20.0 |
Affected Products
camelapacheDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.apache.camel:camel-vertx-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.apache.camel:camel-vertx-http to 4.14.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40859 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated as Important because it allows for remote code execution in Apache Camel applications using the `camel-vertx-http` component. Exploitation requires a non-default configuration where `transferException=true` or `allowJavaSerializedObject=true` is enabled on the producer endpoint, in addition…
To mitigate this issue, avoid enabling `transferException=true` or `allowJavaSerializedObject=true` on Apache Camel `camel-vertx-http` producer endpoints that communicate with untrusted or network-reachable backend services. Ensure all producer connections utilize TLS (HTTPS) to prevent man-in-the-middle attacks. If enabling these options is necessary, configure a strict deserialization filter using the `-Djdk.serialFilter` JVM system property, for example: `-Djdk.serialFilter="java.**;org.apache.camel.**;!*"`. This will restrict the classes allowed during deserialization, limiting the potential impact.Source: Red Hat security advisory for CVE-2026-40859 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Build of Apache Camel 3.33.2.SP3 | org.apache.camel/camel-vertx-http:4.18.3.redhat-00001 | RHSA-2026:48118 |
| Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16 | camel-vertx-http | RHSA-2026:54622 |
Frequently Asked Questions
Is CVE-2026-40859 in your dependencies?
Find it across Maven, including transitive dependencies.