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