CVE-2023-42809: Redisson Java Client RCE Vulnerability

CVE-2023-42809 Overview

CVE-2023-42809 is an insecure deserialization vulnerability in Redisson, a popular Java Redis client that uses the Netty framework. Prior to version 3.22.0, Redisson deserializes Java objects received from Redis servers without proper validation, allowing attackers who can intercept or manipulate Redis communications to execute arbitrary code on client machines.

Critical Impact

Attackers who trick clients into communicating with a malicious Redis server can include specially crafted objects that, once deserialized, force the client to execute arbitrary code, potentially leading to complete system compromise.

Affected Products

• Redisson versions prior to 3.22.0
• Applications using Kryo5Codec as deserialization codec (remains vulnerable post-fix)
• Applications using SerializationCodec without allowlist configuration

Discovery Timeline

• 2023-10-04 - CVE-2023-42809 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-42809

Vulnerability Analysis

This vulnerability stems from unsafe deserialization practices in the Redisson Java Redis client. When Redisson receives messages from a Redis server, it deserializes Java objects embedded in these responses without performing adequate validation or restricting which classes can be instantiated during the deserialization process.

Insecure deserialization vulnerabilities (CWE-502) are particularly dangerous in Java applications because the deserialization process can trigger code execution through gadget chains—sequences of existing classes in the application's classpath that, when combined during deserialization, lead to arbitrary code execution. This attack requires no authentication and can be executed remotely when an attacker can position themselves as a malicious Redis server or perform a man-in-the-middle attack on Redis communications.

The fix introduces an allowlist mechanism for SerializationCodec that restricts which classes can be deserialized. However, it's critical to note that Kryo5Codec remains vulnerable due to its setRegistrationRequired(false) configuration, while KryoCodec is considered safe to use.

Root Cause

The root cause is the lack of class validation during Java object deserialization. The Redisson client trusted all incoming serialized objects from Redis servers and would instantiate any class present in the serialized data stream. This violates the security principle of never trusting untrusted input, especially when that input can control object instantiation.

Attack Vector

The attack requires an adversary to position themselves between the Redisson client and a legitimate Redis server, or to trick the client into connecting to a malicious server entirely. Once this is achieved, the attacker can craft malicious serialized Java objects and include them in Redis responses. When the vulnerable Redisson client deserializes these objects, it executes attacker-controlled code.

The security patch introduces an allowedClasses parameter to restrict deserialization:

*/
package org.redisson.codec;

-import java.io.IOException;
-import java.io.InputStream;
-import java.io.ObjectInputStream;
-import java.io.ObjectStreamClass;
+import java.io.*;
import java.lang.reflect.Proxy;
import java.util.ArrayList;
import java.util.List;
+import java.util.Set;

/**
 *

Source: GitHub Commit

The corresponding changes in SerializationCodec.java add the allowlist functionality:

*/
package org.redisson.codec;

-import java.io.IOException;
-import java.io.ObjectInputStream;
-import java.io.ObjectOutputStream;
-
+import io.netty.buffer.ByteBuf;
+import io.netty.buffer.ByteBufAllocator;
+import io.netty.buffer.ByteBufInputStream;
+import io.netty.buffer.ByteBufOutputStream;
import org.redisson.client.codec.BaseCodec;
import org.redisson.client.handler.State;
import org.redisson.client.protocol.Decoder;
import org.redisson.client.protocol.Encoder;

-import io.netty.buffer.ByteBuf;
-import io.netty.buffer.ByteBufAllocator;
-import io.netty.buffer.ByteBufInputStream;
-import io.netty.buffer.ByteBufOutputStream;
+import java.io.IOException;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.util.Set;

/**
 * JDK's serialization codec.

Source: GitHub Commit

Detection Methods for CVE-2023-42809

Indicators of Compromise

• Unexpected outbound connections from application servers to unknown Redis endpoints
• Unusual process spawning from Java applications using Redisson
• Network traffic to Redis ports (default 6379) containing suspicious serialized Java objects
• Log entries indicating deserialization errors or unexpected class loading

Detection Strategies

• Monitor Java application logs for ObjectInputStream exceptions or unusual class instantiation patterns
• Implement network monitoring to detect Redis traffic to unauthorized endpoints
• Use Java security managers or deserialization filters to log and block suspicious class loading
• Deploy application-level monitoring for unexpected system command execution originating from Java processes

Monitoring Recommendations

• Enable verbose logging for Redisson client connections and codec operations
• Implement network segmentation monitoring between application servers and Redis infrastructure
• Configure intrusion detection systems to alert on Redis protocol anomalies
• Monitor for known deserialization gadget chain class names in network traffic

How to Mitigate CVE-2023-42809

Immediate Actions Required

• Upgrade Redisson to version 3.22.0 or later immediately
• Audit existing codebase for usage of Kryo5Codec and migrate to KryoCodec
• Configure SerializationCodec with explicit allowlists using the constructor SerializationCodec(ClassLoader classLoader, Set<String> allowedClasses)
• Ensure Redis server communications occur over trusted, encrypted channels

Patch Information

The vulnerability is addressed in Redisson version 3.22.0. The patch adds an optional allowlist mechanism to SerializationCodec through the allowedClasses parameter. Security researchers recommend making the allowlist behavior the default. The fix is available in the GitHub commit fe6a2571801656ff1599ef87bdee20f519a5d1fe.

For additional technical details, refer to the GitHub Security Advisory GHSL-2023-053.

Workarounds

• Do NOT use Kryo5Codec as it remains vulnerable even after the patch
• Use KryoCodec instead, which is safe for deserialization
• Implement network-level controls to ensure Redis connections only go to trusted servers
• Apply Java deserialization filters at the JVM level as an additional defense layer

# Example: Configuring Java deserialization filter (JEP 290)
# Add to JVM startup arguments
java -Djdk.serialFilter=!org.apache.commons.collections.*;!org.apache.xalan.* \
     -jar your-application.jar