Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W aplikacji Horilla w wersji 1.3 ujawniono krytyczną podatność typu authenticated remote code execution, oznaczoną jako CVE-2025-48868. Luka wynika z niebezpiecznego użycia mechanizmu dynamicznej ewaluacji kodu, co pozwala zalogowanemu użytkownikowi z odpowiednimi uprawnieniami doprowadzić do wykonania poleceń systemowych na serwerze.
Problem dotyczy funkcji zbiorczej archiwizacji projektów i wpisuje się w dobrze znany antywzorzec bezpieczeństwa: przekazywanie danych wejściowych użytkownika do funkcji eval() bez ścisłej walidacji oraz bezpiecznego modelu przetwarzania.
W skrócie
- Podatność dotyczy Horilla w wersjach do 1.3 włącznie.
- Luka została oznaczona jako CVE-2025-48868.
- Atak wymaga wcześniejszego uwierzytelnienia, ale nie wymaga interakcji ofiary.
- Źródłem problemu jest dynamiczne wykonanie danych kontrolowanych przez użytkownika.
- Skutkiem może być pełne wykonanie kodu na serwerze aplikacyjnym.
Kontekst / historia
Horilla to otwartoźródłowy system HRM wykorzystywany do obsługi procesów kadrowych i administracyjnych. Tego typu platformy często przechowują dane osobowe pracowników, informacje organizacyjne oraz konfiguracje integracji z innymi systemami wewnętrznymi, dlatego każda podatność prowadząca do RCE ma szczególnie wysoki ciężar operacyjny.
W przypadku CVE-2025-48868 publicznie opisano scenariusz eksploatacji wskazujący na problem w widoku odpowiedzialnym za operację project_bulk_archive. Klasyfikacja CWE-95 potwierdza, że chodzi o niewłaściwą neutralizację dyrektyw w kodzie dynamicznie ewaluowanym, co w praktyce otwiera drogę do wstrzyknięcia i wykonania wyrażeń Pythona po stronie serwera.
Analiza techniczna
Techniczny rdzeń podatności sprowadza się do tego, że parametr żądania HTTP może zostać wykorzystany do dostarczenia spreparowanego wyrażenia interpretowanego przez eval(). Publiczny proof-of-concept wskazuje, że szczególne znaczenie ma parametr is_active używany w żądaniu kierowanym do endpointu odpowiedzialnego za archiwizację projektów.
Przykładowy łańcuch ataku obejmuje zalogowanie się do aplikacji, utrzymanie ważnej sesji i tokena CSRF, utworzenie pomocniczego rekordu projektu, a następnie wysłanie żądania POST z odpowiednio przygotowaną wartością parametru wejściowego. Jeżeli serwer interpretuje tę wartość jako kod, atakujący może uruchomić polecenie systemowe w kontekście procesu aplikacji.
To sprawia, że luka nie ogranicza się do naruszenia logiki biznesowej. W najgorszym scenariuszu umożliwia przejęcie hosta aplikacyjnego, odczyt sekretów, dostęp do bazy danych, a także dalszy ruch boczny w środowisku. Dodatkowym utrudnieniem dla zespołów obronnych jest fakt, że ruch wykorzystywany w ataku może wyglądać jak zwykła, poprawna operacja aplikacyjna, z prawidłowymi ciasteczkami sesyjnymi i standardowymi nagłówkami HTTP.
Konsekwencje / ryzyko
Najważniejszym skutkiem CVE-2025-48868 jest możliwość wykonania dowolnego kodu na serwerze przez uwierzytelnionego użytkownika. To oznacza nie tylko ryzyko przejęcia samej aplikacji, ale także naruszenia poufności danych kadrowych, konfiguracji środowiska i poświadczeń przechowywanych przez system.
- odczyt danych pracowniczych i biznesowych,
- pozyskanie sekretów, kluczy API i danych dostępowych,
- modyfikacja rekordów oraz ustawień aplikacji,
- instalacja backdoora lub mechanizmów persistence,
- wykorzystanie serwera jako punktu wyjścia do dalszej penetracji sieci.
Choć podatność wymaga logowania, nie obniża to znacząco jej wagi. W realnych środowiskach konto użytkownika może zostać przejęte przez phishing, ponowne użycie haseł, credential stuffing albo nadużycie przez użytkownika wewnętrznego. W takim modelu authenticated RCE bardzo szybko staje się incydentem krytycznym.
Rekomendacje
Priorytetem powinno być niezwłoczne wdrożenie poprawki i potwierdzenie, że środowiska nie działają już na podatnych wersjach. Organizacje korzystające z Horilla powinny również ocenić, czy nie doszło już do prób eksploatacji oraz czy aplikacja nie działa z nadmiernymi uprawnieniami systemowymi.
- zaktualizować Horilla do wersji zawierającej poprawkę,
- usunąć lub zastąpić niebezpieczne użycie
eval()i podobnych mechanizmów, - przeprowadzić przegląd logów HTTP i operacji związanych z archiwizacją projektów,
- ograniczyć uprawnienia procesu aplikacyjnego oraz kont serwisowych,
- wdrożyć segmentację sieci i separację zasobów krytycznych,
- monitorować nietypowe parametry wejściowe zawierające składnię Pythona,
- rotować sekrety i poświadczenia w przypadku podejrzenia kompromitacji,
- włączyć MFA dla kont uprzywilejowanych i administracyjnych.
Z perspektywy detekcji warto zwrócić uwagę na nietypowe żądania do endpointów projektowych, uruchamianie interpreterów lub narzędzi sieciowych przez proces webowy oraz nagłe połączenia wychodzące z serwera aplikacyjnego.
Podsumowanie
CVE-2025-48868 w Horilla v1.3 pokazuje, jak pojedynczy błąd projektowy związany z dynamiczną ewaluacją danych wejściowych może przerodzić się w pełne wykonanie kodu po stronie serwera. Mimo wymogu uwierzytelnienia wpływ tej luki pozostaje bardzo poważny, ponieważ umożliwia atakującemu przejęcie warstwy aplikacyjnej i potencjalne rozszerzenie kompromitacji na dalsze elementy infrastruktury.
Dla zespołów bezpieczeństwa i administratorów oznacza to konieczność szybkiego patchowania, retrospektywnej analizy logów oraz oceny, czy legalne konta użytkowników nie zostały już wykorzystane do nadużyć.
Źródła
- Exploit Database: Horilla v1.3 – RCE – https://www.exploit-db.com/exploits/52497
- NVD – CVE-2025-48868 – https://nvd.nist.gov/vuln/detail/CVE-2025-48868
- GitHub Security Advisory: Horilla vulnerable to authenticated RCE via eval() in project_bulk_archive – https://github.com/horilla-opensource/horilla/security/advisories/GHSA-h6qj-pwmx-wjhw
- Horilla commit addressing the issue – https://github.com/horilla-opensource/horilla/commit/b0aab62b3a5fe6b7114b5c58db129b3744b4d8cc