CVE-2025-55248

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.

An Information Disclosure vulnerability (CVE-2025-55248) has been identified in System.Net.Mail, which allows an attacker positioned between the client and the SMTP server to prevent the use of TLS and read what should have been an encrypted session. An attacker who causes the server's EHLO reply to fail pushes the client onto the older HELO command, which cannot advertise STARTTLS.

Per CWE-326: Inadequate Encryption Strength, the product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.

This issue affects .NET 6. System.Net.Mail ships in-box as part of the Microsoft.NETCore.App shared framework. Exposure is narrower than the advisory implies: only asynchronous sends are affected. A client calling the synchronous Send already failed closed in .NET 6, so applications using SendAsync or SendMailAsync with EnableSsl set are the ones at risk.

‍

Details

Module Info

• Product: .NET
• Affected packages: System.Net.Mail (ships in the Microsoft.NETCore.App shared framework)
• Affected versions: Microsoft.NETCore.App >= 6.0.0 <= 6.0.44
• 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.45

Vulnerability Info

This Medium-severity vulnerability is found in SmtpConnection as shipped in the .NET 6 shared framework. SmtpClient opens a session with EHLO and falls back to HELO when the server reports the command unrecognised. STARTTLS is advertised only in the EHLO response, so a session negotiated with HELO can never be upgraded. A client that has asked for TLS by setting EnableSsl must therefore treat that fallback as fatal.

The synchronous path did exactly that: after the fallback it checked whether the server had advertised STARTTLS and threw when it had not. The asynchronous path had no equivalent check. Its SendHello continued straight to authentication, so the credentials and the message itself crossed the network on an unencrypted connection. An attacker who can inject a single error reply to the EHLO command is enough to trigger it, without needing to interfere with the rest of the session.

The fixed release adds the missing check, throwing SmtpException with the existing "server does not support STARTTLS" message before the fallback proceeds, which brings the asynchronous path into line with the synchronous one.

Applicability to .NET 6 was established from source and confirmed by exercising the shipped artifact: against a server that rejects EHLO, the 6.0.44 asynchronous path transmitted MAIL FROM, RCPT TO and DATA in the clear. Microsoft's published affected-version list names only .NET 8 and 9.

‍

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 >= 8.0.21
  • .NET >= 9.0.10
• Leverage a commercial support partner like HeroDevs for post-EOL security support, including NES for .NET 6.0.45 or later.

‍

Credits

Microsoft did not publicly credit an individual finder for this vulnerability in its security advisory.