Venkatraman Kumar

#2253of 56,330
112.1Total CVSS
Vulnerabilities · 13
Medium
1
High
7
Critical
5
PT-2026-55882
8.1
2026-07-06
Apache · Apache Camel · CVE-2026-40859
**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.19.9 **Description** The `camel-vertx-http` component deserializes HTTP response bodies with the `application/x-java-serialized-object` Content-Type using a raw `java.io.ObjectInputStream` without an `ObjectInputFilter` in the `deserializeJavaObjectFromStream()` function. This occurs when the producer endpoint is configured with `transferException=true` (or `allowJavaSerializedObject=true`) and `throwExceptionOnFailure` is set to true. In these conditions, a backend HTTP response with a 5xx status and the specified content type is deserialized without class restrictions. An attacker controlling the backend or performing a man-in-the-middle attack on an unencrypted HTTP connection can send a crafted serialized Java object to achieve remote code execution on the host, provided a suitable gadget chain exists on the classpath. **Recommendations** Upgrade to version 4.14.8 for those on the 4.14.x LTS stream. Upgrade to version 4.18.3 for those on the 4.18.x stream. Upgrade to version 4.20.0. Do not enable `transferException=true` or `allowJavaSerializedObject=true` on producers communicating with untrusted or network-reachable backends. Ensure producer connections use TLS (https) to prevent man-in-the-middle response substitution. Set an explicit `-Djdk.serialFilter` allow-list to constrain deserialization.
PT-2026-55883
8.1
2026-07-06
Apache · Apache Activemq Artemis · CVE-2026-42527
**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.14.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** An issue exists where the default ObjectInputFilter pattern used for deserialization filtering in several components allows classes that perform network I/O, such as `java.net.URL` and `java.net.InetAddress`. An attacker can send a Java-serialized payload containing a `HashMap` with `java.net.URL` keys to an affected consumer. This triggers the JVM to issue DNS queries to an attacker-controlled host during deserialization, creating an out-of-band side channel. The risk is most significant in the `camel-jms` family because the `extractBodyFromJms()` function in `JmsBinding` unconditionally invokes `getObject()` when the `mapJmsMessage` variable is set to true. Affected components include `camel-jms`, `camel-sjms`, `camel-amqp`, `camel-mina`, `camel-netty`, `camel-netty-http`, `camel-vertx-http`, `camel-infinispan`, and aggregation repository components `camel-leveldb`, `camel-cassandraql`, `camel-consul`, and `camel-sql`. **Recommendations** Update Apache Camel versions 4.14.0 through 4.14.7 to version 4.14.8. Update Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Update Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. Configure a JMS-provider-side allow-list using `deserializationAllowList` or `deserializationDenyList` in Apache ActiveMQ Artemis, or `org.apache.activemq.SERIALIZABLE PACKAGES` in Apache ActiveMQ Classic. Override the default filter via the `deserializationFilter` option at the endpoint level or the `-Djdk.serialFilter` JVM system property using the pattern `!java.net.**;java.**;javax.**;org.apache.camel.**;!*` (or `!java.net.**;java.**;org.apache.camel.**;!*` for aggregation-repository components).