Wprowadzenie do problemu / definicja
W aplikacji RomM, wykorzystywanej do samohostowanego zarządzania kolekcjami ROM-ów, wykryto krytyczną podatność oznaczoną jako CVE-2025-65027. Problem wynika z połączenia dwóch błędów bezpieczeństwa: możliwości przesyłania aktywnych plików HTML prowadzącej do XSS oraz niewłaściwej obsługi mechanizmu CSRF. W praktyce taki łańcuch podatności pozwala użytkownikowi o niskich uprawnieniach doprowadzić do przejęcia konta administratora.
Scenariusz ataku nie wymaga zdalnego wykonania kodu po stronie serwera. Wystarczy zwykłe konto w aplikacji, możliwość przesłania pliku oraz nakłonienie ofiary do otwarcia przygotowanego zasobu. To sprawia, iż zagrożenie jest szczególnie istotne dla środowisk self-hosted, gdzie dostęp użytkowników bywa szeroki, a kontrola nad przesyłanymi plikami ograniczona.
W skrócie
Podatność dotyczy wersji RomM wcześniejszych niż 4.4.1. Atakujący z kontem o niskich uprawnieniach może przesłać złośliwy plik HTML, uzyskać do niego bezpośredni odnośnik i skłonić administratora do jego otwarcia.
Po uruchomieniu złośliwego kodu w kontekście aplikacji możliwe staje się nadpisanie tokena CSRF i wysłanie żądania zmiany hasła ofiary. Efektem może być pełne przejęcie konta administracyjnego i dalsza kompromitacja środowiska.
Kontekst / historia
Łańcuch ataku został publicznie opisany jako exploit dla RomM 4.4.0 oraz wcześniejszych wydań przed 4.4.1. Zgłoszenie powiązano z identyfikatorem CVE-2025-65027, a publicznie dostępny proof of concept pokazał, iż problem nie jest pojedynczym błędem, ale skutkiem zestawienia kilku słabości architektonicznych.
Kluczowe znaczenie ma tutaj akceptowanie aktywnej zawartości HTML w plikach użytkownika, możliwość bezpośredniego otwierania tych zasobów oraz niewystarczająca odporność modelu anty-CSRF. W materiałach dotyczących wydania 4.4.1 wskazano, iż wersja ta zawiera poprawki bezpieczeństwa odnoszące się do tej klasy problemów.
Analiza techniczna
Atak rozpoczyna się od zalogowania się do aplikacji przez użytkownika z ograniczonymi uprawnieniami, na przykład z rolą Viewer. Następnie napastnik przygotowuje plik HTML zawierający złośliwy kod JavaScript i przesyła go do systemu jako element profilu lub inny zasób użytkownika.
Jeżeli aplikacja przechowuje taki plik pod publicznie dostępnym adresem i serwuje go bez odpowiednich ograniczeń bezpieczeństwa, przeglądarka ofiary renderuje dokument jako aktywną treść. W efekcie skrypt uruchamia się w kontekście sesji ofiary, co tworzy warunki do wykonania kolejnego etapu łańcucha.
Kluczowym elementem exploita jest możliwość nadpisania wartości tokena CSRF przechowywanego w ciasteczku. Po ustawieniu wartości kontrolowanej przez napastnika skrypt wysyła żądanie do endpointu odpowiedzialnego za modyfikację danych użytkownika, dołączając zgodny nagłówek i sesyjne cookie ofiary. o ile backend akceptuje taki model walidacji, ochrona przed CSRF zostaje skutecznie ominięta.
W publicznie opisanym scenariuszu celem żądania jest zmiana hasła konta o określonym identyfikatorze. o ile administrator ma przewidywalny identyfikator, a aplikacja nie wprowadza dodatkowych zabezpieczeń przy operacjach uprzywilejowanych, końcowym rezultatem może być pełne przejęcie konta administratora.
- wejście: konto o niskich uprawnieniach w RomM,
- etap pierwszy: upload złośliwego pliku HTML,
- etap drugi: uruchomienie JavaScript po otwarciu zasobu przez ofiarę,
- etap trzeci: nadpisanie tokena CSRF i wysłanie żądania zmiany hasła,
- rezultat: przejęcie konta administratora.
Konsekwencje / ryzyko
Z perspektywy organizacji ryzyko należy ocenić jako wysokie. Podatność umożliwia eskalację z konta o minimalnych uprawnieniach do pełnej kontroli nad aplikacją administracyjną.
Przejęcie konta administratora może prowadzić do zmiany konfiguracji systemu, manipulacji zasobami, dostępu do danych użytkowników, a także dalszego ruchu bocznego w środowisku. W instalacjach self-hosted, gdzie jedna aplikacja bywa osadzona w większym ekosystemie usług, skutki mogą wykraczać poza sam RomM.
Dodatkowym problemem jest niski próg wejścia dla atakującego. Nie jest wymagane wykonanie kodu na serwerze ani złożone obejście mechanizmów przeglądarki. Wystarczające okazuje się połączenie błędnej obsługi uploadu z podatnym modelem ochrony CSRF i interakcją użytkownika.
Rekomendacje
Najważniejszym działaniem naprawczym jest natychmiastowa aktualizacja RomM do wersji 4.4.1 lub nowszej. Organizacje korzystające z wcześniejszych wersji powinny potraktować ten krok priorytetowo, zwłaszcza jeżeli użytkownicy nieadministracyjni mają możliwość przesyłania plików.
Poza aktualizacją warto wdrożyć dodatkowe środki ochronne, które ograniczą ryzyko podobnych incydentów w przyszłości.
- zablokować upload plików HTML, SVG oraz innych formatów zdolnych do wykonywania aktywnej treści,
- wymuszać bezpieczne nagłówki odpowiedzi i prawidłowy typ Content-Type dla plików użytkownika,
- serwować treści użytkowników z odseparowanej domeny lub subdomeny bez współdzielonych cookies,
- przeprojektować walidację CSRF tak, aby token nie mógł zostać skutecznie nadpisany i ponownie użyty,
- ograniczyć bezpośredni dostęp do przesłanych plików lub neutralizować je po stronie serwera,
- przeanalizować logi pod kątem nietypowych zmian haseł, modyfikacji kont i odwołań do zasobów HTML,
- zresetować hasła kont uprzywilejowanych, jeżeli istnieje podejrzenie wykorzystania podatności.
Z perspektywy deweloperskiej warto traktować cały obszar uploadu treści użytkownika jako strefę podwyższonego ryzyka. Każdy plik, który może zostać wyrenderowany przez przeglądarkę, powinien być analizowany pod kątem XSS, izolacji origin, polityki cookies i interakcji z mechanizmami sesyjnymi.
Podsumowanie
CVE-2025-65027 w RomM jest przykładem tego, jak połączenie pozornie odrębnych błędów może doprowadzić do krytycznego incydentu. Sam upload pliku HTML nie zawsze oznacza pełną kompromitację, podobnie jak niedoskonała walidacja CSRF nie musi automatycznie prowadzić do przejęcia konta.
Jednak zestawienie obu słabości w jednym łańcuchu ataku otwiera drogę do przejęcia konta administratora przez zwykłego użytkownika aplikacji. Dla administratorów i twórców systemu to wyraźny sygnał, iż bezpieczeństwo uploadu, izolacja treści użytkownika i mechanizmy anty-CSRF muszą być projektowane jako jeden spójny model ochrony.
Źródła
- Exploit-DB: RomM 4.4.0 – XSS_CSRF Chain — https://www.exploit-db.com/exploits/52505
- NVD: CVE-2025-65027 — https://nvd.nist.gov/vuln/detail/CVE-2025-65027
- RomM Releases on GitHub — https://github.com/rommapp/romm/releases
- RomM GitHub Repository — https://github.com/rommapp/romm
- Technical write-up by the exploit author — https://he4am.medium.com/bypassing-samesite-protection-chaining-xss-and-csrf-for-admin-ato-in-romm-44d910c54403