CVE-2026-104659

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.

Helper aktualizacji na żywo Linuksa (hmailserver-update) w Progressive Robot hMailServer 6.3.4 i 6.3.5 działa jako root na pliku żądania zapisanym przez nieuprzywilejowane konto usługi hmailserver i pobiera z tego żądania program używany do weryfikacji podpisu aktualizacji AppImage oraz jednostkę systemd do zatrzymania przed odczytaniem plików konta usługi. Atakujący, który już wykonuje kod jako konto usługi hmailserver, na przykład przez inną lukę w serwerze pocztowym, może w ten sposób spowodować wykonanie dowolnego kodu jako root, na dowolnej instalacji Linuksa, gdzie jednostka ścieżki aktualizacji na żywo jest aktywna — domyślnie dla pakietów .deb i .rpm projektu — oraz w instalacjach AppImage uruchamianych pod tą jednostką.

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.