The vulnerability in Apache Camel’s camel-vertx-http component allows deserialization of untrusted Java objects received in HTTP responses. When the producer endpoint is set with transferException=true (or the component-level allowJavaSerializedObject=true) and throwExceptionOnFailure is left at its default true, a 5xx backend response bearing the application/x-java-serialized-object content type is deserialized with no class restrictions. This gives an attacker the ability to craft a malicious serialized payload and, if a compatible gadget chain is present on the server classpath, execute arbitrary code on the Camel host. The flaw falls under CWE‑502 – Deserialization of Untrusted Data.

Apache Camel 4.0.0 up to (but not including) 4.14.8, 4.15.0 up to (but not including) 4.18.3, and 4.19.0 up to (but not including) 4.20.0 are affected. Users running any of these vulnerable releases are at risk.

The attack path requires the attacker to control the backend system that the Camel producer communicates with, or to position a man‑in‑the‑middle on an unencrypted HTTP connection, and to supply a crafted Java object that will be deserialized. Because the flaw is only reachable when transferException or allowJavaSerializedObject is enabled and the default exception handling is active, it is not an arbitrary vulnerability; it demands precise configuration. Despite its high impact (remote code execution), the EPSS score is reported as less than 1 % and the issue is not yet listed in CISA’s KEV catalog, indicating that the likelihood of exploitation in the wild is currently low. Nonetheless, the potential damage warrants prompt remediation.