CVE-2026-55558

ŚrednieCVSS 5.9

Opublikowano: 20/08/2026(UTC)Zaktualizowano: 20/08/2026(UTC)Przetłumaczono: 20/08/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.26%

Percentyl 18 - wyżej niż 18% wszystkich znanych CVE

Streszczenie

W bibliotece aiosmtplib przed wersją 5.1.2 wykryto podatność w metodzie SMTPProtocol.start_tls. Atakujący aktywny w sieci może umieścić własne linie odpowiedzi SMTP po odpowiedzi 220, które po rozpoczęciu TLS są interpretowane jako pierwsza odpowiedź w sesji TLS, co prowadzi do desynchronizacji komunikacji SMTP. Podatne są połączenia z start_tls=True lub oportunistycznym STARTTLS.

Ocena ryzyka

Podatność umożliwia atakującemu typu man-in-the-middle manipulację sesją SMTP, co może prowadzić do przechwycenia lub modyfikacji wiadomości e-mail. Może to naruszyć poufność i integralność komunikacji.

Rekomendacja

Zaleca się natychmiastową aktualizację biblioteki aiosmtplib do wersji 5.1.2 lub nowszej. Należy również rozważyć użycie połączeń z use_tls=True, które nie są podatne.

Inne podatności w aiosmtplib

CVE-2026-53533Średnie
aiosmtplib przed wersją 5.1.1 nie odrzuca adresów zawierających znaki CR lub LF w metodach SMTP.mail(), SMTP.rcpt(), SMTP.vrfy() i SMTP.expn(). Dane po znaku nowej linii są interpretowane jako dodatkowe komendy SMTP, co pozwala atakującemu na wstrzyknięcie komend takich jak MAIL FROM, RCPT TO, RSET, DATA lub AUTH. SMTP.sendmail() i SMTP.send() bez obiektu Message przekazują adresy przez podatne metody, podczas gdy SMTP.send_message() nie jest podatne. Udane wstrzyknięcie może zdesynchronizować potok komend, zawiesić instancję SMTP lub wysłać dowolną wiadomość bez kontroli nad serwerem SMTP.

Oryginalny opis (angielski, źródło NVD)

aiosmtplib is an asynchronous SMTP client for use with asyncio. Prior to 5.1.2, SMTPProtocol.start_tls in src/aiosmtplib/protocol.py consumes the server's 220 response and starts the TLS handshake without clearing SMTPProtocol._buffer. An active network attacker can place attacker-chosen SMTP response lines after the plaintext 220 response in the same network segment. The method then calls loop.start_tls; those bytes survive the transport upgrade and are parsed as the first response from inside the TLS session, desynchronizing subsequent SMTP command and response pairs. Connections using start_tls=True or opportunistic STARTTLS are affected, while connections using use_tls=True are not. This issue is fixed in version 5.1.2.