CVE-2025-49113 w Roundcube: krytyczne RCE po zalogowaniu

CVE-2025-49113 to krytyczna podatność Roundcube Webmail oceniona na CVSS 9,9. Uwierzytelniony użytkownik może wstrzyknąć złośliwy obiekt PHP, doprowadzić do wykonania kodu na serwerze pocztowym i przejść od dostępu do jednej skrzynki do naruszenia całej aplikacji. Błąd dotyczy wersji Roundcube 1.1.0–1.6.10 i został usunięty w 1.5.10 oraz 1.6.11.

W praktyce: zaktualizuj Roundcube do najnowszego wspieranego wydania, przejrzyj żądania ustawiające nietypowe parametry sesji i załóż, że przejęte konto pocztowe wystarcza do rozpoczęcia ataku. Wymóg logowania nie jest silną barierą w środowisku pełnym phishingu i wykradzionych haseł.

CVE-2025-49113 — fakty

Parametr	Wartość
Produkt	Roundcube Webmail
Podatne wersje	1.1.0 do 1.6.10
Poprawione wersje	1.5.10 oraz 1.6.11
CVSS	9,9 — krytyczna
Wymagania	konto użytkownika Roundcube
Klasa błędu	PHP object deserialization / object injection
Skutek	zdalne wykonanie kodu w kontekście serwera webowego
Publiczny PoC	tak, opublikowany przez badacza

Projekt Roundcube ogłosił poprawki 1 czerwca 2025 r. w oficjalnym komunikacie o wersjach 1.6.11 i 1.5.10. Wersja 1.5.11 naprawiła później problem zgodności z PHP 5.5, który pojawił się w 1.5.10; organizacje powinny instalować aktualne wspierane wydanie, a nie historyczne minimum.

Jak dochodzi do deserializacji PHP

Roundcube używał funkcji PHP unserialize() na danych, których struktura mogła zostać zmodyfikowana przez zalogowanego użytkownika. Serializacja pozwala zapisać obiekt wraz z jego właściwościami, ale odtworzenie obiektu w aplikacji uruchamia także mechanizmy klas: metody magiczne, destruktory i łańcuchy wywołań. Jeżeli w kodzie lub zależnościach istnieje odpowiedni gadget chain, kontrolowany obiekt może doprowadzić do zapisu pliku albo wykonania polecenia.

W CVE-2025-49113 problem był związany z nieprawidłową walidacją nazwy parametru i sposobem, w jaki dane trafiały do sesji. Badacz wykazał, że odpowiednio skonstruowane wejście może zanieczyścić przechowywany stan, a następnie uruchomić PHP object injection.

Nie trzeba mieć konta administratora. Wystarczy zwykła sesja użytkownika, co w praktyce oznacza także:

hasło wykradzione przez phishing;
konto z credential stuffing;
utworzony legalnie użytkownik w usłudze hostingowej;
dostęp przez przejętą sesję lub słabe SSO;
konto wewnętrzne o minimalnych uprawnieniach.

Dlaczego wpływ wykracza poza jedną skrzynkę

Roundcube działa na serwerze webowym mającym dostęp do konfiguracji IMAP/SMTP, książek adresowych, wtyczek, baz danych i sekretów aplikacji. Kod wykonany jako użytkownik PHP może odczytać konfigurację, modyfikować pliki osiągalne dla procesu i nawiązywać połączenia do systemów wewnętrznych.

Możliwe skutki zależą od architektury:

przejęcie sekretów i sesji innych użytkowników;
modyfikacja strony logowania w celu kradzieży haseł;
dostęp do bazy Roundcube i książek adresowych;
wykorzystanie hosta jako punktu wejścia do sieci pocztowej;
trwałość przez webshell, wtyczkę lub zmieniony kod aplikacji;
podszywanie się pod organizację i dalsze kampanie BEC.

Izolowany kontener i rozdzielenie ról mogą ograniczyć wpływ, ale wiele starszych wdrożeń webmaila łączy aplikację, bazę i dane konfiguracyjne na jednym serwerze.

Publiczny PoC i bezpieczne potwierdzenie

Autor badania udostępnił publiczny PoC CVE-2025-49113 oraz opis techniczny. Repozytorium zawiera kod prowadzący do wykonania polecenia i nie powinno być uruchamiane na produkcyjnej poczcie.

Bezpieczna walidacja powinna opierać się przede wszystkim na wersji:

