CVE-2026-41319: 
C# vulnerability analysis and mitigation

CVE-2026-41319 is a STARTTLS Response Injection vulnerability in MailKit, a cross-platform mail client library for .NET built on top of MimeKit. It allows a Man-in-the-Middle (MitM) attacker to inject arbitrary protocol responses across the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade (e.g., forcing PLAIN or LOGIN instead of SCRAM-SHA-256). All MailKit versions prior to 4.16.0 are affected across SMTP, IMAP, and POP3 protocol implementations. The vulnerability was published on April 24, 2026, with a patch released in version 4.16.0. It carries a CVSS v3.1 base score of 5.9 (Medium/High) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component — Injection). The vulnerability exists because the Stream property setter in SmtpStream, ImapStream, and Pop3Stream does not reset the internal 4096-byte read buffer (inputIndex/inputEnd) when the underlying stream is replaced with an SslStream during STARTTLS upgrade. A MitM attacker positioned on the network can append crafted protocol data immediately after the legitimate 220 Ready STARTTLS response in a single TCP segment; this injected data is buffered before TLS negotiation begins. After the TLS handshake completes, subsequent calls (e.g., Ehlo()) read from the still-populated buffer rather than the new encrypted channel, causing pre-TLS attacker-controlled data to be interpreted as trusted post-TLS server responses. The fix requires resetting buffer indices (inputIndex = inputEnd) when the stream property is set. This vulnerability belongs to the same class as CVE-2021-23993 (Thunderbird), CVE-2021-33515 (Dovecot), and CVE-2011-0411 (Postfix) (GitHub Advisory).

Successful exploitation allows a network MitM attacker to manipulate the SASL authentication mechanism negotiation for SMTP, IMAP, and POP3 connections, downgrading from strong mechanisms like SCRAM-SHA-256 to weaker ones such as PLAIN or LOGIN. This primarily impacts integrity (CVSS integrity impact: HIGH) — the attacker can force the client to authenticate using a weaker mechanism, potentially enabling credential interception or replay attacks if the attacker can also observe the subsequent authentication exchange. Any application using MailKit with SecureSocketOptions.StartTls or StartTlsWhenAvailable (the default configuration) is affected, making the exposure broad across .NET mail-sending applications (GitHub Advisory).

A self-contained C# proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating successful SASL mechanism downgrade against MailKit 4.12.0 (confirmed output: Auth mechanisms: PLAIN, LOGIN when the server advertised SCRAM-SHA-256). Exploitation requires a network MitM position (high attack complexity), which limits opportunistic exploitation but is realistic in shared network environments, rogue Wi-Fi, or compromised network infrastructure. The EPSS score is approximately 0.031% (0.000310), indicating low current exploitation probability. No in-the-wild exploitation or CISA KEV catalog listing has been reported as of the time of this report (GitHub Advisory, Red Hat CVE).

1. Establish MitM position: Position between the MailKit client and the mail server using ARP spoofing, rogue access point, BGP hijacking, or DNS manipulation to intercept TCP traffic on the relevant mail port (25/587 for SMTP, 143 for IMAP, 110 for POP3).
2. Intercept initial plaintext connection: Allow the client's initial connection and EHLO/CAPABILITY exchange to pass through to the real server, relaying legitimate server responses (including STARTTLS capability advertisement) to the client.
3. Intercept STARTTLS command: When the client sends STARTTLS, forward it to the real server and receive the legitimate 220 Ready response.
4. Inject malicious data: Craft a TCP response that includes the legitimate 220 Ready\r\n immediately followed by a forged EHLO response advertising only weak authentication mechanisms (e.g., 250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n). Deliver this as a single TCP segment to the client so both the legitimate response and injected data land in MailKit's internal read buffer.
5. Allow TLS handshake: Let the TLS handshake proceed normally between client and server — the injected data remains in the client's pre-TLS buffer undetected.
6. Trigger buffer processing: After TLS is established, MailKit's Ehlo() call reads from the still-populated internal buffer instead of the TLS stream, processing the attacker-injected AUTH PLAIN LOGIN capability as if it were a trusted post-TLS server response.
7. Achieve downgrade: The client now believes only PLAIN/LOGIN authentication is available and proceeds to authenticate using the weaker mechanism, potentially exposing credentials to the MitM attacker (GitHub Advisory).

• Network: Unexpected TCP segments containing both a 220 Ready STARTTLS response and additional SMTP/IMAP/POP3 protocol data in a single packet; anomalous ARP traffic or unexpected gateway MAC address changes indicating MitM positioning; TLS handshake traffic on mail ports preceded by unusually large plaintext response payloads.
• Logs: Application or mail client logs showing authentication via PLAIN or LOGIN mechanisms when SCRAM-SHA-256 or other strong mechanisms were expected or previously used; authentication failures or unexpected mechanism negotiation in mail server access logs.
• Behavioral: MailKit-based applications suddenly using weaker SASL mechanisms (PLAIN, LOGIN) despite server support for stronger ones (SCRAM-SHA-256, GSSAPI); authentication credentials transmitted in base64-encoded PLAIN format observable in network captures between STARTTLS and expected encrypted traffic.

The primary remediation is to upgrade MailKit to version 4.16.0 or later, which patches the vulnerability by resetting buffer indices (inputIndex = inputEnd) when the internal stream is replaced during STARTTLS upgrade. No configuration-based workaround is available for unpatched versions since the vulnerability affects the default StartTlsWhenAvailable behavior. As a temporary risk reduction measure, applications can be configured to use implicit TLS (e.g., SecureSocketOptions.SslOnConnect on port 465/993/995) instead of STARTTLS, which avoids the plaintext-to-TLS upgrade path entirely and eliminates the attack surface (GitHub Advisory).

The vulnerability was reported by security researcher ROCmertakdag and published by MailKit maintainer jstedfast via GitHub Security Advisories on April 17, 2026. The advisory explicitly draws parallels to the same vulnerability class affecting Thunderbird (CVE-2021-23993), Dovecot (CVE-2021-33515), and Postfix (CVE-2011-0411), contextualizing it as a known and recurring pattern in mail protocol implementations. Red Hat tracked the issue as affecting their product ecosystem (Red Hat CVE). No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability database aggregation.