AI agents found a Netty zero-day that bypassed email trust

At a glance

What this is: depthfirst reports a Netty zero-day, CVE-2025-59419, where SMTP command injection let user input alter email commands and bypass core mail trust checks.

Why it matters: For IAM and security teams, the case shows how trusted execution paths can be abused when input validation fails, a pattern that also matters for service identities and agentic workflows.

👉 Read depthfirst's analysis of the Netty zero-day and SMTP command injection

Context

SMTP command injection happens when untrusted input is inserted into a text-based mail command stream without sanitisation. In this case, the flaw mattered because the application built trusted email commands directly from user-controlled values, which turned a normal messaging function into a forgery path. The same control failure appears across identity and automation systems when runtime input is allowed to shape privileged actions.

This is not just an email issue. It shows how security tooling, autonomous analysis, and code generation can expose weaknesses in core libraries before defenders notice them manually. For identity programmes, the lesson is familiar: when a system signs, sends, or acts on behalf of a trusted entity, input handling becomes part of the trust model.

Key questions

Q: What breaks when untrusted input is allowed into SMTP commands?

A: The protocol stream can be split into multiple commands, so an attacker can change recipients, inject content, or send mail that appears to come from a trusted server. The failure is not just malformed syntax. It is the loss of the boundary between data and instruction, which turns a normal mail function into an abuse path.

Q: Why do SPF, DKIM, and DMARC not stop this kind of phishing?

A: They validate message authenticity signals, but they do not prove the communication is safe or legitimate in context. Attackers can still send technically valid emails that contain a phone number and rely on social engineering after the recipient calls. Identity and support workflows remain exposed even when mail authentication passes.

Q: How can security teams test for protocol injection in shared libraries?

A: Use negative testing and fuzzing around every point where user data becomes a protocol command or header. The goal is to prove that illegal control characters, separators, and reserved tokens are rejected before serialization. Teams should also include regression tests for known parsing edge cases so the same flaw cannot reappear in later releases.

Q: Who is responsible when a library flaw enables forged email?

A: Responsibility is shared. Library maintainers need secure defaults and input validation, while application teams must not pass untrusted values into privileged protocol builders. For regulated environments, the accountable control owner is the team that operates the mail flow, because they decide how trust boundaries are enforced in production.

Technical breakdown

How SMTP command injection breaks mail trust

SMTP is a line-oriented protocol, so carriage return and line feed characters define where one command ends and the next begins. If a library concatenates user input directly into an SMTP command, an attacker can append a new command inside the original one. The receiving server will parse the stream as valid protocol, not as an attack. That is why protocol grammar matters as much as authentication on the network edge.

Practical implication: Sanitise control characters before any SMTP command is constructed.

Why SPF, DKIM, and DMARC did not stop this flaw

SPF checks whether the sending IP is authorised for the domain, DKIM signs the message after it is constructed, and DMARC evaluates whether SPF and DKIM align. In this case, the forged message was created by the trusted server itself, so the mail passed through the normal trust stack. These controls verify origin and integrity, but they do not repair a compromised command-building path inside the application.

Practical implication: Treat mail-authentication controls as downstream checks, not protection against injection in application logic.

Why library-level validation matters in trusted APIs

Low-level libraries often expose flexible APIs so developers can compose protocol messages. That flexibility becomes risky when the library does not reject illegal control characters or reserved syntax before serialization. Netty already validates similar input in its HTTP codec, which shows the same principle applies across protocols: the library should fail closed when user data can alter message structure. The security boundary sits at the point where data becomes protocol.

Practical implication: Apply protocol-aware validation in shared libraries, not only in the application layer.

Threat narrative

Attacker objective: The attacker aims to send fraudulent mail that appears to originate from a trusted internal sender and can support phishing or business email compromise.

1. Entry occurred when attacker-controlled recipient input was passed into Netty's SMTP codec without filtering.
2. Escalation happened when the injected CRLF sequence created additional SMTP commands inside the original mail request.
3. Impact followed when the forged message could pass SPF, DKIM, and DMARC because it was generated by the trusted server itself.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol injection is a trust failure, not just a parsing bug. When untrusted data is allowed to shape a privileged protocol message, the application can mint attacker-intended actions that downstream controls still treat as legitimate. That is why the real failure is governance of the command boundary, not simply the absence of a filter. Practitioners should treat data-to-command transitions as security-sensitive interfaces.

AI-assisted discovery changes the economics of dependency review. A security agent finding a zero-day in a widely used library shows that code review at scale is now a machine-speed problem. That does not make the software itself autonomous, but it does change how vulnerabilities are found, triaged, and patched across software supply chains. Teams should expect more machine-assisted discovery of latent flaws in core dependencies.