odczytaj wersję z plików aplikacji lub menedżera pakietów, nie tylko stopki UI;
ustal, czy wdrożenie pochodzi z upstreamu, dystrybucji Linux czy panelu hostingowego;
sprawdź poprawkę dostawcy backportowaną do pakietu o starszym numerze;
zbuduj kopię laboratoryjną z testową skrzynką i bez danych firmowych;
monitoruj filesystem i proces PHP podczas nieszkodliwego testu;
po aktualizacji wykonaj retest i sprawdź integralność plików.

W dystrybucjach numer pakietu może wyglądać na starszy mimo backportu. Źródłem prawdy jest advisory dostawcy systemu oraz changelog pakietu.

Aktualizacja i hardening Roundcube

Zaktualizuj odpowiednio do 1.6.11 lub nowszej w głównej linii albo do wspieranej linii LTS co najmniej 1.5.10. Ze względu na późniejsze wydania najbezpieczniej użyć aktualnej wersji wspieranej przez projekt lub dystrybucję. Wykonaj kopię konfiguracji i bazy, wdrożenie w oknie serwisowym oraz test logowania, wysyłki, książek adresowych i wtyczek.

Dodatkowe kontrole:

uruchamiaj PHP-FPM jako osobne, nieuprzywilejowane konto;
ustaw katalogi aplikacji jako tylko do odczytu poza miejscami, które muszą być zapisywalne;
trzymaj sekrety poza webrootem;
ogranicz połączenia wychodzące procesu webowego;
usuń nieużywane wtyczki i regularnie aktualizuj Composer dependencies;
stosuj MFA na warstwie tożsamości, rate limiting i ochronę przed credential stuffing;
centralizuj logi reverse proxy, aplikacji, IMAP, SMTP i systemu operacyjnego.

WAF może wykryć część znanych wzorców, ale nie powinien być podstawą ochrony. Łańcuchy serializacji można kodować na wiele sposobów, a zalogowany ruch zwykle ma wyższy poziom zaufania.

Detekcja i incident response

Przejrzyj okres od pierwszej ekspozycji podatnej wersji, zwracając uwagę na:

nietypowe żądania zalogowanych użytkowników i parametry z zakodowaną treścią;
błędy unserialize, ostrzeżenia PHP i nagłe wyjątki sesji;
procesy potomne PHP-FPM, których nie wymaga Roundcube;
nowe lub zmienione pliki PHP, szczególnie w katalogach zapisywalnych;
połączenia wychodzące z serwera webmail do nieznanych hostów;
modyfikacje wtyczek, konfiguracji, cron i kont systemowych;
logowania do wielu skrzynek po pojedynczym zdarzeniu aplikacyjnym;
reguły przekazywania poczty i anomalie wysyłki mogące świadczyć o BEC.

W przypadku potwierdzonego RCE odizoluj host, zabezpiecz obraz dysku i logi, obróć sekrety aplikacji oraz hasła kont technicznych, wymuś reset aktywnych sesji i sprawdź integralność całej platformy. Aktualizacja plików Roundcube nie usuwa webshella pozostawionego poza katalogiem aplikacji.

Powierzchnia ataku: więcej niż numer Roundcube

Warunkiem wejścia jest uwierzytelniona sesja Roundcube, lecz rzeczywista powierzchnia zależy od całego łańcucha logowania i uruchomienia PHP. Publiczny webmail, SSO, reverse proxy, panel hostingowy, wtyczki oraz sposób przechowywania sesji wpływają na możliwość osiągnięcia podatnego kodu i późniejszy skutek.

Inwentaryzacja powinna wykazać, które hostnames i ścieżki kierują do Roundcube, jakie wersje działają na każdym węźle, skąd pochodzi pakiet i czy dystrybucja backportowała poprawkę. Sprawdź także wersję obrazu kontenera, nie tylko nazwę deploymentu. W środowisku autoscaling stary image może ponownie utworzyć podatny pod po prawidłowej aktualizacji jednego węzła.

Następnie ustal model sesji: pliki lokalne, baza, Redis albo inny handler. Root cause dotyczy manipulacji stanem, dlatego lokalizacja, retencja i możliwość korelacji sesji są istotne dla analizy. Nie należy jednak otwierać ani ręcznie deserializować podejrzanych danych w narzędziu, które może wykonać metody obiektu. Kopię analizuj statycznie w odizolowanym środowisku.

