CVE-2026-55558: 
Python vulnerability analysis and mitigation

CVE-2026-55558 is a STARTTLS response injection vulnerability in aiosmtplib, an asynchronous SMTP client for Python's asyncio framework. The flaw exists in SMTPProtocol.start_tls within src/aiosmtplib/protocol.py, which fails to clear the receive buffer before initiating the TLS handshake, allowing an active network attacker (man-in-the-middle) to inject attacker-chosen SMTP response lines that persist into the encrypted session. All versions up to and including 5.1.1 are affected; connections using use_tls=True (implicit TLS) are not vulnerable. The vulnerability was published by the National Vulnerability Database on August 20, 2026, and carries a CVSS v3.1 base score of 5.9 (Medium) (Github Advisory).

The root cause is classified as CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component — Injection). When SMTPProtocol.start_tls is called, it reads the server's 220 go-ahead reply and immediately invokes loop.start_tls to upgrade the transport, but does not call del self._buffer[:] beforehand. Because asyncio swaps the transport in place while reusing the protocol object and its buffer, any bytes already buffered from the plaintext socket survive the upgrade and are subsequently parsed as if they originated from within the TLS session. An active MITM attacker on the same network segment can craft a single TCP segment containing the legitimate 220 Go ahead response followed by attacker-chosen SMTP response lines (e.g., 250-mx.evil 250 AUTH LOGIN ); aiosmtplib consumes only the 220, leaves the injected lines in the buffer, completes the handshake, and then misinterprets the attacker's pre-staged plaintext as the first post-TLS server response, desynchronizing all subsequent command/response pairs. The fix, introduced in commit 9fab7ba, adds del self._buffer[:] immediately before the loop.start_tls call, per RFC 3207 §4.2 (Github Advisory, Fix Commit).

Successful exploitation allows an active network attacker to inject and control SMTP response data that the client processes as authenticated, encrypted server responses, resulting in a high integrity impact with no confidentiality or availability loss. The attacker can manipulate SMTP command-response exchanges — for example, spoofing authentication capability advertisements or forging server acknowledgments — potentially causing the client to send credentials or email content to attacker-controlled endpoints or to behave in unintended ways. The scope is limited to the affected connection; however, desynchronization of the SMTP session can affect all subsequent commands within that session (Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time, per NVD SSVC assessment and Feedly executive summary (Github Advisory). Exploitation requires an active man-in-the-middle position on the network path between the client and the SMTP server during the plaintext phase of a STARTTLS negotiation; passive eavesdroppers cannot exploit this vulnerability. The EPSS score is approximately 0.26% (18th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported.

1. Gain MITM position: Position on the network path between the aiosmtplib client and the target SMTP server (e.g., via ARP spoofing, rogue Wi-Fi access point, or BGP hijacking on the plaintext network segment).
2. Intercept STARTTLS negotiation: Monitor the TCP stream for the client's STARTTLS command, which is sent in plaintext before TLS is established.
3. Craft injected response: Immediately after the client sends STARTTLS, respond with a single TCP segment containing the legitimate 220 go-ahead reply followed by attacker-chosen SMTP response lines, e.g.:

   220 Go ahead\r\n250-mx.evil\r\n250 AUTH LOGIN\r\n

4. Allow TLS handshake to complete: Let the TLS handshake proceed normally. The aiosmtplib client will consume only the 220 response and buffer the remaining injected lines without clearing them.
5. Injected data parsed as TLS response: After the handshake, the client reads the buffered attacker-controlled plaintext as the first response from within the encrypted session, desynchronizing all subsequent SMTP command/response pairs.
6. Achieve objective: Leverage the desynchronized session to spoof server responses — for example, advertising attacker-controlled authentication mechanisms, manipulating EHLO capability lists, or causing the client to misdirect email or credentials (Github Advisory, Fix Commit).

• Network: Unexpected or malformed SMTP response lines (e.g., 250-mx.evil, 250 AUTH LOGIN) appearing immediately after a 220 STARTTLS go-ahead in network captures; TCP segments containing multiple SMTP response lines concatenated with the 220 reply during the STARTTLS exchange.
• Logs: Application-level SMTP session logs showing unexpected server capability advertisements (e.g., unknown hostnames in EHLO responses, unexpected AUTH methods) immediately after STARTTLS negotiation; SMTP command/response pairs that appear out of sequence or mismatched after TLS upgrade.
• Process/Application Behavior: aiosmtplib-based applications unexpectedly attempting authentication with methods not previously configured; connections to SMTP servers resulting in authentication failures or unexpected server error codes post-TLS handshake.

Upgrade aiosmtplib to version 5.1.2 or later, which discards any buffered server data before the STARTTLS handshake per RFC 3207 §4.2 (Release v5.1.2). If an immediate upgrade is not possible, switch to implicit TLS by connecting with use_tls=True instead of start_tls=True or opportunistic STARTTLS — this eliminates the plaintext phase entirely and is not affected by this vulnerability. As an additional precaution, restrict SMTP connections to servers reachable only over trusted, controlled network paths to reduce MITM exposure (Github Advisory).