Identity systems face the same hidden boundary risk. Whenever an identity, token, service account, or automated workflow is converted into a privileged action, the system needs explicit validation at the moment of translation. That is the same structural problem as SMTP injection: trusted output can be forged if input is not constrained. The lesson for IAM and NHI programmes is to govern the action boundary, not only the credential boundary.

Command injection in shared libraries creates systemic blast radius. A defect in a common dependency can affect many applications that never wrote vulnerable code themselves. That makes dependency governance, secure defaults, and protocol-specific testing part of operational resilience. Teams should assume that widely deployed libraries deserve the same control scrutiny as external-facing services.

Credentialed systems need structural input controls, not human skepticism. Email trust mechanisms already assume the message is well formed, and that assumption fails fast when the application constructs malicious protocol frames. The same pattern applies to AI agents and service identities that can issue actions automatically. Practitioners should enforce structure before privilege, not after.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities. Confidence gaps of that size usually track incomplete lifecycle controls, not just tooling gaps.
• From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%. The same control logic applies when trusted automation can generate privileged actions.
• From our research: The broader lesson is that identity trust must be enforced at the action boundary, not only at the credential boundary. See the The 52 NHI breaches Report for repeated failure patterns and the Ultimate Guide to NHIs , 2025 Outlook and Predictions for how those patterns evolve.

What this signals

SMTP command injection should be read as an identity boundary problem. When a system can create messages or actions on behalf of a trusted principal, the point of risk is the translation from input into authority. Teams should map those translation points across mail systems, ticketing automations, and AI workflows, then verify where validation occurs before privilege is exercised.

The most useful programme response is to treat protocol builders as governance surfaces. That means pairing secure coding rules with dependency review, protocol-aware test cases, and incident playbooks that distinguish trust failure from credential theft. For identity teams, the parallel to NHI governance is clear: if a workload can speak with authority, it needs strict control over what it can say.

For practitioners

• Sanitise protocol control characters Reject carriage return and line feed characters wherever user input can become part of an SMTP command, including recipient, sender, and header fields. Apply the same rule to any protocol builder that serializes trusted actions from untrusted data.
• Test libraries for command-boundary injection Add unit and fuzz tests that try to break protocol boundaries in shared libraries, especially where the code concatenates values into mail, HTTP, or queue commands. Use negative cases to confirm the parser fails closed before serialization.
• Review trust assumptions in automated mail flows Map every system that sends mail on behalf of a user, service, or workflow and verify where the message is assembled, signed, and delivered. That review should distinguish authentication controls such as SPF, DKIM, and DMARC from the application-layer logic that creates the message.
• Add dependency governance for core libraries Track critical libraries with the same discipline you use for externally facing services, including version pinning, vulnerability monitoring, and rapid patch rollout. Prioritise components that sit at protocol boundaries because a single flaw can affect many downstream systems.

Key takeaways

• The Netty flaw showed that a text-based protocol can be turned into a trust bypass when user input is allowed to shape SMTP commands.
• Standard mail-authentication controls did not stop the attack because the forged message was created inside the trusted sending path.
• Teams should govern the data-to-command boundary in shared libraries, because that is where application logic becomes privileged action.

Key terms

• SMTP Command Injection: SMTP command injection is a flaw where untrusted input is inserted into a text-based mail command without proper sanitisation. An attacker can use protocol control characters to create additional commands, changing recipients, content, or sender behaviour inside a trusted mail flow.
• Protocol Boundary Validation: Protocol boundary validation is the process of checking identity assertions when traffic crosses a trust boundary between systems, networks, or providers. It is the control that prevents a forged caller, packet, or message from being accepted simply because it arrived through a familiar channel.
• Mail Authentication: Mail authentication is the set of checks, including SPF, DKIM, and DMARC, used to verify that a message appears to originate from an authorised sender path. It does not determine whether the content is safe, so authenticated mail can still carry phishing links or malicious meeting requests.
• Trusted Execution Path: A trusted execution path is a system route that assumes the caller is already authorised once initial access is granted. In SAP, these paths often include RFC, web service, and legacy UI functions. If enforcement is inconsistent, the path becomes a control-plane weakness rather than a normal application feature.

What's in the full article

depthfirst's full article covers the implementation detail this post intentionally leaves for the source:

• Auto-generated patch snippet and the maintainers' discussion about where validation belongs in the library stack.
• The exact SMTP command construction path that allowed CRLF injection into recipient values.
• The precedent Netty followed from its HTTP codec and comparable fixes in PHPMailer and Apache James.
• The article's account of how the AI agent discovered the flaw and generated a patch autonomously.

👉 depthfirst's full post covers the exploit path, maintainer discussion, and autonomous patch generation details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps practitioners connect lifecycle control, privilege boundaries, and operational governance across modern identity programmes.