REDHAT-BUG-2536968: Command Injection
Netty netty-codec-smtp — SMTP command-name field is not CRLF-validated (incomplete fix of CVE-2025-59419)
A public GitHub Security Advisory (GHSA-5vh9-c45f-rf7p) describes the following issue:
Summary
CVE-2025-59419 (GHSA-jq43-27x9-3v86) added SmtpUtils.validateSMTPParameters to reject CR/LF in SMTP request parameters and wired it into DefaultSmtpRequest's parameter paths. The fix does not validate the SMTP command name: SmtpCommand.valueOf(CharSequence) performs no validation, and SmtpRequestEncoder writes the command verbatim. So CR/LF embedded in the command-name field injects whole SMTP commands onto the wire — the same CRLF/command-injection class the fix set out to close, on a field the fix did not cover.
Empirically (run-log), against the released netty-codec-smtp.14.Final: a CRLF-in-recipient request is correctly rejected (parameter path fixed), but new DefaultSmtpRequest(SmtpCommand.valueOf("NOOP\r\nMAIL FROM:<…>\r\nRCPT TO:<…>\r\nDATA")) encodes to four CRLF-separated SMTP commands on the wire.
Anchor (netty/netty HEAD e067b6e; released netty-codec-smtp.14.Final)
- Validation is parameter-only — DefaultSmtpRequest.java:46 and :59 call SmtpUtils.validateSMTPParameters(parameters); the command is taken as-is (:37/:45/:58 checkNotNull(command) — no CRLF check). - SmtpCommand.java:66 valueOf(CharSequence) → :69 new SmtpCommand(AsciiString.of(commandName)) — no validation. - SmtpRequestEncoder writes the command name verbatim (ByteBufUtil.writeAscii), so embedded CR/LF passes to the wire. - Public entrypoints DefaultSmtpRequest(CharSequence command, …) (:53) and SmtpCommand.valueOf(...) route straight through.
Root cause
This is an incomplete fix of CVE-2025-59419 (CWE-93, CRLF injection). The 4.1.128/4.2.7 patch was expected to neutralize CR/LF in SMTP requests, but it only validates request parameters; the command-name field is unvalidated end-to-end. Encoding a request whose command name carries embedded CR/LF emits four injected SMTP commands on the wire (run-log). The gap exists because the original reporter's PoC and the patch both framed the bug as a parameter (recipient) problem — the command name was outside the fix's threat model, and SmtpRequestEncoder performs no validation of its own when writing the command.
Threat model — and honest severity
CRLF/command injection into the SMTP byte stream enables SMTP command smuggling (forged MAIL FROM/RCPT TO, unauthorized relay/spoofing) when the application routes untrusted input into the SMTP command-name field.
Honest caveat (this is the load-bearing limitation): applications normally place user-controlled data in SMTP parameters (recipient/sender addresses) — which the parent CVE now validates — not in the command name, which is usually a fixed verb. So real-world reachability of the command-name axis is lower than the parameter axis the CVE fixed; this is best characterised as a fix-completeness / defense-in-depth gap in a flagship library rather than a high-reachability heavy-hitter.
CVSS v3.1
6.5 Medium — honestly rated. The injection impact, when reached, is integrity-affecting command smuggling (the I:H vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N = 7.5); it is down-rated here to 6.5 to reflect the narrow reachability (untrusted data in the command-name field is an uncommon application pattern versus the parameter path the parent CVE closed). Reported as the completeness sibling of CVE-2025-59419.
Recommended fix
Validate the command name for CR/LF the same way parameters are validated — either in SmtpCommand.valueOf / the SmtpCommand(AsciiString) constructor, or in SmtpRequestEncoder before writing the command:
java // in SmtpCommand.valueOf / constructor, or SmtpRequestEncoder.encode: SmtpUtils.validateSMTPParameters(java.util.Collections.singletonList(commandName));
Cross-references
- Parent: CVE-2025-59419 / GHSA-jq43-27x9-3v86, fix commits 1782e8c2…, 2b3fddd3… (added SmtpUtils.validateSMTPParameters, parameters only).
CNA / submission target
GHSA private advisory on netty/netty (Netty maintainers / io.netty CNA).
Repro
poc/run.sh downloads the released Netty 4.2.14.Final jars, compiles poc/SmtpInjectionPoc.java, and runs the production SmtpRequestEncoder in an EmbeddedChannel. Captured run log: poc/run-log-2026-06-02.txt (exit 0).
- Control — CRLF in a recipient parameter (SmtpRequests.rcpt): throws IllegalArgumentException (parameter path is fixed). - Bug — DefaultSmtpRequest(SmtpCommand.valueOf("NOOP\r\n…\r\nDATA")): encodes 4 CRLF-separated SMTP commands onto the wire (smuggled MAIL FROM + RCPT TO present).
Affected: - maven:io.netty:netty-codec-smtp affected >=4.2.0.Final,<= 4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-smtp affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-5vh9-c45f-rf7p
Affected Software
Event History
Frequently Asked Questions
What input must an attacker control to exploit this issue?
The attacker must be able to supply or influence the SMTP command-name field used to construct an SmtpCommand, such as through SmtpCommand.valueOf(CharSequence). CR and LF characters in that field are written verbatim by SmtpRequestEncoder, allowing additional SMTP commands to be injected.
Are SMTP request parameters protected by the earlier fix?
Yes. The earlier CVE-2025-59419 fix validates SMTP request parameters and rejects CR/LF in those parameter paths. This issue remains because the SMTP command name is not covered by that validation.
How can I determine whether an application is exposed?
Review whether the application creates SMTP commands from non-constant or externally influenced CharSequence values using SmtpCommand.valueOf. A vulnerable flow can encode a command name containing CR/LF into multiple CRLF-separated SMTP commands on the wire.