Luki w LiteSpeed Cache: co zrobić z WordPress i PrestaShop

Co się stało i dlaczego to Cię dotyczy

Według materiału opublikowanego przez CyberFolks 5 listopada 2026 roku, w październiku zeszłego roku ujawniono dwa odrębne problemy bezpieczeństwa dotyczące produktów LiteSpeed Cache. Ważne jest rozróżnienie: WordPress i PrestaShop korzystają z zupełnie innych rozszerzeń, choć oba noszą tę samą nazwę handlową. Pierwsza podatność, oznaczona identyfikatorem CVE-2026-114190, dotyczy wtyczki LiteSpeed Cache for WordPress. Druga, PSV-2026-0001, została wykryta w module LiteSpeed Cache dla PrestaShop i otrzymała od PrestaShield ocenę 9,8 na 10 punktów w skali CVSS 3.1 - co klasyfikuje ją jako zagrożenie krytyczne. Obie luki zostały zgłoszone odpowiednio przez zespół Patchstack (w sierpniu) oraz opublikowane w bazie PrestaShield (30 października), a poprawki wydano w wersjach 7.9.1 (1 września) oraz 1.6.2 (30 października). Jeśli Twoja strona lub sklep korzysta ze starszych wersji, pozostaje narażony na ataki.

Z perspektywy hostingu warto podkreślić: samo posiadanie serwera opartego na oprogramowaniu LiteSpeed nie sprawia, że witryna jest podatna. Zagrożenie dotyczy wyłącznie konkretnych wersji wtyczki lub modułu zainstalowanych w aplikacji. Dlatego kluczowe jest sprawdzenie numeru wersji w panelu administracyjnym (WordPress: Wtyczki - Zainstalowane wtyczki; PrestaShop: Moduły - Menedżer modułów) i porównanie go z wersjami bezpiecznymi. Jeśli hosting oferuje automatyczne aktualizacje wtyczek lub modułów, upewnij się, że mechanizm ten zadziałał - w przypadku krytycznych łuk bezpieczeństwa warto jednak zweryfikować to ręcznie.

WordPress: CVE-2026-114190 - ujawnienie danych administratora

Podatność w wtyczce dla WordPressa ma charakter ujawnienia poufnych danych (Sensitive Data Exposure). Zgodnie z informacjami ze źródła, do jej wykorzystania musi dojść jednocześnie kilka warunków: włączone buforowanie REST API w ustawieniach LiteSpeed Cache, korzystanie z prostego formatu bezpośrednich odnośników (Plain Permalinks) oraz istnienie zewnętrznej integracji - np. aplikacji mobilnej, systemu headless lub narzędzia do kopii zapasowych - która uwierzytelnia się hasłem aplikacji, wykonuje żądania REST API z uprawnieniami administratora i nie korzysta z ciasteczek sesyjnych. W takim scenariuszu odpowiedź API zawierająca dane przeznaczone dla administratora może trafić do publicznej pamięci podręcznej. Osoba nieuprawniona może następnie pobrać te informacje bez logowania. Producent informuje, że dane mogą pozostać w cache przez okres określony w konfiguracji REST API Cache - domyślnie nawet przez 7 dni. Co istotne, automatyczne czyszczenie wykonywane przez cron nie usuwa problematycznego wpisu w opisanym scenariuszu, dlatego po aktualizacji konieczne jest ręczne wyczyszczenie całej pamięci podręcznej (opcja Purge All).

Producent zaleca aktualizację wszystkim użytkownikom wtyczki, niezależnie od tego, czy ich witryna spełnia warunki umożliwiające wykorzystanie podatności. To dobra praktyka bezpieczeństwa: łatki często zawierają dodatkowe zabezpieczenia prewencyjne, które chronią przed wariantami ataku nieprzewidzianymi w momencie publikacji. Z perspektywy hostingu dodajmy, że warto sprawdzić, czy Twoja konfiguracja permalinków nie jest ustawiona na "Zwykłe" (Plain) - nowoczesne struktury odnośników są bezpieczniejsze i lepiej współgrają z mechanizmami cache. Jeśli korzystasz z integracji headless lub aplikacji mobilnych, przejrzyj ich sposób uwierzytelniania i rozważ ograniczenie uprawnień kont używanych do API.

PrestaShop: PSV-2026-0001 - zdalne wykonanie kodu bez uwierzytelnienia

