CVE-2026-41319

Root

Cause MailKit versions prior to 4.16.0 contain a STARTTLS Response Injection vulnerability (CVE-2026-41319) in the SmtpStream, ImapStream, and Pop3Stream classes. The Stream property is a simple auto-property that does not reset the internal read buffer when the underlying stream is replaced with SslStream during a STARTTLS upgrade [3]. This means any data that a Man-in-the-Middle attacker injects after the 220 Ready response (still within the same TCP segment) remains in the buffer and is not discarded when TLS negotiation begins.

Exploitation

A MitM attacker positioned between the MailKit client and the real server can append crafted protocol responses after the legitimate STARTTLS success response (e.g., 220 Ready) [2][3]. The client reads the 220 Ready line from its internal buffer, then replaces the plaintext stream with a TLS stream — but does not clear any remaining buffered data. When the client later issues an EHLO command (or equivalent in IMAP/POP3), ReadResponse() finds the injected data already in the buffer and processes it as if it came over the authenticated TLS channel [3]. No authentication is required for this attack; the attacker only needs to be in a position to intercept and modify network traffic before TLS is established.

Impact

By injecting a fake capability response, the attacker can force the client to downgrade its SASL authentication mechanism. For example, the server may offer SCRAM-SHA-256-* mechanisms, but the injected data can list only PLAIN, causing the client to send credentials in cleartext even though TLS was supposedly active [2][3]. This compromises authentication secrets and enables credential theft.

Mitigation

The vulnerability is fixed in MailKit version 4.16.0 [2][3]. Users should upgrade immediately. There is no known workaround. This vulnerability class is similar to earlier issues in Thunderbird (CVE-2021-23993), Dovecot (CVE-2021-33515), and Postfix (CVE-2011-0411) [3].