Blast radius zależy od konta PHP-FPM, praw do webrootu, wspólnych katalogów tymczasowych, dostępu do bazy i sekretów IMAP/SMTP. Jeżeli kilka witryn działa pod tym samym użytkownikiem systemowym, RCE w Roundcube może naruszyć ich separację. Jeżeli konfiguracja zawiera credentiale techniczne albo master password, rotacja po podejrzeniu incydentu ma wyższy priorytet.

Bezpieczne potwierdzenie ekspozycji bez publicznego PoC

Do decyzji o aktualizacji wystarczą trzy fakty: wersja bez poprawki lub brak potwierdzonego backportu, osiągalny login Roundcube i możliwość utworzenia zwykłego konta/sesji. Nie trzeba przesyłać zserializowanego obiektu.

Bezpieczna procedura wygląda następująco:

odczytaj wersję upstream z pliku programu i wersję pakietu systemowego;
porównaj changelog/advisory dystrybucji z CVE, zamiast oceniać wyłącznie semver;
sprawdź wszystkie repliki, obrazy, backupy aplikacyjne i środowiska staging z kopiami konfiguracji;
potwierdź z zewnętrznej sieci, które adresy prezentują ekran logowania;
wykonaj legalne logowanie kontem testowym i zweryfikuj, że zdarzenie trafia do reverse proxy, Roundcube i systemu tożsamości;
zachowaj dane przed aktualizacją, a później powtórz identyczny test funkcjonalny.

Jeśli aplikacja korzysta z SSO, oceń jej integrację zgodnie z zaleceniami OAuth 2.0 i RFC 9700. Błąd w walidacji issuer, audience albo sesji może obniżyć próg wejścia poniżej zamierzonego „legalnego użytkownika”. To osobna podatność i należy ją raportować oddzielnie, nie jako część CVE-2025-49113.

Triage incydentu Roundcube

Przypadek można podzielić na cztery poziomy:

Poziom A — poprawiona wersja, kompletna historia. Potwierdź aktualny pakiet i zamknij po retestach.
Poziom B — podatna wersja, ale webmail był wiarygodnie nieosiągalny dla niezaufanych użytkowników. Aktualizuj, zachowaj logi i udokumentuj kontrolę dostępu.
Poziom C — podatna publiczna instancja, brak jednoznacznych IoC. Traktuj jako hunting: przejrzyj logowania, sesje, błędy PHP, integralność i egress.
Poziom D — proces potomny PHP, zmieniony plik, nieautoryzowany dostęp do danych lub BEC. Izoluj host, rozpocznij pełny IR i odtwórz system z zaufanego źródła po zabezpieczeniu dowodów.

Wymóg konta nie obniża automatycznie priorytetu. Jeżeli organizacja miała phishing, password spray, infostealer albo słabe MFA, należy skorelować przejęte konta z żądaniami do Roundcube. Skuteczne wdrożenie odpornego na phishing MFA zmniejsza prawdopodobieństwo spełnienia warunku, ale nie zastępuje patcha.

Przy podejrzeniu naruszenia nie resetuj najpierw tylko hasła użytkownika. RCE dotyczy hosta aplikacji. Izoluj warstwę web, utrzymując pocztę przez alternatywny klient, jeśli jest to możliwe. Unieważnij sesje, wymień sekrety aplikacji, zweryfikuj konta systemowe i przeanalizuj reguły forwarding oraz OAuth grants w warstwie pocztowej. Szerszy proces opisuje plan reakcji na wyciek danych.

Telemetria i korelacja śladów

Reverse proxy powinien logować czas, źródło, metodę, ścieżkę, status, rozmiar i identyfikator korelacyjny bez pełnych cookie i sekretów. Roundcube powinien wiązać zdarzenie z lokalnym użytkownikiem oraz sesją. PHP-FPM i EDR pokazują wyjątek, dostęp do pliku, child process i połączenie wychodzące.

Alarm wysokiej wartości łączy zdarzenia w krótkim oknie: zalogowana sesja wysyła nietypowe parametry, PHP zgłasza błąd deserializacji lub modyfikuje plik, a worker PHP uruchamia proces albo rozpoczyna nieznany egress. Każdy element osobno może mieć legalne wyjaśnienie; razem tworzą spójny łańcuch.

File Integrity Monitoring obejmuje kod Roundcube, plugins, konfigurację, pliki startowe PHP, zadania cron i katalogi zapisywalne. Baseline powinien pochodzić z podpisanego pakietu lub obrazu, nie z potencjalnie skompromitowanego hosta. Porównuj hashe oraz właściciela, tryb, extended attributes i czas modyfikacji.

