CVE-2026-104659

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.

Nieprawidłowa autoryzacja w API administracyjnym COM w hMailServer 6.3.4–6.3.6 pozwala kontu z rolą serveradmin ograniczoną do listy domen działać jako administrator całego serwera przez COM. Konto może odczytywać i zmieniać konta oraz pocztę wszystkich domen, zmieniać nazwy domen, mapować aliasy, modyfikować ustawienia i sekrety serwera oraz tworzyć kolejne konta administratora serwera.

Brak autoryzacji w interfejsach administracyjnych REST i COM hMailServer 6.0.0–6.3.6 firmy Progressive Robot pozwala zdalnemu uwierzytelnionemu użytkownikowi, którego poświadczenia są ograniczone do wskazanych domen, na zmianę routingu poczty i konfiguracji domen poza tymi domenami na serwerze wielodostępnym. Możliwe jest m.in. utworzenie aliasu domeny dla dowolnej nazwy, zmiana nazwy domeny, ustawienie akcji reguły (bind-to-address, send-using-route, script-function) oraz ustawienie hosta przekazywania domeny na adres w sieci serwera.

W hMailServer 6.0.0 do 6.3.6 akcja usuwania załączników przez antywirusa nie kończy się bezpieczną odmową, co pozwala zdalnemu nieuwierzytelnionemu atakującemu na dostarczenie do skrzynki odbiorcy wiadomości uznanej przez skaner za zainfekowaną w niezmienionej postaci. Gdy skanowanie jest włączone, a akcja ustawiona na usuwanie załączników i dostarczanie tekstu, serwer zachowuje jedną część tekstową i zastępuje załączniki notatką. Wiadomość, której jedyna część nie jest tekstem, nie ma części do wyodrębnienia i jest dostarczana bez zmian.

Podatność w hMailServer (wersje 6.0.0–6.3.6) polega na niewystarczającym zachowaniu oryginalnego nadawcy przy przekazywaniu wiadomości. W wyniku tego zdalny, nieuwierzytelniony atakujący może wysłać wiadomość z adresem From w domenie hostowanej przez serwer, a serwer przekaże ją dalej w taki sposób, że u odbiorców przejdzie ona kontrolę SPF i DMARC dla tej domeny, mimo że oryginalnie nie przeszła DMARC.

W hMailServer w wersji od 6.2.25 do 6.3.6 brakuje autoryzacji w trasie REST metrics, co pozwala uwierzytelnionemu użytkownikowi z uprawnieniami ograniczonymi do nazwanych domen odczytać historię ruchu całego serwera. GET /api/v1/metrics/history zwraca liczniki ruchu z ostatnich 30 dni, które są ogólnoserwerowe i nie zawierają informacji o domenie.

Nieprawidłowa autoryzacja w interfejsie administracyjnym REST hMailServer 6.3.4–6.3.6 firmy Progressive Robot pozwala zdalnemu uwierzytelnionemu użytkownikowi z uprawnieniem manage_roles w wskazanych domenach na uzyskanie uprawnień administratora serwera. Trasa DELETE /api/v1/role-assignments/{address} sprawdzała jedynie uprawnienia bieżące, a nie przyszłe, co pozwalało odebrać zawężającą rolę kontu o poziomie administratora serwera i przywrócić jego pełne uprawnienia, a następnie zalogować się jako administrator serwera po wcześniejszej zmianie hasła tego konta.

Brak autoryzacji w trasach REST do zarządzania rolami w Progressive Robot hMailServer 6.3.4 do 6.3.6 pozwala zdalnemu uwierzytelnionemu użytkownikowi, którego poświadczenia są ograniczone do nazwanych domen, modyfikować rolę niestandardową posiadaną przez konta w innych domenach oraz tworzyć i usuwać role. Trasy tworzenia, aktualizacji i usuwania roli wymagają uprawnienia manage_roles, które posiada tylko rola serveradmin; jednak klucz API o pełnym zakresie wydany dla nazwanych domen oraz serveradmin przypisany z listą domen są ograniczone do tych domen i posiadają manage_roles. Bramka autoryzacji nie odrzuciła tych tras dla ograniczonych poświadczeń, a trasa nie wskazywała domeny, więc poświadczenie jednego tenanta mogło podnieść lub obniżyć uprawnienia roli niestandardowej przypisanej w innych tenantach.

W hMailServer w wersjach 6.0.0–6.3.6 użyto mniej zaufanego źródła adresu koperty przy pobieraniu z konta zewnętrznego. Umożliwia to zdalnemu nieuwierzytelnionemu atakującemu wysłanie wiadomości w imieniu domeny hostowanej przez serwer z adresem koperty w tej domenie, dzięki czemu przechodzi ona kontrolę SPF i DMARC u odbiorców. Serwer przyjmował adres z nagłówka From jako adres koperty dla wiadomości pobranych przez POP3/IMAP, a przekierowanie takiej wiadomości na zewnątrz zachowywało ten adres, który Sender Rewriting Scheme pozostawiał bez zmian dla domeny hostowanej.

Nieprawidłowa autoryzacja w Sender Rewriting Scheme (SRS) w Progressive Robot hMailServer 6.2.1 do 6.3.6 pozwala zdalnemu atakującemu na przekazywanie poczty przez serwer na zewnętrzne adresy. Gdy SRS jest włączony, serwer przepisuje kopertę nadawcy na podpisany adres SRS w domenie przekazującej i przekazuje odbicie na ten adres z powrotem do oryginalnego nadawcy; jednak każdą wiadomość na prawidłowy adres SRS, niezależnie od nadawcy, traktował jako dostarczenie do lokalnego odbiorcy, więc reguły przekazywania i wymagane uwierzytelnianie SMTP nie były stosowane, a wiadomość była dostarczana na zewnętrzny adres zakodowany w adresie SRS. Każdy posiadający prawidłowy adres SRS serwera mógł przez 21 dni zlecać serwerowi przekazywanie poczty na adres, który koduje.