CVE-2026-78165

Description

A flaw was found in Apache Camel's camel-spring-redis component. By default, the component relies on an unfiltered Java deserializer to process messages received from Redis channels or stored keys. An attacker with permission to publish messages or write data to the Redis instance can exploit this issue by supplying a crafted serialized payload, potentially leading to arbitrary code execution.

Statement

This vulnerability is rated as an Important severity impact because successful exploitation can lead to arbitrary code execution within the context of the running application process. Although network-accessible without user interaction, exploitation requires an attacker to possess network reachability and sufficient authorization to write data or publish messages directly to the underlying Redis instance monitored by the application. Consequently, deployments where the Redis instance is strictly isolated and access-controlled face reduced practical risk.

Mitigation

--- CME Mitigation Guidance (2026-10-20) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.

The highest-value action is to eliminate unfiltered Java deserialization across camel-spring-redis consumers, producer reads, and idempotent repositories by enforcing ObjectInputFilter validation or configuring non-Java serializers: upgrade to Apache Camel 4.18.5, 4.22.1, or 4.23.0 (or the fixed Camel Spring Redis builds), which enforce an ObjectInputFilter using a custom FilteringDeserializer and configurable deserialization filter options during deserialization, closing all 3 injection vectors (publishing crafted serialized Java payloads to subscribed Redis channels, writing crafted serialized Java payloads to Redis keys read by producer commands, populating crafted serialized Java payloads in keys queried by SpringRedisIdempotentRepository). Until patched, this is a concern on deployments running Camel Spring Redis routes without a custom non-Java serializer option, so set the JVM-wide jdk.serialFilter property, configure the endpoint serializer option to a non-Java serializer such as StringRedisSerializer, and enforce authentication while restricting network write and publish access to Redis. As a compensating measure, deploy EDR agents to detect anomalous process execution and malicious payload activity spawned from the Java process following deserialization and configure Falco or eBPF runtime security monitoring to detect unexpected shell executions or outbound network connections originating from the Camel application. These controls limit blast radius and contain exploitation, but they do not fix the underlying untrusted Java deserialization defect — apply the upstream patch to fully remediate.

Highest-impact CME: CME-1302 Deserialization Allowlist (Safe Loading) (high)

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score8.8N/A8.8
Attack VectorNetworkN/ANetwork
Attack ComplexityLowN/ALow
Privileges RequiredLowN/ALow
User InteractionNoneN/ANone
ScopeUnchangedN/AUnchanged
ConfidentialityHighN/AHigh
Integrity ImpactHighN/AHigh
Availability ImpactHighN/AHigh

Vector

Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Understanding the Weakness (CWE)

Integrity

Technical Impact: Modify Application Data; Unexpected State

Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.

Availability

Technical Impact: DoS: Resource Consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.

Other

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.

Frequently Asked Questions

Want to get errata notifications? Sign up here.