Описание
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.
A flaw was found in the camel-vertx-http component of Apache Camel. This vulnerability, a Deserialization of Untrusted Data, could allow a remote attacker to execute arbitrary code. By controlling the backend server or acting as a man-in-the-middle, an attacker could send a specially crafted serialized Java object. If the producer endpoint is configured to transfer exceptions, this could lead to remote code execution on the affected Camel application.
Отчет
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 an attacker controlling the backend service or performing a man-in-the-middle attack on an unencrypted connection.
Меры по смягчению последствий
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.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat build of Apache Camel 4 for Quarkus 3 | camel-vertx-http | Affected | ||
| Red Hat build of Apache Camel for Spring Boot 4 | camel-vertx-http | Affected | ||
| Red Hat JBoss Enterprise Application Platform Expansion Pack | camel-vertx-http | Not affected | ||
| Red Hat Build of Apache Camel 4.18 for Quarkus 3.33 | camel-vertx-http | Fixed | RHSA-2026:48118 | 30.07.2026 |
Показывать по
Дополнительная информация
Статус:
8.1 High
CVSS3
Связанные уязвимости
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
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 ...
8.1 High
CVSS3