Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W ekosystemie systemów CMS jedną z najgroźniejszych klas błędów pozostaje nieograniczone przesyłanie plików. Tego typu podatność występuje wtedy, gdy aplikacja akceptuje pliki bez skutecznej walidacji ich typu, rozszerzenia lub zawartości. W praktyce może to otworzyć drogę do wgrania pliku wykonywalnego na serwer i doprowadzić do zdalnego wykonania kodu.
W przypadku Bludit problem dotyczył wtyczki API i umożliwiał uwierzytelnionemu atakującemu, posiadającemu ważny token API, przesłanie pliku PHP, a następnie jego uruchomienie na serwerze. Luka została powiązana z CVE-2026-25099 i usunięta w wersji 3.18.4.
W skrócie
- Podatność dotyczy Bludit w wersjach wcześniejszych niż 3.18.4.
- Błąd wynika z niewystarczającej walidacji plików przesyłanych przez endpoint API.
- Atakujący z ważnym tokenem API może wgrać plik PHP i uzyskać zdalne wykonanie kodu.
- Publiczny proof of concept pokazuje pełny łańcuch ataku, od pozyskania identyfikatora strony po uruchomienie poleceń systemowych.
- Producent usunął problem w wydaniu 3.18.4.
Kontekst / historia
Bludit to lekki, plikowy system CMS wykorzystywany do obsługi blogów, stron firmowych i mniejszych serwisów internetowych. Takie rozwiązania są często wdrażane w klasycznych środowiskach hostingowych, gdzie serwer WWW interpretuje skrypty znajdujące się w katalogach dostępnych z poziomu HTTP.
Opisana podatność została oznaczona jako CVE-2026-25099 i sklasyfikowana w kategorii CWE-434, czyli unrestricted upload of file with dangerous type. To szczególnie niebezpieczna klasa błędów, ponieważ pozwala przejść od ograniczonego dostępu aplikacyjnego do pełnego wykonywania poleceń na serwerze.
Choć wykorzystanie luki wymaga ważnego tokenu API, nie obniża to znacząco ryzyka operacyjnego. Tokeny mogą zostać ujawnione przez błędną konfigurację, wycieki sekretów, nadmierne uprawnienia lub wcześniejszą kompromitację kont administracyjnych. W praktyce taki błąd może stanowić szybki etap eskalacji po uzyskaniu dostępu do warstwy aplikacyjnej.
Analiza techniczna
Techniczna przyczyna podatności sprowadza się do braku odpowiedniej kontroli nad plikami przesyłanymi przez API. Endpoint odpowiedzialny za upload przyjmował dane metodą POST i zapisywał je bez skutecznego sprawdzenia, czy plik ma bezpieczne rozszerzenie i czy jego zawartość odpowiada deklarowanemu typowi.
W praktyce oznaczało to możliwość przesłania pliku PHP zawierającego prosty webshell. Publicznie udostępniony proof of concept pokazuje, że atakujący może najpierw pobrać z API identyfikator strony, a następnie użyć go podczas wysyłania złośliwego pliku do odpowiedniego endpointu uploadu.
Jeżeli serwer zapisuje taki plik w katalogu publicznie dostępnym i interpretuje rozszerzenie jako wykonywalny skrypt, napastnik może wywołać plik przez HTTP i przekazać parametry pozwalające wykonywać komendy systemowe. To klasyczny scenariusz prowadzący do zdalnego wykonania kodu z uprawnieniami procesu serwera WWW.
Przypadek Bludit pokazuje też istotny problem projektowy: sama kontrola dostępu nie wystarcza, jeśli aplikacja nie zabezpiecza samej operacji. System może poprawnie rozpoznawać, kto ma prawo wysyłać pliki, ale jednocześnie nie weryfikować, jakie pliki są dopuszczalne i czy ich zapisanie nie stworzy bezpośredniej ścieżki do wykonania kodu.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją wykorzystania tej luki jest pełne zdalne wykonanie kodu na serwerze aplikacji. Po skutecznym przesłaniu i uruchomieniu webshella atakujący może wykonywać polecenia systemowe, przeglądać pliki konfiguracyjne, modyfikować treści witryny, kraść dane i instalować mechanizmy trwałego dostępu.
Ryzyko rośnie w środowiskach, w których instancja CMS ma dostęp do dodatkowych zasobów, takich jak bazy danych, pamięci podręczne, repozytoria plików lub usługi administracyjne. W takich przypadkach pojedynczy webshell może stać się punktem wejścia do szerszej kompromitacji infrastruktury.
Znaczenie luki wzmacnia również fakt publicznej dostępności kodu PoC. Gdy exploit jest łatwo osiągalny, maleje próg wejścia dla atakujących, a organizacje utrzymujące podatne wersje oprogramowania powinny liczyć się ze wzrostem prób automatycznego lub półautomatycznego wykorzystania błędu.
Rekomendacje
Podstawowym działaniem naprawczym jest niezwłoczna aktualizacja Bludit do wersji 3.18.4 lub nowszej. Sama aktualizacja nie powinna jednak kończyć procesu reagowania, zwłaszcza jeśli system był dostępny publicznie lub jeśli środowisko wykorzystywało aktywnie interfejs API.
- zweryfikować, czy wtyczka API jest rzeczywiście potrzebna i wyłączyć ją tam, gdzie nie jest używana,
- przeprowadzić rotację wszystkich tokenów API oraz przegląd kont administracyjnych,
- skontrolować katalogi uploadu pod kątem obecności plików skryptowych, zwłaszcza plików PHP,
- przeanalizować logi HTTP i logi aplikacyjne pod kątem żądań do endpointów listowania stron oraz uploadu plików,
- zablokować wykonywanie skryptów w katalogach przeznaczonych na przesyłane pliki,
- wdrożyć walidację opartą na rozszerzeniu, typie MIME oraz inspekcji zawartości pliku,
- ograniczyć ekspozycję panelu administracyjnego i API z użyciem ACL, VPN lub segmentacji administracyjnej,
- włączyć monitoring nowych plików w katalogach publicznych oraz anomalii związanych z procesem serwera WWW.
Jeżeli istnieje choćby podejrzenie kompromitacji, serwer należy traktować jako potencjalnie przejęty. W takiej sytuacji zalecane są izolacja hosta, analiza artefaktów poeksploatacyjnych, weryfikacja mechanizmów persistence, zmiana poświadczeń oraz odbudowa systemu z zaufanego źródła po zakończeniu działań śledczych.
Podsumowanie
CVE-2026-25099 w Bludit to przykład podatności, w której pozornie ograniczony mechanizm uploadu staje się bezpośrednią drogą do zdalnego wykonania kodu. Połączenie ważnego tokenu API z brakiem ścisłej walidacji plików tworzy scenariusz szczególnie niebezpieczny dla środowisk produkcyjnych.
Dla administratorów oznacza to konieczność szybkiej aktualizacji do wersji 3.18.4 lub nowszej, przeglądu tokenów API, analizy śladów potencjalnego wykorzystania oraz wdrożenia dodatkowych zabezpieczeń wokół uploadu i ekspozycji interfejsów administracyjnych.
Źródła
- Exploit Database – Bludit CMS 3.18.4 – RCE
https://www.exploit-db.com/exploits/52553 - NVD – CVE-2026-25099 Detail
https://nvd.nist.gov/vuln/detail/CVE-2026-25099 - CERT Polska – CVE-2026-25099
https://cert.pl/posts/2026/03/CVE-2026-25099/ - Bludit – Release 3.18.4
https://github.com/bludit/bludit/releases/tag/3.18.4