GHSA-9j88-vvj5-vhgr: STARTTLS Response Injection and SASL Downgrade in MailKit

MailKit is a widely deployed open-source .NET mail client library supporting IMAP, POP3, and SMTP protocols. It implements the STARTTLS extension to upgrade standard plaintext network connections to secure, encrypted TLS tunnels. The protocol upgrade requires strict state management to separate plaintext data from encrypted data. A failure in this separation logic introduces a vulnerability categorized under CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component).

The vulnerability is a STARTTLS Response Injection flaw. When MailKit negotiates a protocol upgrade, it relies on application-layer buffers to read server responses efficiently. If an attacker injects additional data into the TCP stream immediately following the server's affirmative response to the STARTTLS command, MailKit reads the entire segment into its internal memory buffer.

Because the internal buffer is not explicitly flushed when the underlying socket transitions to a secure state, the injected plaintext payload remains queued. Once the TLS handshake completes and the client issues its first post-TLS command, it retrieves the attacker's queued response from local memory instead of reading from the secure tunnel. This architecture flaw mirrors historical protocol issues such as CVE-2011-0411 in Postfix and CVE-2021-33515 in Dovecot.

MailKit optimizes network I/O operations through custom stream wrappers, specifically SmtpStream, ImapStream, and Pop3Stream. These classes implement internal buffering using a byte array (input) and position pointers (inputIndex and inputEnd). When the client receives the "220 Ready" response to a STARTTLS command, the Read method fetches data from the network socket into this array to minimize system calls.

A Man-in-the-Middle (MitM) attacker exploits TCP stream coalescing by appending a forged response directly after the legitimate "220 Ready" string within the same plaintext TCP packet. The application-layer read operation pulls the entire packet payload into the input buffer. The STARTTLS parsing logic correctly identifies the "220" status code and initiates the TLS handshake, wrapping the network socket in an SslStream.

The root cause of the vulnerability resides in the stream transition logic. When MailKit assigns the newly negotiated SslStream to the active connection, it fails to clear or invalidate the existing plaintext bytes held between inputIndex and inputEnd. The internal buffering mechanism retains the attacker's injected payload.

Following the successful TLS handshake, the client issues a command expecting an encrypted response, such as an EHLO command to query server capabilities. When the stream class attempts to read the response, it first inspects its internal buffer. Finding the unread injected bytes, it processes them immediately. The client software parses this plaintext injection under the false assumption that it arrived via the authenticated, encrypted TLS tunnel.

The vulnerability exists within the property setters responsible for updating the underlying network stream after a successful TLS handshake. In the vulnerable versions of SmtpStream, ImapStream, and Pop3Stream, the transition assigns the new SslStream without resetting the internal buffer indices.

The logic failure allows stale, unencrypted bytes to persist across the boundary of the security context transition.

// Vulnerable implementation (conceptual representation)
internal Stream Stream {
    get { return stream; }
    set {
        stream = value;
        // FLaw: inputIndex and inputEnd retain their previous values
        // Any unread bytes from the plaintext connection remain valid
    }
}

The fix implemented in MailKit version 4.16.0 addresses this synchronization issue directly. The developers modified the stream property setter to forcefully invalidate the internal buffer whenever the underlying stream object changes. Setting inputIndex equal to inputEnd signals to the read methods that the buffer is empty.

// Patched implementation
internal Stream Stream {
    get { return stream; }
    set {
        stream = value;
        inputIndex = inputEnd; // Fix: Buffer invalidated upon stream transition
    }
}

This remediation completely neutralizes the injection vector. By discarding all residual data in the application-layer buffer, MailKit is forced to perform a fresh read operation against the newly established SslStream. Any plaintext bytes appended by an attacker are discarded, ensuring the client only processes data that has successfully passed through the TLS decryption and MAC verification processes.

Exploitation requires the attacker to occupy a Man-in-the-Middle (MitM) position on the network path between the MailKit client and the legitimate mail server. The attacker intercepts the client's initial plaintext connection and monitors the protocol exchange. When the client issues the STARTTLS command, the attacker permits the server to respond but intercepts that response packet.

The attacker modifies the server's affirmative response by appending a crafted payload. For an SMTP session, the attacker sends 220 Ready\r\n followed immediately by 250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n. The entire string is transmitted to the client in a single plaintext TCP segment, loading the payload into MailKit's read buffer.

// Attack simulation PoC
// The attacker concatenates the STARTTLS success and the fake EHLO response
Send(s, "220 Ready\r\n250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n");
 
// Client initiates connection and requests secure upgrade
client.Connect("127.0.0.1", port, SecureSocketOptions.StartTls);
Console.WriteLine($"Auth mechanisms: {string.Join(", ", client.AuthenticationMechanisms)}");
// Output: Auth mechanisms: PLAIN, LOGIN

The client processes the "220 Ready" segment and successfully negotiates the TLS session with the server. However, upon sending the subsequent EHLO command, the client reads the locally buffered attacker payload. The client registers the server capabilities as restricted to PLAIN and LOGIN authentication methods, completely ignoring the true capabilities the server would have transmitted over the TLS tunnel.

The primary impact of this vulnerability is a SASL mechanism downgrade. By substituting the server's legitimate capability list with a crafted list, an attacker manipulates the client's security decisions. The attacker strips out strong authentication mechanisms like SCRAM-SHA-256 or CRAM-MD5, forcing the client to select weaker mechanisms such as PLAIN or LOGIN.

While the client proceeds to transmit credentials over the newly established TLS tunnel, the underlying security model is compromised. If the client connects to an attacker-controlled endpoint rather than the legitimate server, or if the TLS certificate validation is bypassed or misconfigured by the user, the attacker can intercept the plaintext credentials directly.

The vulnerability is assessed with a CVSS v3.1 score of 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N). The lack of a direct confidentiality impact in the base vector reflects that the injection itself only modifies data (integrity), and the subsequent credential exposure requires additional conditions, such as the client continuing authentication against an invalid certificate.

This diagram illustrates the flow of data. The critical failure point occurs when the stale data in the internal read buffer bypasses the TLS verification process and feeds directly into the client's post-TLS state machine.

The definitive remediation for this vulnerability is updating the MailKit NuGet package to version 4.16.0 or later. This version contains the required patches to flush internal read buffers during protocol transitions. Development teams must scan their dependency trees to ensure no transitive dependencies are pulling in vulnerable versions of the library.

For systems where immediate patching is not technically feasible, administrators can implement a network-level mitigation by disabling explicit TLS (STARTTLS) and enforcing implicit TLS. By connecting to dedicated secure ports (e.g., port 465 for SMTP, port 993 for IMAP, port 995 for POP3) using SecureSocketOptions.SslOnConnect, the application establishes the encrypted tunnel before any protocol data is exchanged.

Implicit TLS eliminates the plaintext transition phase entirely, rendering response injection attacks mechanically impossible. Security engineers should update application configuration files to prefer implicit TLS over STARTTLS whenever the target mail server supports it, aligning with modern RFC 8314 recommendations.