Sytuacja w przypadku PrestaShop jest znacznie poważniejsza. Podatność PSV-2026-0001 dotyczy mechanizmu ESI (Edge Side Includes), który pozwala niezależnie przetwarzać i buforować fragmenty strony. W wersjach starszych niż 1.6.2 brakowało odpowiedniej kontroli parametrów przekazywanych do ESI. Atakujący mógł manipulować tymi danymi, wpływając na wybór szablonu Smarty oraz uruchamianych metod modułu, co w określonych warunkach prowadziło do zdalnego wykonania kodu na serwerze bez konieczności logowania. Według PrestaShield pojawiły się publiczne zgłoszenia dotyczące możliwego wykorzystania luki w sklepach na wersji 1.6.1 - opisywano tworzenie nieautoryzowanych kont administratorów, instalowanie nieznanych plików PHP i modułów. LiteSpeed nie potwierdził tych doniesień, jednak sama natura podatności (RCE bez autentykacji, CVSS 9.8) wymaga natychmiastowej reakcji.

Kluczowa informacja z komunikatu producenta: sama aktualizacja do wersji 1.6.2 usuwa podatność, ale nie usuwa złośliwego kodu ani nieautoryzowanych kont, jeśli sklep został już wcześniej zainfekowany. Dlatego po aktualizacji konieczne jest przeprowadzenie audytu bezpieczeństwa: sprawdzenie listy kont pracowników i administratorów, weryfikacja ostatnio zainstalowanych lub zmienionych modułów, przegląd plików PHP pod kątem nieznanych zmian, analiza logów serwera i panelu sklepu pod kątem nietypowej aktywności. W razie podejrzenia włamania należy unieważnić aktywne sesje zaplecza oraz zmienić hasła i inne dane uwierzytelniające. Usunięcie samego podejrzanego pliku może nie wystarczyć, jeśli atakujący uzyskał dodatkowy dostęp (np. backdoory w innych lokalizacjach).

Dobre praktyki hostingowe: jak zminimalizować ryzyko w przyszłości

Opisane incydenty pokazują, że nawet popularne, rozwijane przez lata rozwiązania do optymalizacji wydajności mogą zawierać błędy krytyczne. Z perspektywy HostGrade.pl warto wdrożyć kilka nawyków, które ograniczają powierzchnię ataku i ułatwiają reakcję na incydenty. Po pierwsze: regularne aktualizacje nie tylko rdzenia CMS (WordPress, PrestaShop), ale też wszystkich wtyczek, modułów i motywów. Wiele hostingu oferuje narzędzia do automatyzacji tego procesu - warto je włączyć lub ustawić przypomnienia. Po drugie: kopie zapasowe wykonywane codziennie i przechowywane w oddzielnej lokalizacji (off-site) to fundament odzyskiwalności. Jeśli wykryjesz infekcję po aktualizacji, czysta kopia sprzed incydentu pozwala przywrócić stan znany jako bezpieczny. Po trzecie: środowisko stagingowe do testowania aktualizacji przed wdrożeniem na produkcję - pozwala wykryć konflikty i błędy bez ryzyka dla działającego sklepu lub strony. Po czwarte: monitorowanie integralności plików (np. narzędzia typu Tripwire, AIDE lub wtyczki bezpieczeństwa skanujące zmiany w kodzie) daje wczesne ostrzeżenie o nieautoryzowanych modyfikacjach.

Warto też pamiętać o zasadzie najmniejszych uprawnień: konta API, hasła aplikacji, konta bazodanowe i FTP powinny mieć tylko te uprawnienia, które są im niezbędne. W przypadku PrestaShop ograniczenie dostępu do panelu administracyjnego po IP lub przez VPN, wyłączenie niepotrzebnych modułów i regularny przegląd logów serwera (access/error log) to standardy, które drastycznie zmniejszają szansę na pomyślny atak. Jeśli Twój hosting oferuje WAF (Web Application Firewall) z regułami blokującymi znane wzorce ataków na ESI lub REST API, upewnij się, że jest on aktywny i aktualizowany. To dodatkowa warstwa ochrony, która może zablokować próbę wykorzystania luki jeszcze zanim trafi do aplikacji.

Jeśli szukasz hostingu, który oferuje automatyczne kopie zapasowe, środowisko stagingowe i WAF w standardzie, CyberFolks daje to bez dodatkowych kosztów.

Jeśli chcesz zgłębić temat, zajrzyj też do naszych powiązanych poradników: Dlaczego backup to podstawa bezpieczeństwa, Hosting zoptymalizowany pod PrestaShop, Bezpieczeństwo WordPress na hostingu, LiteSpeed vs Apache vs Nginx - co wybrać.

Najczęstsze pytania