Apache Camel security advisory

CVE-2026-40859

Camel-Vertx-Http and Camel-Netty-Http: Unsafe Java deserialization of HTTP response bodies via a raw ObjectInputStream when transferException is enabled

Description

The camel-vertx-http and camel-netty-http components deserialize HTTP response bodies carrying the Content-Type application/x-java-serialized-object using a raw java.io.ObjectInputStream, without applying any ObjectInputFilter (VertxHttpHelper.deserializeJavaObjectFromStream and NettyHttpHelper.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.

Mitigation

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.

Credit

This issue was discovered by Venkatraman Kumar from Securin

Notes

The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23324 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/22613 (commit e735f56b4bcae040a6a113a83bf08d41b8696c43, released in 4.20.0) and backported to camel-4.18.x (commit a3835afef108fef9eaf04165faed91784889407f, PR #22637) and camel-4.14.x (commit 04019cf90a4b09e263d2df4ad4cacea85a9d72ee, PR #22768). Exploitation requires the non-default option transferException=true (or allowJavaSerializedObject=true) together with an attacker-controlled backend; applications using the default configuration are not affected. The reporter assessed the issue as CWE-502 (Deserialization of Untrusted Data). It belongs to the same Camel deserialization-hardening family as CVE-2026-40858 and CVE-2026-42527, and follows the class of vulnerability previously addressed in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747.

References

CVE-2026-40859.txt.asc — PGP signed advisory data cve.org/CVERecord?id=CVE-2026-40859