CVE-2026-104658

Progressive Robot hMailServer w wersjach 6.0.0 do 6.3.5 nie wymusza TLS dla wychodzącej dostawy SMTP do serwera wymiany poczty, którego rekordy TLSA zweryfikowane przez DNSSEC nie zawierają rekordu DANE-EE (użycie 3), wbrew RFC 7672 sekcja 2.2. Serwer używał tylko rekordów DANE-EE i traktował zweryfikowany zestaw rekordów TLSA składający się z DANE-TA (użycie 2) lub innych bezużytecznych rekordów tak, jakby nie opublikowano żadnych rekordów, więc dostawa do takiego hosta spadała do oportunistycznego TLS. Atakujący z aktywną pozycją na ścieżce sieciowej między serwerem a serwerem wymiany poczty odbiorcy może stłumić lub przerwać negocjację STARTTLS i spowodować dostarczenie wiadomości w postaci jawnej, gdzie mogą być odczytane i zmodyfikowane.

Brak autoryzacji na obiektach COM w Progressive Robot hMailServer 6.0.0 do 6.3.5 (tylko Windows) pozwala lokalnemu użytkownikowi interaktywnemu bez poświadczeń hMailServer na odczyt i zapis dowolnych plików jako konto usługi oraz kolejkę poczty jako dowolny nadawca. Usługa rejestruje swoje klasy COM bez uprawnień dostępu lub uruchamiania DCOM i wywołuje CoInitializeSecurity bez deskryptora zabezpieczeń, więc każdy użytkownik zalogowany na konsoli lub przez Remote Desktop może aktywować klasy w działającej usłudze; utworzone w ten sposób hMailServer.Message, jego Attachments i Attachment oraz hMailServer.FetchAccount niosą poświadczenie, które nigdy nie zostało uwierzytelnione. Attachments.Add(path) i Attachment.SaveAs(path) nie wykonywały żadnej kontroli autoryzacji, a Message.Save/Copy i FetchAccount.AccountID/Save nie wykonywały żadnej do 6.3.3, a od 6.3.4 traktowały posiadacza bez poświadczeń jako własnego hosta skryptów zdarzeń serwera. Ponieważ usługa nie personifikuje wywołującego COM, Attachments.Add odczytuje dowolny plik, który konto usługi może odczytać, i zwraca go, Attachment.SaveAs zapisuje wybrane przez atakującego bajty do dowolnej ścieżki, do której może zapisać (w instalacji LocalSystem, wykonanie kodu jako SYSTEM), Message.Save kolejkuje wychodzącą pocztę z dowolnego adresu poza kontrolami SMTP, a FetchAccount dołącza zadanie pobierania poczty do dowolnej skrzynki. Obiekty przekazane przez Application zachowują się tak samo, gdy późniejsze Authenticate na tym Application zawiedzie.

Brak walidacji nagłówka Host i brak ograniczania nieudanych logowań administratora w listenerze REST API Progressive Robot hMailServer 6.0.0 do 6.3.5 pozwalają zdalnemu atakującemu na brute-force hasła administratora serwera przez przeglądarkę administratora za pomocą DNS rebinding. Listener, domyślnie wyłączony i powiązany z loopbackiem, odpowiadał na żądania niezależnie od nagłówka Host, a nieudane logowanie z hasłem administratora z loopbacka nie było automatycznie banowane ani opóźniane. Strona internetowa, której nazwa hosta jest rebindowana na 127.0.0.1, otwarta w przeglądarce na serwerze, może wysyłać uwierzytelnione żądania do listenera, odczytywać odpowiedzi i próbować hasła administratora z pełną prędkością, aż jedno zostanie zaakceptowane, dając atakującemu pełną kontrolę administracyjną nad serwerem pocztowym.

Brak limitów czasu sieci w kompilacjach Linuksa Progressive Robot hMailServer 6.3.0 do 6.3.5 pozwala zdalnemu atakującemu na zajęcie wątków serwera na czas nieokreślony i zatrzymanie wychodzącej dostawy poczty (odmowa usługi). Serwer ustawiał limity czasu gniazd w formie akceptowanej przez Windows, którą Linux odrzuca, a jego klienty HTTPS czytały bez terminu, więc peer, który akceptuje połączenie i nic nie wysyła, trzymał wątek oczekujący tak długo, jak długo połączenie pozostawało otwarte. Pobieranie polityki MTA-STS, domyślnie włączone, odbywa się podczas wychodzącej dostawy do mta-sts.<domena odbiorcy>, więc każdy, kto może zmusić serwer do dostarczenia poczty do domeny przez niego kontrolowanej — na przykład jako nadawca koperty wiadomości, która odbija się — może trzymać wątki dostawy, aż wychodząca dostawa ustanie. Ta sama wada dotyczy zapytania DANE TLSA, żądania tokenu OAuth2, klienta ACME oraz listenerów ManageSieve i metryk, które cichy klient przestaje obsługiwać dla wszystkich innych. Kompilacje Windows nie są dotknięte.

Cross-site scripting w webmailu Progressive Robot hMailServer 6.3.2 do 6.3.5 pozwala zdalnemu atakującemu, który może wysłać użytkownikowi zaszyfrowaną wiadomość, na uruchomienie skryptu w origin webmaila z sesją tego użytkownika. Gdy webmail odszyfrowywał wiadomość S/MIME (od 6.3.2) lub OpenPGP (od 6.3.4) w przeglądarce, oferował każdy odszyfrowany załącznik jako blob URL typu mediów zadeklarowanego dla niego. Kliknięcie zapisywało plik, ale jeśli użytkownik otworzył załącznik w nowej karcie, część zadeklarowana jako text/html była renderowana jako dokument origin webmaila, a jej skrypt mógł odczytać skrzynkę, wysyłać pocztę i zmieniać konto przez REST API. Webmail jest serwowany tylko, gdy REST API jest włączone, co nie jest domyślne.

Przepełnienie bufora na stercie w starszej procedurze deszyfrowania Blowfish (BlowFishEncryptor::DecryptFromString) w Progressive Robot hMailServer 6.0.0 do 6.3.3 na Windows pozwala lokalnemu użytkownikowi interaktywnemu bez poświadczeń hMailServer na zapis wybranych bajtów poza końcem 255-bajtowego bufora sterty w procesie usługi hMailServer, który domyślnie działa jako LocalSystem. Użytkownik robi to, przekazując długi ciąg szesnastkowy do metody COM Utilities.BlowfishDecrypt, która nie sprawdzała uwierzytelnienia. Procedura konwertowała dane wejściowe o dowolnej długości na stały 255-bajtowy bufor przed deszyfrowaniem w miejscu. Skutkiem jest odmowa usługi (awaria usługi) i prawdopodobnie wykonanie kodu z uprawnieniami konta usługi.

Podatność na wstrzykiwanie kodu JScript w hMailServer (wersje 6.0.0-6.3.3) umożliwia zdalnemu, nieuwierzytelnionemu atakującemu wykonanie dowolnego kodu JScript w procesie usługi z uprawnieniami konta usługi. Wymaga to niestandardowej konfiguracji: włączonego skryptowania zdarzeń, języka JScript i zdefiniowanego handlera OnClientValidatePassword. Atak wykorzystuje hasło zawierające backslash i apostrof, które nie jest poprawnie escapowane.