CVE-2025-59419: Netty SMTP Codec RCE Vulnerability

CVE-2025-59419 Overview

CVE-2025-59419 is an SMTP command injection vulnerability in Netty, an asynchronous, event-driven network application framework widely used in Java applications. The flaw resides in the SMTP codec component, specifically io.netty.handler.codec.smtp.DefaultSmtpRequest, where user-supplied parameters are concatenated into SMTP command strings without validation. Attackers who control SMTP parameters such as email recipients can inject Carriage Return (\r) and Line Feed (\n) sequences to issue arbitrary SMTP commands. Because injected commands originate from the trusted server's IP, forged emails pass SPF and DKIM authentication checks. The issue affects versions prior to 4.1.128.Final and 4.2.7.Final and is classified under [CWE-93] (Improper Neutralization of CRLF Sequences).

Critical Impact

Remote attackers can forge authenticated emails from trusted servers, enabling executive impersonation and fraudulent corporate communications that bypass SPF and DKIM checks.

Affected Products

• Netty versions prior to 4.1.128.Final
• Netty versions prior to 4.2.7.Final
• Java applications using io.netty.handler.codec.smtp for SMTP client functionality

Discovery Timeline

• 2025-10-15 - CVE-2025-59419 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-59419

Vulnerability Analysis

The vulnerability resides in Netty's SMTP codec, which constructs outbound SMTP commands by concatenating caller-supplied parameters directly into the protocol stream. The DefaultSmtpRequest constructor accepts parameters as CharSequence values and stores them without inspecting their contents. Helper methods such as SmtpRequests.rcpt(recipient) forward attacker-controlled input straight to the codec.

When serialized, the codec terminates each command with CRLF (\r\n). If a parameter already contains CRLF, the codec emits multiple commands in a single request. Attackers exploit this confusion to append commands such as MAIL FROM, RCPT TO, and DATA after a legitimate command, producing fully crafted messages on the wire.

Because the SMTP session is already authenticated and originates from the trusted server's IP address, downstream relays accept the forged messages. Receiving mail servers evaluate SPF and DKIM against the legitimate sending infrastructure, so the spoofed messages pass authentication.

Root Cause

The root cause is missing neutralization of CRLF characters in SMTP parameters. The pre-patch DefaultSmtpRequest constructor stored parameters without calling any validator, allowing protocol metacharacters to flow into the wire format.

Attack Vector

Exploitation requires an application that passes externally controlled input (for example, an email recipient field from a web form) into Netty's SMTP request helpers. The attacker submits a recipient string containing CRLF followed by additional SMTP verbs, which the codec then transmits over the authenticated session.

// Security patch in DefaultSmtpRequest.java
public DefaultSmtpRequest(SmtpCommand command, CharSequence... parameters) {
    this.command = ObjectUtil.checkNotNull(command, "command");
    SmtpUtils.validateSMTPParameters(parameters);
    this.parameters = SmtpUtils.toUnmodifiableList(parameters);
}

// New validator in SmtpUtils.java
/**
 * Validates SMTP parameters to prevent SMTP command injection.
 * Throws IllegalArgumentException if any parameter contains CRLF sequences.
 */
static void validateSMTPParameters(CharSequence... parameters) {
    if (parameters != null) {
        for (CharSequence parameter : parameters) {
            if (parameter != null) {
                validateSMTPParameter(parameter);
            }
        }
    }
}

Source: Netty Security Patch Commit

Detection Methods for CVE-2025-59419

Indicators of Compromise

• Outbound SMTP traffic from application servers containing multiple MAIL FROM or RCPT TO verbs within a single client request.
• Application logs showing recipient or sender fields containing raw \r or \n characters.
• Unexpected DATA payloads in SMTP sessions originating from Netty-based services that authenticate against corporate relays.

Detection Strategies

• Inspect dependency manifests (pom.xml, build.gradle) across Java projects for Netty versions below 4.1.128.Final or 4.2.7.Final.
• Add runtime input validation to reject CRLF in user-supplied SMTP parameters even when callers do not yet validate input.
• Correlate egress SMTP logs with web application request logs to flag recipient fields containing encoded CRLF (%0d%0a).

Monitoring Recommendations

• Monitor mail relay logs for messages from internal services where the envelope sender differs from the application's expected identity.
• Alert on Software Composition Analysis (SCA) findings tagged with GHSA-jq43-27x9-3v86.
• Track outbound SMTP command rates per session, since injection often produces an abnormal number of commands per logical email.

How to Mitigate CVE-2025-59419

Immediate Actions Required

• Upgrade Netty to 4.1.129.Final or 4.2.8.Final, which include SmtpUtils.validateSMTPParameters invocation in the request constructor.
• Audit application code that calls SmtpRequests.rcpt, SmtpRequests.mail, or constructs DefaultSmtpRequest directly with user-influenced input.
• Add server-side validation that strips or rejects CRLF in email recipient, sender, and subject fields before passing to Netty.

Patch Information

The Netty project published the fix in the GitHub Security Advisory GHSA-jq43-27x9-3v86 and the corresponding Netty patch commit. The patch adds validateSMTPParameters calls in DefaultSmtpRequest to throw IllegalArgumentException when CRLF sequences are present.

Workarounds

• No vendor-supplied workaround exists. Upgrading to a patched version is required.
• As a compensating control, applications can wrap calls to SmtpRequests with a pre-validation layer that rejects any parameter containing \r or \n.
• Restrict the set of email recipients to a server-side allowlist where feasible to limit attacker control over SMTP parameters.

# Maven dependency upgrade example
mvn versions:use-dep-version -Dincludes=io.netty:netty-codec-smtp -DdepVersion=4.1.129.Final -DforceVersion=true

# Gradle dependency override example
# In build.gradle:
# implementation('io.netty:netty-codec-smtp:4.1.129.Final')