Discovering a Netty Zero-Day

Part of my job involves evaluating and improving our security AI agents against a variety of codebases. When the agent flagged a vulnerability in Netty I was surprised. Netty is a library used everywhere in the Java ecosystem and is adopted by leading technology companies like Apple, Meta, and Google. Our agents discovered the vulnerability, provided a risk assessment, and generated a patch autonomously. I shared the results with the Netty maintainers who assigned CVE-2025-59419 and merged our fix.

‍

Our security agent found a business logic flaw in how Netty handled one of the internet's oldest and most trusted protocols. To understand the vulnerability, we need to take a quick journey back to the humble beginnings of email.

‍

Technical Root Cause: SMTP Command Injection

Email is built on the Simple Mail Transfer Protocol, SMTP. SMTP is a text-based conversation between a client and a server. The client issues SMTP commands to build the email. Each command ends with \r\n. To set the email’s sender, the client sends MAIL FROM:<sender@example.com>\r\n. To set the receiver, the client sends RCPT TO:<receiver@example.com>\r\n. Other SMTP commands set the email’s content and additional data.

‍

The vulnerability existed because Netty’s SMTP codec allowed \r\n in user input. This could be exploited when Netty creates an SMTP command with user data. Imagine company.com uses Netty to send alerts to user-configured emails.

‍

In this scenario, users would control the recipient variable in Netty (github):

DefaultSmtpRequest(SmtpCommand.RCPT, "TO:<" + recipient + '>')

‍

Netty uses the recipient variable directly to build the SMTP command (github):

RCPT TO:<user@example.com>\r\n

‍

However, an attacker can use \r\n into their email to inject their own SMTP command “inside” the RCPT command. Setting the recipient to anyone@anywhere.com\r\nFROM: <ceo@example.com>\r\n creates:

RCPT TO: <anyone@anywhere.com>\r\n
FROM: <ceo@example.com>\r\n

‍

The receiving server will read this as two separate commands. It has no idea it’s being manipulated. It will send an email to anyone@anywhere.com from ceo@example.com. The attacker can inject more SMTP commands to control the email content and even send multiple emails.

‍

Impact: Bypassing Email Trust

As a security professional, you learn to trust a few ground truths. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and DMARC are the bedrock of email security. So my first thought was, "Surely those defenses would catch this."

‍

The sinking feeling came when I realized this vulnerability sidesteps them all.

‍

• SPF (Sender Policy Framework): Checks that an email is coming from an IP address authorized to send mail for that domain. The attack passes because the injected email is sent from the company's own, trusted server.

• DKIM (DomainKeys Identified Mail): Adds a digital signature to the email, proving it hasn't been tampered with in transit. The attack passes because the forged email is constructed on the server before DKIM signing happens.

• DMARC (Domain-based Message Authentication, Reporting & Conformance): enforces SPF and DKIM. When those foundations crumble, DMARC goes down with them.

‍

This is what makes the flaw so dangerous. It allows an attacker to craft an email that passes every technical defense. This enables high-stakes attacks like Business Email Compromise (BEC) and hyper-realistic phishing. Imagine an attacker using this flaw to send an email from your CFO to the accounting department, instructing them to wire funds to a new account. The defensive security mechanisms are bypassed and the remaining defense is a skeptical human.

‍

Disclosure: Automated Fix and Community Conversation

‍

After our agent discovered the flaw and automatically generated a full patch, I reported the issue to the Netty maintainers. This started an important conversation: is validating input to SMTP commands Netty’s responsibility or that of developers using the library?

‍

Some maintainers' perspective is that Netty provides a low-level API and expects users to perform their own input checks. The other maintainers’ perspective is that the library should enforce security.

‍

The discussion settled by following the precedent. Netty already has input validation for its HTTP codec that checks for illegal characters (like \r and \n) to prevent similar injection vulnerabilities. Another point is that other widely-used libraries, such as PHPMailer and Apache James, had fixed and assigned CVEs for similar SMTP injection flaws.

‍

The maintainers agreed to move forward with the fix, accepting our patch and requesting a CVE. It was a great outcome that speaks volumes to the collaborative strength of the Netty maintainers. And I was selfishly happy we got a CVE in Netty.

‍

Conclusion: My New Favorite Hacking Partner

There's a unique thrill in finding a zero-day. It's a feeling I know well, the adrenaline of the hunt, the quiet satisfaction of knowing you found a critical flaw others missed. For my entire career, it’s been a deeply human endeavor.

‍

It used to be.

‍

This time, I wasn't the one hunting for the bug. This discovery wasn't the result of weeks spent poring over source code. It was our AI agent, running silently on our own production systems, that found the vulnerability and handed me the fix.

‍

It’s a strange and humbling feeling. You realize the game has fundamentally changed. The hunt for vulnerabilities is no longer a manual process. The attack surface is too vast, our dependencies too deep. Software security has to be as autonomous and relentless as the software it’s sworn to protect.

‍