CVE-2026-50659

Overview

.NET is a free, open-source, cross-platform framework for building modern apps and powerful cloud services. It consists of a runtime and a developer platform made up of tools, programming languages, and libraries for building many different types of applications.

A content spoofing vulnerability (CVE-2026-50659) has been identified in .NET's System.Net.Mail SMTP client, which allows an authorized attacker to smuggle a message-terminating sequence past the client's outbound dot-stuffing encoder and inject additional SMTP commands or a second spoofed message. This is a form of SMTP smuggling (CWE-116, improper encoding or escaping of output).

Per CWE-116: Improper Encoding or Escaping of Output, improper encoding or escaping of output occurs when a product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly, so the intended structure of the message is not preserved.

This issue affects the System.Net.Mail SMTP client in multiple versions of .NET, including the End-of-Life .NET 6.0 line.

‍

Details

Module Info

• Product: .NET
• Affected packages: Microsoft.NETCore.App shared framework (System.Net.Mail)
• Affected versions: >= 6.0.0 <= 6.0.42
• GitHub repository: https://github.com/dotnet/runtime
• Published packages: Download .NET (Linux, macOS, and Windows)
• Package manager: NuGet
• Fixed in: NES for .NET 6.0.43

Vulnerability Info

This Medium-severity vulnerability is found in the System.Net.Mail component in multiple versions of .NET, including the End-of-Life .NET 6.0 line.

When an application sends mail through SmtpClient, the message content is written to the SMTP DATA command through an encoder that applies RFC 2821 dot-stuffing: at the start of each output line, a leading . is doubled so that message content cannot prematurely terminate the DATA command. That encoding is implemented in EightBitStream.EncodeLines, which tracks the current line length and only recognizes a CRLF line ending when the CR and the LF fall inside the same write buffer:

// EightBitStream.EncodeLines: a CRLF is detected only within one write buffer
if ((buffer[i] == '\r') && ((i + 1) < (offset + count)) && (buffer[i + 1] == '\n'))
{
    WriteState.AppendCRLF(false); // resets CurrentLineLength to 0
    i++; // skip past the recorded CRLF
}
else if ((WriteState.CurrentLineLength == 0) && (buffer[i] == '.'))

When a CR ends one write call and the following LF begins the next call, the encoder never resets CurrentLineLength, so a . at the start of the following line is not doubled. An application that relays attacker-influenced message content can be driven to place a line boundary at a write split and emit an un-stuffed leading dot, smuggling a DATA-terminating sequence past the encoder and injecting additional SMTP commands or a second spoofed message onto the wire.

This vulnerability has been present since at least .NET 6.0 and likely earlier.

‍

Mitigation

.NET 6 is End-of-Life and will not receive any updates to address this issue. For more information see .NET and .NET Core official support policy.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to one of:
  
  •  .NET Runtime >= 8.0.29
  •  .NET Runtime >= 9.0.18
  • .NET Runtime >= 10.0.10
• Leverage a commercial support partner like HeroDevs for post-EOL security support, including NES for .NET 6.0.43 or later.

‍

Credits

Microsoft credits hamayanhamayan for reporting this vulnerability.