12 maja 2026 zespół XBOW opublikował szczegóły krytycznej luki w Eximie — najpopularniejszym agencie poczty na świecie, według statystyk pracującym na ponad 50 procentach widocznych w internecie serwerów SMTP. Podatność oznaczona jako CVE-2026-45185 i nazwana „Dead.Letter” pozwala nieautoryzowanemu napastnikowi wykonać kod na serwerze pocztowym, mając do dyspozycji jedynie możliwość nawiązania połączenia TLS i wysłania wiadomości komendą BDAT. Twórcy Exima przyznali jej maksymalny poziom krytyczności (CVSS 9.8), a poprawka trafiła do wersji 4.99.3 — wszystko poniżej, począwszy od 4.97, jest podatne.
Na czym polega luka
Dead.Letter to klasyczny use-after-free w obsłudze komendy BDAT (CHUNKING) — rozszerzenia SMTP pozwalającego przesyłać dużą wiadomość w blokach binarnych zamiast linia po linii. Bug uaktywnia się, kiedy klient zaczyna przesyłać treść wiadomości komendą BDAT po szyfrowanym połączeniu TLS, w środku transmisji wysyła pakiet TLS close_notify (rozłączenie szyfrowanej sesji), a następnie — wciąż w tej samej sesji TCP — dosyła jeszcze jeden bajt w czystym tekście. Exim w tym momencie zapisuje dane do bufora, który został już zwolniony podczas zamykania sesji TLS, co prowadzi do uszkodzenia sterty i, przy odpowiednim ułożeniu pamięci, do zdalnego wykonania kodu.
Co istotne, luka dotyczy wyłącznie buildów Exima skompilowanych z USE_GNUTLS=yes. Wersje używające OpenSSL — czyli między innymi standardowe pakiety w Debianie, Ubuntu i CentOS Stream — są bezpieczne. To dość duża ulga, bo wielu administratorów po lekturze pierwszych nagłówków wpadło w panikę. Niestety część dystrybucji oraz wiele własnoręcznie kompilowanych Eximów na hostingu współdzielonym jest budowanych z GnuTLS, między innymi po to, by uniknąć problemu z licencją OpenSSL przy linkowaniu.
Dlaczego to jest tak groźne
Po pierwsze, atak nie wymaga uwierzytelnienia — wystarczy, że serwer Exima jest dostępny z internetu na porcie 25, 465 albo 587 i akceptuje TLS oraz CHUNKING. To w praktyce każdy hosting i każdy własny serwer pocztowy. Po drugie, luka nie wymaga żadnej specjalnej konfiguracji po stronie serwera — działa na ustawieniach domyślnych. Po trzecie, exploit jest relatywnie prosty do napisania, a XBOW w swoim raporcie opisał technikę krok po kroku, więc można się spodziewać, że publiczny PoC pojawi się w ciągu kilku dni od publikacji.
Z perspektywy napastnika udane wykorzystanie Dead.Letter oznacza zdobycie pełnej kontroli nad serwerem pocztowym, co przekłada się na cztery scenariusze. Pierwszy to czytanie i przekierowywanie cudzej poczty, w tym tokenów resetu hasła do innych usług. Drugi to wysyłanie spamu i phishingu z legalnego serwera, którego reputacja sprawi, że wiadomości trafią do skrzynki odbiorczej, a nie do folderu spam. Trzeci to ruch lateralny w infrastrukturze hostingowej, bo Exim często ma dostęp do bazy użytkowników i panelu cPanel/DirectAdmin. Czwarty, najbardziej spektakularny — szyfrowanie całego serwera ransomwarem.
Co zrobić, jeżeli zarządzasz serwerem pocztowym
Pierwsza i najważniejsza rzecz — sprawdź, czy twój Exim jest skompilowany z GnuTLS. Wystarczy polecenie exim -bV i poszukanie w wyjściu wpisu „Support for: GnuTLS”. Jeżeli go widzisz, jesteś podatny. Jeżeli widzisz „OpenSSL”, możesz spać spokojnie do następnej luki. Wersję sprawdzisz w tej samej komendzie — wszystko od 4.97 do 4.99.2 wymaga natychmiastowej aktualizacji do 4.99.3.
Druga rzecz to aktualizacja przez menedżera pakietów dystrybucji. Debian, Ubuntu i RHEL wypuściły backportowane łatki w ciągu 24 godzin od publikacji, więc zwykłe apt update && apt upgrade exim4 albo dnf update exim powinno wystarczyć. W cPanelu sprawdź EasyApache i upewnij się, że Exim jest na najnowszej wersji, ewentualnie wymuś rekompilację.
Trzecia rzecz, jeżeli z jakiegoś powodu nie możesz natychmiast zaktualizować — tymczasowo wyłącz obsługę CHUNKING w exim.conf opcją chunking_advertise_hosts = . Wyłączenie tego rozszerzenia ucina wektor ataku, bo BDAT przestaje być reklamowany klientom. Skutkiem ubocznym jest spadek wydajności przy dużych załącznikach, ale to rozsądna cena za bezpieczeństwo do czasu zaktualizowania pakietu.
Czwarta rzecz to monitoring logów. Sprawdź w /var/log/exim/mainlog (albo /var/log/exim4/mainlog) wpisy zawierające słowo „BDAT” połączone z nietypowymi rozłączeniami TLS. Jeżeli widzisz wiele takich połączeń ze stałych adresów IP w ostatnich dniach, jest spora szansa, że już ktoś próbował na tobie wykorzystać podatność.
Czego się spodziewać w najbliższych tygodniach
Historia poprzednich krytycznych luk w Eximie (Sender Address Header Disclosure z 2019 roku, „21 Nails” z 2021 roku) pokazuje, że masowe skanowanie internetu w poszukiwaniu podatnych serwerów rozpoczyna się w ciągu 48–72 godzin od publikacji szczegółów. Botnety pokroju Mirai dostosowują swoje moduły skanujące błyskawicznie, a ransomware-as-a-service operacjonalizuje exploit w ciągu tygodnia. W praktyce oznacza to, że okno bezpieczeństwa od momentu publikacji do pierwszej masowej fali ataków wynosi 3–7 dni — i to jest czas, w którym trzeba się zaktualizować.
Podsumowanie
Dead.Letter to jeden z najgroźniejszych bugów w Eximie ostatnich lat, bo łączy łatwość wykorzystania z brakiem wymogu uwierzytelniania i maksymalnym wpływem na bezpieczeństwo. Jeżeli administrujesz serwerem pocztowym, sprawdź wersję i bibliotekę TLS jeszcze dziś, zaktualizuj Exima do 4.99.3, a w środowiskach krytycznych dorzuć wyłączenie CHUNKINGu jako warstwę dodatkową. Jeżeli korzystasz z hostingu współdzielonego, dopytaj dostawcę, czy ich Exim został już zaktualizowany — to jego zadanie, ale w razie zaniedbania to klient ponosi konsekwencje wycieku poczty.
źródło: https://thehackernews.com/2026/05/new-exim-bdat-vulnerability-exposes.html