CVE-2026-93576: Io.netty/netty-codec-smtp: netty netty-codec-smtp — smtp command-name field is not crlf-validated (incomplete fix of cve-2025-59419)

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

— Red Hat