CVE-2026-55558: STARTTLS Response Injection in aiosmtplib

The asynchronous SMTP client library aiosmtplib relies on Python's asyncio framework to manage network socket communication. During connection initialization over standard port 587 or 25, the protocol utilizes explicit negotiation to transition an insecure plaintext connection to an encrypted Transport Layer Security (TLS) tunnel via the STARTTLS command sequence.

This transition exposes a temporary state boundary where plaintext messages must cease, and encrypted handshaking must initiate. Under standard RFC 3207 specifications, both client and server must verify that no extra data is present on the wire during this transitional window. If either party fails to validate that transport streams are completely synchronized and empty of unauthenticated packets, the protocol is susceptible to injection techniques.

The vulnerability is classified under CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component) and represents a classic protocol-transition buffer injection. An attacker with active network placement can inject arbitrary SMTP command responses that are subsequently interpreted by the application as trusted, encrypted payload responses.

In Python asyncio, the asyncio.Protocol base class reads incoming bytes from the underlying TCP socket and appends them to a continuous application-level read buffer. The implementation of aiosmtplib manages this buffer through the SMTPProtocol._buffer attribute in src/aiosmtplib/protocol.py. During normal operation, the client reads a line of text, locates the carriage return and line feed indicators (\r\n), and extracts the command response.

When SMTPProtocol.start_tls is called, the library transmits the STARTTLS command and waits for the server's 220 Go ahead reply. When the server transmits this reply, it may be combined into a single TCP segment with other data due to standard network framing or TCP pipelining. The aiosmtplib client parses only the initial 220 response from the read buffer but neglects to verify whether further, unparsed data remains in SMTPProtocol._buffer prior to executing the handshake.

Immediately after parsing the 220 code, the client invokes self._loop.start_tls(), which substitutes the plaintext transport with a new ssl.SSLSocket-backed transport. Crucially, the high-level SMTPProtocol instance and its associated _buffer remain unchanged during this transport swap. Because the existing bytes inside the buffer are not purged, any plaintext data residing there is preserved. When the next secure application command is issued, the client reads from its local _buffer first, consuming unencrypted, attacker-supplied data as though it was authenticated ciphertext from the newly established TLS session.

An inspection of the fix implemented in version 5.1.2 highlights the specific buffer-handling deficiency. In previous releases, the function initiated the TLS upgrade with the buffer unchecked, leaving any pre-loaded bytes accessible to the application engine. The patch directly resolves this by clearing the internal list object.

Below is the patch implemented in src/aiosmtplib/protocol.py inside the start_tls method:

# File: src/aiosmtplib/protocol.py
@@ -379,6 +379,13 @@ async def start_tls(
             if self.transport is None or self.transport.is_closing():
                 raise SMTPServerDisconnected("Connection lost")
 
+            # STARTTLS injection defense (RFC 3207 section 4.2): a compliant
+            # server sends nothing after its 220 reply until TLS is negotiated.
+            # Any bytes still buffered here are plaintext a MITM may have
+            # injected; discard them so they cannot be misread as part of the
+            # encrypted session once the handshake completes.
+            del self._buffer[:]
+
             try:
                 tls_transport = await self._loop.start_tls(
                     cast(asyncio.WriteTransport, self.transport),

The introduction of del self._buffer[:] explicitly truncates the dynamic array. Because the deletion occurs after the verification of the transport state but before invoking the start_tls asynchronous hook of the loop, there is no window where a secondary read can occur. Any data sent by a server or injected by an intermediate node prior to the TLS handshake execution is discarded. If the adversary sends extra bytes during the actual TLS handshake, those bytes will be processed by the OpenSSL state machine, causing a hard handshake failure rather than application-layer processing.

To exploit this vulnerability, an attacker must have Adversary-in-the-Middle capabilities on the network path. This position can be achieved through ARP poisoning, DNS redirection, or control of an intermediary network appliance. The attacker monitors TCP traffic on standard SMTP port 587 or 25 and waits for a STARTTLS request.

When the client transmits the STARTTLS command, the attacker permits the command to reach the real server. Once the server returns the 220 Go ahead status code, the attacker intercepts this packet and modifies the payload before forwarding it to the client. The attacker appends malicious SMTP capability lists or spoofed responses directly behind the 220 code.

Once the TLS handshake finishes, the client immediately issues its EHLO command to negotiate capabilities. The client's line parser then retrieves the injected bytes from self._buffer and treats them as the response to the EHLO query. The attacker can structure these responses to spoof the supported authentication mechanisms, force authentication down to plaintext (AUTH PLAIN), or simulate authentication failures to capture user credentials.

The security implications of CVE-2026-55558 are significant for environments relying on opportunistic or explicit STARTTLS. If an organization transmits transactional or administrative emails using vulnerable client configurations, credentials can be intercepted. An attacker can inject an AUTH promotion response that prompts the client to transmit base64-encoded login strings, resulting in credential harvesting.

Furthermore, the attacker can use this session desynchronization to silently hijack the email transaction. By manipulating the server's advertised capabilities, the attacker can block transport-layer integrity checks or alter command flows to force the client to transmit email payloads to alternative recipients. Because this injection happens prior to the secure negotiation phase, standard application loggers often record a successful TLS connection, hiding the execution of the injection.

The CVSS v3.1 base score of 5.9 reflects High complexity because it requires the attacker to have network path access and manage timing precisely to align the injected packets. Despite this high complexity, the impact to confidentiality and integrity is significant, prompting recommended remediation.

The primary remediation for this vulnerability is upgrading aiosmtplib to version 5.1.2 or higher, which includes the buffer clearance mechanism. Security teams should scan PyPI dependency locks, requirements files, and containerized Python runtimes to ensure compliance.

If immediate patching is not possible due to dependency constraints, organizations can configure explicit connection rules. Forcing the connection configuration parameter use_tls=True bypasses the STARTTLS sequence. This parameter establishes an implicit TLS session on port 465 from the first packet, negating the plaintext protocol negotiation window.

Additionally, implementing strict DNSSEC and routing infrastructure access lists minimizes the probability of an adversary gaining the required network positioning to perform the injection.