CVE-2026-78165

Apache Camel is behind-the-scenes software many businesses use to connect different systems together, and one of its building blocks talks to a database called Redis. This flaw is like a mailroom that opens and executes any sealed package handed to it without checking what's inside — if someone can drop a malicious 'package' into the right mail slot (a Redis channel), the software will run it, potentially handing them control of your application.

This matters to you if your business runs an application built with Apache Camel that uses the Spring Redis component to read or write messages via Redis. It's a risk if that Redis instance (or the channels it subscribes to) can be reached by anyone outside your trusted network, including by other systems or users who shouldn't normally have access.

This is a serious weakness — a successful attack hands over control of the application — but there's no evidence yet of active exploitation in the wild and no public exploit code circulating. It deserves prompt attention and planning to patch, but it is not an emergency requiring an immediate outage-risking fix tonight.

Confirm exposure by checking whether camel-spring-redis is on your classpath and whether a serializer option is explicitly configured on the Redis endpoint (the vulnerable default is JdkSerializationRedisSerializer). Note that setting a custom redisTemplate with a safe serializer does NOT close the consumer-side exposure — RedisConsumer.setBody reads the component's serializer option directly, not the template's serializer, so you must set the serializer endpoint option itself. Target fixed versions per branch: 4.18.5 for the 4.18.x stream, 4.22.1 for 4.22.x, and 4.23.0 for current/latest. The 4.14.x and earlier streams are end-of-life and will not receive a fix — migrate off them entirely. As a temporary workaround while patching is scheduled, set the serializer endpoint option to StringRedisSerializer (or another non-Java serializer), and/or apply a JVM-wide jdk.serialFilter such as -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* since the vulnerable ObjectInputStream path honours this filter. As defence in depth, require Redis authentication and restrict which clients can PUBLISH to subscribed channels or write to keys read via GET/HGET/HGETALL/HVALS, and never expose the Redis instance to untrusted networks. Monitor for upgrade availability notices and watch for any future KEV listing or public PoC, which would elevate urgency.

CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:H) reflects network-reachable, low-complexity exploitation requiring only limited privileges (ability to publish to a Redis channel or write Redis keys) and no user interaction, with full confidentiality/integrity/availability impact. Weakness is CWE-502 (Deserialization of Untrusted Data): RedisConsumer.setBody and RedisConfiguration.createDefaultTemplate both default to JdkSerializationRedisSerializer, which delegates through Spring's DeserializingConverter/DefaultDeserializer to a ConfigurableObjectInputStream with no ObjectInputFilter installed, allowing arbitrary class graph materialization and readObject execution on untrusted bytes from Redis PUBLISH messages or GET/HGET/HGETALL/HVALS results. Not listed in CISA KEV; no public exploit code on record; EPSS indicates low predicted near-term exploitation likelihood with a flat trend. Press attention is rising, but this reflects disclosure coverage, not confirmed in-the-wild activity. Fix available across all actively supported branches (4.18.5, 4.22.1, 4.23.0); 4.14.x and earlier are EOL and unpatched. Workarounds include setting jdk.serialFilter (honoured because the code path uses ObjectInputStream) or switching the serializer endpoint option to a non-Java serializer like StringRedisSerializer.