Krytyczna podatność w serwerze pocztowym Exim. Administratorzy muszą pilnie zaktualizować
CERT Polska ostrzega przed luką CVE-2026-45185 w serwerze pocztowym Exim, która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Podatne są wersje 4.97-4.99.2 z biblioteką GnuTLS, w tym domyślne konfiguracje Debiana i Ubuntu. Należy niezwłocznie zaktualizować oprogramowanie.
Zespół CERT Polska opublikował ostrzeżenie o krytycznej podatności w serwerze pocztowym Exim, który jest jednym z najpopularniejszych rozwiązań MTA (Mail Transfer Agent) na świecie. Luka oznaczona jako CVE-2026-45185 otrzymała maksymalną ocenę 9.8 w skali CVSS, co oznacza najwyższy poziom ryzyka. Podatność umożliwia zdalnemu, nieuwierzytelnionemu atakującemu wykonanie dowolnego kodu na serwerze. Administratorzy powinni jak najszybciej sprawdzić wersję Exima i zastosować aktualizację.
Co wiadomo o podatności
Według komunikatu CERT Polska problem dotyczy wersji Exima od 4.97 do 4.99.2 włącznie, ale tylko tych skompilowanych z biblioteką GnuTLS. To ważne zastrzeżenie – instalacje korzystające z biblioteki OpenSSL nie są zagrożone tą konkretną luką. Podatne są między innymi domyślne konfiguracje w dystrybucjach Debian oraz Ubuntu, które często używają GnuTLS. Jak wskazują znalazcy podatności, luka może pozwolić na zdalne wykonanie kodu w kontekście serwera Exim, co w praktyce oznacza możliwość przejęcia kontroli nad całą maszyną.
Szczegóły techniczne zostały upublicznione przez badaczy z XBOW, którzy odkryli i zgłosili problem. Mechanizm ataku wykorzystuje specyficzny sposób obsługi połączeń TLS w połączeniu z GnuTLS. Atakujący nie potrzebuje żadnych uwierzytelnienia ani uprzedniego dostępu do serwera – wystarczy wysłać spreparowane zapytanie sieciowe.
Kogo dotyczy zagrożenie
Exim jest domyślnym serwerem pocztowym w wielu dystrybucjach Linuksa, szczególnie w Debianie i Ubuntu. Oznacza to, że podatność może dotyczyć zarówno serwerów korporacyjnych, jak i mniejszych instalacji hostingowych czy nawet domowych serwerów NAS, jeśli uruchomiono na nich usługę pocztową. W polskim krajobrazie IT Exim wciąż jest szeroko stosowany, zwłaszcza w starszych instalacjach i u dostawców hostingu współdzielonego. Administratorzy powinni niezwłocznie sprawdzić, jaką wersję Exima uruchomili oraz z jaką biblioteką TLS została skompilowana.
CERT Polska w swoim ostrzeżeniu nie podaje informacji o aktywnych atakach, ale biorąc pod uwagę łatwość wykorzystania luki i jej krytyczną ocenę, ryzyko jest bardzo wysokie. Zalecenie jest jednoznaczne: aktualizacja do wersji zawierającej łatkę, czyli nowszej niż 4.99.2, lub przejście na wersję skompilowaną z OpenSSL.
Jak się zabezpieczyć – praktyczne kroki
Najważniejszym działaniem jest aktualizacja oprogramowania. Większość dystrybucji powinna już udostępnić poprawione pakiety. W Debianie i Ubuntu wystarczy wykonać standardowe polecenia aktualizacji systemu:
- Sprawdź aktualną wersję Exima: exim –version | head -1
- Zaktualizuj pakiety: sudo apt update && sudo apt upgrade exim4 (lub odpowiednik dla Twojej dystrybucji)
- Po aktualizacji uruchom ponownie usługę: sudo systemctl restart exim4
Jeśli z jakiegoś powodu nie można natychmiast zaktualizować, tymczasowym rozwiązaniem może być przełączenie Exima na bibliotekę OpenSSL (jeśli to możliwe w danej kompilacji) lub ograniczenie dostępu do serwera tylko dla zaufanych sieci. Należy jednak traktować to jako działanie doraźne – tylko aktualizacja usuwa podatność całkowicie.
Po załataniu luki warto sprawdzić logi systemowe i logi Exima pod kątem nietypowych wpisów, które mogłyby świadczyć o próbie wykorzystania podatności. CERT Polska prosi o kontakt w przypadku wykrycia oznak potencjalnego ataku.
Co dalej – monitoring i wnioski
Podatność w Eximie pokazuje, jak ważne jest regularne aktualizowanie nawet dobrze znanego i stabilnego oprogramowania. Nawet serwery pocztowe, które często działają przez lata bez zmian, mogą nagle stać się celem ataku. Warto śledzić komunikaty CERT Polska oraz producentów dystrybucji, aby szybko reagować na tego typu ostrzeżenia. Dla administratorów kluczowe jest także utrzymanie kopii zapasowych i procedur odtwarzania po incydencie – na wypadek, gdyby atak powiódł się przed załataniem luki.


