CVE-2026-42586

Summary

Security Vulnerability Report: CRLF Injection in Netty Redis Codec Encoder Vulnerability Summary | Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions with codec-redis) | | Component | io.netty.handler.codec.redis.RedisEncoder | | Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences (CRLF Injection) | | Impact | Redis Command Injection / Response Poisoning | | Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | None | | User Interaction | None | | Scope | Unchanged | | Confidentiality Impact | High | | Integrity Impact | High | | Availability Impact | None | Affected Components The following classes in the codec-redis module are affected: io.netty.handler.codec.redis.RedisEncoder (encoder - no output validation) io.netty.handler.codec.redis.InlineCommandRedisMessage (no input validation) io.netty.handler.codec.redis.SimpleStringRedisMessage (no input validation) io.netty.handler.codec.redis.ErrorRedisMessage (no input validation) io.netty.handler.codec.redis.AbstractStringRedisMessage (base class - no validation) Vulnerability Description The Netty Redis codec encoder (RedisEncoder) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (\r\n) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses. Root Cause In RedisEncoder.java, the writeString() method (lines 103-111) writes content using ByteBufUtil.writeUtf8() without any validation: The message constructors (InlineCommandRedisMessage, SimpleStringRedisMessage, ErrorRedisMessage) inherit from AbstractStringRedisMessage, which only checks for null: Comparison with Similar Fixed CVEs This vulnerability follows the exact same pattern as two previously acknowledged Netty CVEs: | CVE | Component | Fix | |-----|-----------|-----| | GHSA-jq43-27x9-3v86 | SmtpRequestEncoder - SMTP command injection | Added SmtpUtils.validateSMTPParameters() to check for \r and \n | | GHSA-84h7-rjj3-6jx4 | HttpRequestEncoder - CRLF in URI | Added HttpUtil.validateRequestLineTokens() to check for \r, \n, and SP | The Redis codec has no equivalent validation in either the encoder or the message constructors. Exploitability Prerequisites This vulnerability is exploitable when all of the following conditions are met: The application uses Netty's codec-redis module to communicate with a Redis server User-controlled input is placed into InlineCommandRedisMessage, SimpleStringRedisMessage, or ErrorRedisMessage content The application does not perform its own CRLF sanitization before constructing these message objects Important context: Most production Redis clients built on Netty use the RESP array format (ArrayRedisMessage + BulkStringRedisMessage), which uses binary-safe length-prefixed encoding and is not affected by this vulnerability. The vulnerability specifically affects the text-based inline command mode and simple string/error response types, which use CRLF as protocol delimiters. Affected use cases include: Custom Redis clients or proxies that use InlineCommandRedisMessage for simplicity Redis middleware/proxy layers that forward SimpleStringRedisMessage or ErrorRedisMessage responses Applications that construct Redis monitoring or diagnostic commands from user input Redis Sentinel or Cluster management tools using inline command format Attack Scenarios Scenario 1: Redis Command Injection via Inline Commands When Netty is used as a Redis client or proxy, and user-controlled data is placed into InlineCommandRedisMessage, an attacker can inject arbitrary Redis commands: Attack input: key = "foo\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL" Result: Three commands sent to Redis: GET foo CONFIG SET requirepass "" (removes authentication!) FLUSHALL (deletes all data!) Scenario 2: Redis Response Poisoning When Netty is used as a Redis proxy/middleware, a malicious upstream Redis server (or MITM attacker) can inject fake responses: Malicious upstream response: "OK\r\n$6\r\nhacked" Client sees: Simple String: +OK (expected response) Bulk String: $6\r\nhacked (injected fake data!) Scenario 3: Error Message Injection Attack input: errorDetail = "unknown\r\n+FAKESUCCESS" Client sees: Error: -ERR unknown Simple String: +FAKESUCCESS (injected fake success!) Proof of Concept Full Runnable PoC Source Code (RedisEncoderCRLFInjectionPoC.java) How to Compile and Run PoC Execution Output (Verified on Netty 4.2.12.Final) Impact Analysis | Impact Category | Description | |----------------|-------------| | Confidentiality | HIGH - Attacker can execute CONFIG GET to extract sensitive Redis configuration, use KEYS * to enumerate all data | | Integrity | HIGH - Attacker can execute SET/DEL/FLUSHALL to modify or destroy data, CONFIG SET to change server configuration | | Availability | Can be HIGH - FLUSHALL destroys all data, SHUTDOWN stops the server, DEBUG SLEEP causes DoS | | Authentication Bypass | CONFIG SET requirepass "" removes authentication | | Data Exfiltration | Lua scripting via EVAL enables complex data extraction | Remediation Recommendations Option 1: Validate in Message Constructors (Recommended) Add CRLF validation to AbstractStringRedisMessage: Option 2: Validate in Encoder (Defense-in-Depth) Add validation in RedisEncoder.writeString(): Option 3: Both (Best Practice) Apply validation in both the constructor and the encoder, following the pattern used for SMTP: SmtpUtils.validateSMTPParameters() validates in DefaultSmtpRequest constructor This provides defense-in-depth against custom SmtpRequest implementations Resources RESP Protocol Specification CWE-93: Improper Neutralization of CRLF Sequences GHSA-jq43-27x9-3v86: Netty SMTP Command Injection GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection

Impact

Affected versions

Security releases

Remediation advice