W warstwie pocztowej szukaj masowego odczytu IMAP, nowych reguł przekierowania, wysyłki do nowych domen i wykorzystania konta po resecie. Ochrona Exchange/Microsoft 365 ma własną telemetrię, opisaną w przewodniku bezpieczeństwa Microsoft 365. Wdrożenia z lokalnym IMAP wymagają odpowiedników po stronie serwera pocztowego.

Hardening platformy webmail

Rozdziel Roundcube od innych aplikacji na poziomie konta systemowego, puli PHP i — najlepiej — kontenera/VM. Webroot oraz katalogi wtyczek powinny być tylko do odczytu podczas normalnej pracy. Zapisywalne pozostają wyłącznie jawnie potrzebne lokalizacje, montowane z noexec tam, gdzie system i aplikacja to wspierają.

Ogranicz egress procesu PHP do IMAP/SMTP, bazy, DNS i wymaganych usług. Ruch do Internetu nie powinien być domyślnie dozwolony. Sekrety przechowuj poza webrootem z minimalnymi ACL, a konta bazodanowe ogranicz do konkretnego schematu i operacji.

Usuń nieużywane wtyczki, ponieważ rozszerzają classpath PHP i powierzchnię gadget chains. Każda wtyczka ma właściciela, źródło, wersję i plan aktualizacji. Zasady Zero Trust stosuj również wewnątrz serwera: kod webmaila nie potrzebuje nieograniczonego dostępu do wszystkich podsieci pocztowych.

Weryfikacja poprawki i retest

Po aktualizacji zapisz wersję plików, pakietu i aktywnych workerów PHP. Usuń bytecode/opcache zgodnie z procedurą restartu, aby stare procesy nie utrzymywały podatnego kodu. Dla klastra sprawdź każdy backend oraz image tag i digest użyty przez deployment.

Test funkcjonalny obejmuje logowanie, wylogowanie, wygasanie sesji, wysyłkę, odczyt, książkę adresową i każdą wtyczkę krytyczną. Test bezpieczeństwa powinien potwierdzić, że historycznie problematyczny typ nazwy parametru nie zanieczyszcza sesji — w laboratorium, przy markerze bez gadget chain i bez wykonania polecenia. Produkcja nie jest miejscem do odtwarzania publicznego PoC.

Retest sprawdza także, czy proces PHP nie może zapisać wykonywalnego pliku do webrootu, czy egress jest ograniczony i czy kontrolowane ostrzeżenie PHP trafia do SIEM. Sam brak błędu na ekranie użytkownika nie dowodzi poprawki. Kryterium zamknięcia obejmuje załatany kod, wszystkie repliki, czyste artefakty, rotację w razie podejrzenia i działające detekcje.

Drzewo decyzji dla CVE-2025-49113

Czy wersja jest co najmniej 1.6.11/1.5.10 albo ma udokumentowany backport? Jeśli nie lub nie wiadomo, aktualizuj i zachowaj dowody. Jeśli tak, potwierdź aktywny kod na wszystkich węzłach.
Czy podatna instancja była dostępna dla użytkowników z Internetu lub szerokiej grupy? Jeśli tak, rozpocznij hunting. Jeśli nie, udokumentuj warstwę wymuszającą dostęp.
Czy istnieją konta przejęte w okresie ekspozycji? Jeśli tak, skoreluj ich sesje i zdarzenia z logami aplikacji, niezależnie od obecnego resetu hasła.
Czy PHP uruchomił proces, zmienił kod albo wykonał nietypowy egress? Jeśli tak, pełny IR i odbudowa z zaufanego obrazu. Jeśli nie, oceń kompletność telemetryczną.
Czy zaobserwowano forwarding/BEC lub dostęp do wielu skrzynek? Jeśli tak, rozszerz dochodzenie na całą platformę pocztową, tożsamość i odbiorców.

Jak priorytetyzować tę lukę

Mimo wymogu konta CVSS wynosi 9,9, ponieważ najniższy poziom uprawnień aplikacyjnych wystarcza do uzyskania wpływu na inny komponent — serwer. Dla publicznego webmaila prawdopodobieństwo przejęcia jednego konta jest realne. Priorytet jest szczególnie wysoki, gdy Roundcube współdzieli host z panelem hostingowym, bazą danych albo innymi witrynami.

Organizacje powinny łączyć patchowanie z testami bezpieczeństwa aplikacji webowych i ochroną tożsamości. Pentest może potwierdzić separację tenantów, bezpieczeństwo wtyczek, sesji i granic serwera bez niekontrolowanego używania publicznego exploita.