Apache Camel CVE-2026-78165

Applies only when the camel-spring-redis endpoint runs with no explicit serializer option set, so the component lazily builds a bare JdkSerializationRedisSerializer with no java.io.ObjectInputFilter installed. On the consumer side the attacker must be able to PUBLISH to a channel the route subscribes to; on the producer side (GET/HGET/HGETALL/HVALS) and in SpringRedisIdempotentRepository the attacker must be able to write attacker-controlled bytes into the read keyspace. Exploitation further requires a viable deserialization gadget on the application classpath. Key limiting factors: a Redis instance that enforces authentication, restricts which clients may publish, and is not exposed to untrusted networks substantially reduces exposure. Critically, wiring a String serializer into a custom redisTemplate does NOT mitigate the consumer path - RedisConsumer.setBody reads getSerializer directly - so only the serializer endpoint option, the jdk.serialFilter JVM property, or upgrading closes it.

This is a genuine high-priority issue, not a CVSS-inflated one. The vendor-supplied CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) is internally consistent with the technical description: an unfiltered Java deserialization sink (CWE-502) reachable over the network with low attack complexity and no user interaction, yielding full confidentiality, integrity and availability impact - i.e. remote code execution on the Camel JVM. The PR:L metric aligns with the description's prerequisite that an attacker be 'able to issue PUBLISH on a subscribed channel' (or write to the read keyspace), implying some level of access to the Redis instance rather than fully anonymous internet exploitation. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation is currently theoretical/unproven in the wild despite the dangerous primitive. The practical risk hinges heavily on deployment exposure: a Redis instance reachable by untrusted clients (no auth, exposed to untrusted networks) combined with a deserialization gadget on the Camel classpath makes this readily exploitable, whereas an authenticated, network-restricted Redis sharply narrows the attack surface. Net: treat as a real priority for anyone running the camel-spring-redis component with the default serializer, but note the exploitation-signal data (EPSS/KEV/POC) is absent and risk is conditional on Redis exposure.

An attacker who can publish messages to a Redis channel that a Camel route subscribes to crafts a serialized Java object graph built from a gadget chain present on the application's classpath and issues a PUBLISH to that channel. RedisConsumer.setBody feeds the raw bytes straight into the default JdkSerializationRedisSerializer before any route logic runs, so readObject executes the gadget and runs arbitrary code in the Camel JVM. No public exploit code was identified at time of analysis, and exploitation also requires a usable deserialization gadget to be available on the classpath.