Most of the email injection bugs covered here start in a narrow corner of the internet: one WordPress plugin, one Java library. CVE-2026-50659 does not. It sits inside System.Net.Mail, the SMTP client built into every version of .NET for the last two decades, still wired into countless contact forms, ticketing systems, and notification services that have no reason to ever get rewritten.
What CVE-2026-50659 Actually Is
Disclosed as part of Microsoft’s July 2026 .NET security updates, CVE-2026-50659 is a spoofing vulnerability in the SmtpClient implementation shipped in System.Net.Mail. It affects .NET 8.0.0 through 8.0.28, .NET 9.0.0 through 9.0.17, and .NET 10.0.0 through 10.0.9, along with the end-of-life .NET 6.0 line, which will not receive a fix. Patched releases are 8.0.29, 9.0.18, and 10.0.10. Microsoft rates it CVSS 6.5, medium severity, and classifies it as CWE-116, improper encoding or escaping of output.
Microsoft has told developers for years that System.Net.Mail is not recommended for new projects. That guidance did nothing to remove it from production. It remains one of the most common ways a .NET application actually sends mail, precisely because it works, it ships in the box, and nobody budgets time to replace working code.
How a Dot-Stuffing Bug Becomes an Email Smuggling Bug
SMTP marks the end of a message body with a line containing a single period. To keep a genuine line that happens to start with a period from being mistaken for that terminator, the protocol requires dot-stuffing: any line in the message body that begins with a period gets an extra period added in front of it before transmission, then stripped back out on the receiving end.
SmtpClient’s encoder tracks where it is on the current line to know when to apply that stuffing. The bug is in how it handles content delivered across more than one write call. When a carriage return ends one write and the matching line feed arrives at the start of the next write, the encoder fails to correctly carry its line-position tracking across that boundary. A line that begins with a period immediately after a split like that does not get stuffed.
An application that builds an outbound message from attacker-influenced text, a support ticket body, a “message” field on a contact form, a comment forwarded by email, and writes it to the SMTP stream in more than one call, can be driven to place exactly that kind of split at a point the attacker controls. The result is a bare . line reaching the server as a real end-of-message marker in the middle of what should have been one email. Everything the attacker supplied after that point is no longer message content. It is a fresh set of SMTP commands, including a second MAIL FROM, RCPT TO, and DATA block, smuggled into the same session as a message the application never intended to send.
Where DMARC Sits in This Chain
This is the detail that matters most for anyone running authentication policy. The smuggled message is not sent by forging headers on an unrelated connection. It rides the exact same outbound SMTP session the vulnerable application already opened, to the same relay the application is already authorized to use, whether that is an internal Exchange server, Amazon SES, SendGrid, or any other provider the app authenticates to normally.
SPF checks the connecting IP against the domain in the envelope sender. DKIM checks a cryptographic signature applied by the sending infrastructure. DMARC checks that the two align. None of those checks look inside the SMTP session to ask whether it secretly contains two messages instead of one. If the relay signs and forwards the smuggled message the same way it signs and forwards the legitimate one, because from the relay’s point of view there is no visible difference, the smuggled message passes SPF, DKIM, and DMARC cleanly. Not by defeating them. By never entering their field of view as anything other than ordinary, authorized outbound mail.
That is the same pattern behind the Netty and WordPress plugin injection bugs covered here before, now sitting one layer up, inside the framework millions of enterprise .NET applications quietly depend on to send mail on their organization’s behalf.
What This Means for Your Program
Patch first, this one is a straightforward update. Move to .NET 8.0.29, 9.0.18, or 10.0.10, or the corresponding SDK versions. If you maintain a self-contained deployment, it must be recompiled and redeployed against the patched runtime; updating the shared runtime alone will not touch it.
Audit every place your applications build email from user input. Contact forms, support portals, invitation systems, and anything that forwards user-submitted text by email are the applications that matter here. Confirm the message body is written to the SMTP stream in a way your library handles safely, and treat any code path still on .NET 6.0 as needing a migration plan, not just a wait for a patch that is not coming.
Don’t expect DMARC monitoring to surface this on its own. A smuggled message sent through your own authenticated relay looks, to your DMARC aggregate reports, identical to a message you meant to send. Detecting abuse here depends on catching it at the application layer, through input validation and library updates, not through your authentication reports.
Treat “legacy but working” mail code as attack surface, not as settled infrastructure. System.Net.Mail has been marked not recommended for new development for a long time. This vulnerability is a reminder that the code already running in production is exactly where a bug like this does the most damage, because it is the code nobody is looking at.
The Takeaway
CVE-2026-50659 is not a failure of SPF, DKIM, or DMARC. It is a reminder that authentication protocols secure the relationship between a domain and its authorized sending infrastructure, not the integrity of what that infrastructure is asked to send. A single mishandled line break in a two-decade-old SMTP client was enough to let attacker-supplied text become a second, fully authenticated email, riding out through the front door your own application already had open.
Excello Mail gives you continuous visibility into your DMARC reports, so you always know which infrastructure is authenticating under your domain, even as the applications sending that mail carry vulnerabilities authentication alone was never built to catch. Sign up for free to Excello Mail and put real monitoring behind the authentication layer you control.