CVE-2026-55558: 
Linux Debian 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, where the receive buffer is not cleared before the TLS handshake, allowing an active network attacker to inject attacker-controlled SMTP response lines that survive the plaintext-to-TLS transport upgrade. All versions prior to 5.1.2 are affected when using start_tls=True or opportunistic STARTTLS; connections using use_tls=True (implicit TLS) are not vulnerable. The vulnerability was published 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 perform the TLS handshake, but does not clear SMTPProtocol._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 persist across the plaintext→TLS boundary and are subsequently parsed as if they arrived inside the encrypted session. An active man-in-the-middle (MITM) on the same network segment can craft a single TCP segment containing the legitimate 220 Go ahead response immediately followed by attacker-chosen SMTP response lines (e.g., 250-mx.evil 250 AUTH LOGIN ), which then desynchronize all subsequent SMTP command/response pairs within the ostensibly encrypted session. The fix, introduced in commit 9fab7ba, adds del self._buffer[:] immediately before loop.start_tls is called, per RFC 3207 §4.2 (GitHub Advisory, Fix Commit).

Successful exploitation allows an active MITM attacker to inject arbitrary SMTP response lines into what the client believes is an encrypted TLS session, achieving high integrity impact with no confidentiality or availability loss. The attacker can manipulate the client's view of server capabilities (e.g., advertise fake AUTH mechanisms), cause the client to authenticate against attacker-controlled parameters, or desynchronize the SMTP session entirely to force unexpected behavior in downstream mail processing. The attack does not require any privileges or user interaction, but does require the ability to intercept and modify network traffic on the plaintext leg of the STARTTLS connection (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The NVD SSVC assessment indicates exploitation is "none" and the attack is not automatable, reflecting the requirement for an active MITM position on the network. The EPSS score is approximately 0.0026 (0.26%), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Gain MITM position: Position on the same network segment as the target client (e.g., via ARP spoofing, rogue Wi-Fi access point, or BGP hijacking) to intercept TCP traffic between the aiosmtplib client and the SMTP server.
2. Intercept STARTTLS exchange: Monitor the plaintext TCP stream for the client's STARTTLS command sent to the SMTP server.
3. Craft injected response: Immediately after the server's legitimate 220 Go ahead\r\n response, inject attacker-chosen SMTP response lines in the same TCP segment before the TLS handshake begins (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 injected bytes remain in SMTPProtocol._buffer and are not discarded.
5. Exploit desynchronized session: The client parses the injected plaintext as the first post-TLS server response, desynchronizing all subsequent SMTP command/response pairs. The attacker can use this to manipulate advertised server capabilities, force use of a weaker AUTH mechanism, or cause the client to behave unexpectedly (GitHub Advisory, Fix Commit).

• Network: Unexpected SMTP response lines (e.g., 250-mx.evil, 250 AUTH LOGIN) appearing in traffic captures immediately after a 220 STARTTLS reply, within the same TCP segment; anomalous SMTP server banners or capability advertisements not matching the legitimate server.
• Logs: Application logs showing unexpected SMTP server capabilities or AUTH methods after STARTTLS negotiation; SMTP session errors or unexpected command/response mismatches following TLS upgrade; connections to SMTP servers where the advertised EHLO hostname does not match the expected server.
• Behavior: aiosmtplib-based applications unexpectedly selecting weaker authentication mechanisms (e.g., AUTH LOGIN instead of AUTH PLAIN or XOAUTH2); SMTP sessions failing or behaving erratically after STARTTLS with no server-side explanation.

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, which eliminates the plaintext phase entirely and is not vulnerable. As an additional measure, restrict STARTTLS connections to SMTP servers reachable only over trusted, controlled network paths to reduce MITM exposure (GitHub Advisory).

The vulnerability was disclosed by the project maintainer (cole) via a GitHub Security Advisory on June 20, 2026, referencing the well-known STARTTLS injection class documented by Poddebniak, Schmidt, et al. in their USENIX Security 2021 paper "Why TLS is better without STARTTLS." No significant broader media coverage or notable external researcher commentary has been identified beyond standard vulnerability database aggregation (GitHub Advisory).