Czy moja strona na WordPressie jest zagrożona przez PHP2Shell?

Zagrożona jest każda strona działająca na niezałatanej wersji PHP, niezależnie od systemu CMS. Na hostingu współdzielonym poprawki instaluje firma hostingowa, a duże polskie hostingi ogłosiły 21 i 22 października 2026, że je wdrożyły. Warto to potwierdzić w komunikacie lub u obsługi hostingu.

Które wersje PHP są bezpieczne?

PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12 oraz nowsze. Starsze wersje są bezpieczne tylko wtedy, gdy hosting lub dystrybucja Linuksa wgrali do nich poprawkę (backport). Numer wersji nie zmienia się wtedy, dlatego trzeba to potwierdzić u dostawcy.

Czy wystarczy wyłączyć session.upload_progress.enabled?

Nie. To ustawienie blokuje znaną ścieżkę ataku na jedną z dwóch luk (CVE-2026-109619). Projekt PHP i CERT Polska podkreślają, że ustawienia zastępcze nie zabezpieczają instalacji w pełni, a jedyną skuteczną metodą jest aktualizacja PHP.

Czy luki są już wykorzystywane przez przestępców?

Firmy zajmujące się bezpieczeństwem i CERT Polska informują o skanowaniu i próbach wykorzystania od 21 października 2026. Do 22 października w otwartych źródłach nie było potwierdzonych przypadków udanych włamań, a projekt PHP nie zgłaszał wykorzystania luk w praktyce.

Czy PHP 7.4 lub 8.1 dostanie poprawkę?

Projekt PHP nie wydaje już nowych wersji tych gałęzi, ale udostępnił minimalne poprawki źródłowe dla 7.4, 8.0 i 8.1, a dystrybucje i hostingi mogą je wdrożyć jako backport. Niezależnie od tego warto zaplanować przejście na wspieraną wersję PHP.

PHP2Shell (CVE-2026-109618, CVE-2026-109619): jak sprawdzić serwer?

Name: WDesign
Address: ul. Kalwaryjska 2a/5, Piekary Śląskie, śląskie, 41-940, PL
Telephone: +48 601 999 178
Rating: 4.9

21 października 2026 roku projekt PHP wydał awaryjne wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają one dwie krytyczne podatności, CVE-2026-109618 i CVE-2026-109619, które w określonych warunkach pozwalają wykonać kod na serwerze bez logowania. Odkrywcy nazwali je PHP2Shell. Według W3Techs PHP obsługuje 69,3% stron, których język po stronie serwera da się ustalić, więc sprawa dotyczy także stron firmowych i sklepów na WordPressie, WooCommerce, PrestaShop czy Joomli.

Poniżej wyjaśniamy, co wiadomo na pewno, co jest na razie tylko doniesieniem, jak sprawdzić swój serwer i co zrobić. Osobną część poświęcamy WordPressowi: dlaczego strony na tym systemie są częstszym celem i jak luka w samym PHP łączy się z problemami wtyczek.

W skrócie:

Bezpieczne są wersje PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12 oraz nowsze, a także starsze wersje z poprawką wgraną przez hosting lub dystrybucję (tzw. backport).
Na hostingu współdzielonym poprawki instaluje firma hostingowa. Duże polskie hostingi ogłosiły 21 i 22 października, że je wdrożyły.
Na własnym VPS lub serwerze dedykowanym aktualizacja i restart PHP są po stronie administratora.
Ustawienia zastępcze (np. wyłączenie session.upload_progress.enabled) zmniejszają ryzyko, ale według projektu PHP nie zabezpieczają instalacji w pełni.

Co się stało 21 października 2026 roku?

20 października projekt PHP zapowiedział na swojej stronie krytyczne wydanie bezpieczeństwa na następny dzień i zastrzegł, że może je przyspieszyć, gdyby szczegóły wyciekły albo pojawiły się ataki. Według firm zajmujących się bezpieczeństwem informacje o lukach rzeczywiście zaczęły krążyć przed planowaną datą, dlatego publikację przyspieszono.

21 października ukazały się wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Projekt PHP napisał wprost, że naprawiają one dwie krytyczne podatności pozwalające na zdalne wykonanie kodu bez uwierzytelnienia i że wszyscy użytkownicy powinni zaktualizować PHP natychmiast. Tego samego dnia komunikat opublikował CERT Polska, a sprawę opisał m.in. Sekurak.

Luki znaleźli badacze z firmy Wiz, którzy według własnego opisu zgłosili pierwszą z nich zespołowi PHP pod koniec sierpnia 2026. Nazwa PHP2Shell pochodzi od nich. Projekt PHP w oficjalnym komunikacie posługuje się numerami CVE i nazwami technicznymi.

Na czym polegają luki CVE-2026-109618 i CVE-2026-109619?

Obie podatności dotyczą samego silnika PHP, a nie konkretnej aplikacji. Oznacza to, że problem nie wynika z błędu w kodzie strony, tylko z tego, jak interpreter obsługuje żądania. Nie podajemy szczegółów technicznych pozwalających odtworzyć atak. Opis ogólny wygląda tak:

Identyfikator	Nazwa w komunikacie PHP	Na czym polega (ogólnie)
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)	RCE via OOM corruption	Błąd w obsłudze sytuacji, w której PHP zabraknie pamięci w trakcie przetwarzania żądania. Wewnętrzne dane zostają wtedy w niespójnym stanie.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)	RCE via stale global state	Proces PHP może po jednym żądaniu zachować odwołanie do zwolnionej już pamięci, z którego może skorzystać kolejne żądanie. Skutkiem może być ujawnienie zawartości pamięci albo wykonanie kodu.

Do przeprowadzenia ataku wystarczy dostęp do strony przez internet. Nie jest potrzebne konto ani działanie użytkownika. Kod wykonuje się z uprawnieniami konta, na którym działa serwer WWW, czyli w praktyce z dostępem do plików strony, konfiguracji i często danych dostępowych do bazy.

Kogo dotyczą luki PHP2Shell?

Według projektu PHP zagrożone są wszystkie instalacje PHP obsługujące żądania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Największe ryzyko projekt PHP przypisuje konfiguracji z mod_php. W komunikacie na liście oss-security zespół bezpieczeństwa PHP podał, że zdalne wykonanie kodu bez logowania zademonstrowano na Apache z mod_php i na PHP-FPM. Żadne z oficjalnych źródeł nie wymienia PHP uruchamianego z wiersza poleceń (CLI) jako zagrożonego.

Oficjalnie podatne są wszystkie wersje gałęzi 8.2, 8.3, 8.4 i 8.5 przed wydaniami z 21 października. Starsze wersje nie są wspierane przez projekt PHP i nie dostaną nowych wydań, ale zespół PHP udostępnił minimalne poprawki źródłowe dla gałęzi 7.4, 8.0 i 8.1, a dystrybucje Linuksa i dostawcy wsparcia rozszerzonego otrzymali łatki wcześniej. Odkrywcy i CERT Polska podają, że podatne są wersje od PHP 5.4 w górę. Jedna z firm badawczych pisze nawet o wersjach od PHP 5. Projekt PHP nie określa formalnie zakresu dla wersji, których już nie wspiera.

W praktyce oznacza to, że stara wersja PHP na hostingu nie chroni przed tymi lukami, tylko utrudnia ocenę, czy poprawka w ogóle została wgrana.

Jak groźne są te luki naprawdę?

Projekt PHP ocenił obie podatności na 9.2 w skali CVSS 4.0, czyli jako krytyczne. W tej samej ocenie zaznaczono jednak wysoką złożoność ataku i potrzebę spełnienia dodatkowych warunków. Inne instytucje oceniają ryzyko różnie: amerykańska baza NVD podaje 9.8 w starszej skali CVSS 3.1, a Red Hat ocenia lukę na 8.1 i pisze, że na standardowej konfiguracji RHEL z PHP-FPM wykonanie kodu jest w praktyce trudne, a wyższe ryzyko dotyczy mod_php.

Co jest potwierdzone, a co jest doniesieniem?

Potwierdzone przez projekt PHP: istnienie obu luk, możliwość zdalnego wykonania kodu bez logowania, zademonstrowany exploit oraz lista poprawionych wersji.
Doniesienia firm bezpieczeństwa: watchTowr informuje o zaobserwowanych próbach wykorzystania od 21 października. Patchstack rano tego dnia pisał o zgłoszeniach od partnerów hostingowych, a po południu doprecyzował, że widzi skanowanie i próby, ale nie twarde dowody włamań. CERT Polska wspomina o pierwszej fali masowych prób wykorzystania.
Stan oficjalnych rejestrów na 22 października: w bazie NVD ocena wykorzystania w praktyce wynosi „none”, a luki nie trafiły do katalogu znanych wykorzystywanych podatności CISA.

Rzetelne podsumowanie: luki są poważne, skanowanie internetu w ich poszukiwaniu trwa, ale do 22 października w otwartych źródłach nie ma potwierdzonych przypadków udanych włamań. To dobry moment, żeby spokojnie sprawdzić swój serwer, a nie powód do paniki.

Jak sprawdzić, czy serwer jest załatany?

Najprostsza metoda, czyli sprawdzenie numeru wersji, działa tylko częściowo. Wiele firm hostingowych nie instaluje nowych wydań PHP, tylko dokłada poprawkę do wersji, którą już ma. Numer wersji zostaje wtedy bez zmian, a luka jest załatana.

Jeśli numer wersji jest równy lub wyższy niż 8.2.35, 8.3.36, 8.4.27 lub 8.5.12

Wersja zawiera poprawkę. Numer można sprawdzić w panelu hostingu, w pliku z funkcją phpinfo() (usuń go po sprawdzeniu) albo w panelu WordPressa w sekcji Narzędzia, Kondycja witryny, Informacje.

Jeśli numer jest niższy, a strona stoi na hostingu z cPanel lub CloudLinux

CloudLinux wydał poprawione pakiety jako backport i zaznacza, że ich numery wersji pozostają niższe niż w oficjalnych wydaniach PHP. cPanel poprawił swoje pakiety PHP w wersjach od 7.4 do 8.5 w EasyApache 4 v25.91. Administrator serwera może sprawdzić poprawkę w historii zmian pakietu (CloudLinux podaje do tego polecenie rpm -q --changelog dla pakietów ea-php i alt-php z wyszukaniem numerów CVE) i musi pamiętać o restarcie Apache, PHP-FPM lub LiteSpeed po aktualizacji.

Jeśli serwer działa na Debianie, Ubuntu lub RHEL

Dystrybucje również łatają bez zmiany głównego numeru wersji. Liczy się pełny numer pakietu wskazany w komunikacie bezpieczeństwa dystrybucji. Debian wydał poprawki w komunikatach DSA-6574-1 i DLA-4848-1, Ubuntu w USN-8948-1 i USN-8948-2, a Red Hat publikuje poprawki dla RHEL 8, 9 i 10 w ramach biuletynu RHSB-2026-013.

Czy pomoże data kompilacji w phpinfo?

Hostinger jako wskazówkę dla swoich klientów podaje pole Build Date w phpinfo() z datą 21 października 2026 lub późniejszą. Na innych serwerach to tylko poszlaka, nie dowód: świeża data oznacza nowy build, ale nie mówi, co dokładnie zawiera.

Jak zapytać hosting?

Na hostingu współdzielonym najpewniejsza jest odpowiedź firmy hostingowej. Wystarczy krótkie pytanie: „Czy wersje PHP używane przez moje konto mają poprawki dla CVE-2026-109618 i CVE-2026-109619 i czy procesy PHP zostały po aktualizacji zrestartowane?”. Warto też zapytać, czy hosting obejmuje poprawkami starsze wersje PHP, jeśli strona z nich korzysta.

Uwaga dla administratorów: ustawienia PHP sprawdza się w żądaniu obsłużonym przez serwer WWW, nie z wiersza poleceń, bo CLI często korzysta z innego pliku php.ini.

Co zrobiły polskie hostingi?

Zestawienie opiera się wyłącznie na publicznych komunikatach z 21 i 22 października 2026:

Hosting	Co ogłosił
cyber_Folks i Zenbox	Poprawki dla obu luk wdrożone, także dla PHP 5.x i 7.x. Na serwerach zarządzanych klient nie musi nic instalować. Zalecenie przejścia na PHP 8.2 do 8.5.
dhosting	Przed wdrożeniem poprawek wyłączono `session.upload_progress.enabled`. Pierwsze serwery załatano 21 października po południu, komplet poprawek CloudLinux wdrożono w nocy z 21 na 22 października.
Smarthost	21 października serwery z Imunify360 objęto tymczasową blokadą, a przed północą poinformowano, że wszystkie wersje PHP mają łaty bezpieczeństwa.
MyDevil	Tymczasowo wyłączono część funkcji PHP, co wpływało m.in. na wysyłanie plików i edycję stron. Wdrożono poprawione wersje i łatki dla starszych PHP, a ograniczenia zdjęto.
home.pl	Komunikat o zakończeniu wdrażania poprawek PHP na wszystkich platformach. Klient nie musi nic robić.

Jeśli Twój hosting nie opublikował komunikatu, nie musi to oznaczać braku poprawek. Wtedy najlepiej zadać pytanie z poprzedniej sekcji. Na VPS i serwerach dedykowanych zarządzanych samodzielnie aktualizacja należy do administratora serwera.

Co właściciel strony powinien zrobić teraz?

Ustal, kto odpowiada za serwer. Hosting współdzielony: firma hostingowa. VPS lub serwer dedykowany: administrator, agencja albo Ty.
Sprawdź wersję PHP w panelu hostingu lub w kondycji witryny WordPressa i porównaj z wersjami 8.2.35, 8.3.36, 8.4.27 i 8.5.12.
Jeśli wersja jest niższa, potwierdź backport w komunikacie hostingu albo zapytaj obsługę o oba numery CVE.
Na własnym serwerze zaktualizuj PHP i zrestartuj wszystkie procesy (PHP-FPM, Apache, LiteSpeed). Stare procesy działają na starym kodzie do czasu restartu.
Jeśli aktualizacja nie jest możliwa od razu, zastosuj tymczasowe ustawienia z komunikatu PHP i CERT Polska: wyłączenie session.upload_progress.enabled w php.ini lub konfiguracji puli (nie przez ini_set() ani .user.ini), ograniczenie post_max_size oraz zmiany limitu pamięci. Te ustawienia obejmują znane ścieżki ataku, ale według PHP i CERT Polska nie dają pełnej ochrony, a wyłączenie upload progress dotyczy tylko jednej z dwóch luk.
Zaplanuj przejście na wspieraną gałąź PHP. PHP 8.1 i starsze nie są już wspierane, a PHP 8.2 traci wsparcie bezpieczeństwa 31 grudnia 2026.
Zrób kopię zapasową plików i bazy danych i sprawdź, czy da się ją odtworzyć. Więcej piszemy w artykule o dobrych praktykach tworzenia kopii zapasowych.
Przejrzyj stronę pod kątem śladów nieautoryzowanych zmian: nowe konta administratorów, nieznane pliki PHP w katalogach z obrazkami, zmiany w plikach z ostatnich dni. Jeśli coś budzi wątpliwości, zmień hasła do panelu, FTP i bazy danych.
Zaktualizuj aplikację: WordPressa, wtyczki i motywy. Luka w PHP nie zastępuje innych zagrożeń, tylko do nich dochodzi.
Incydent zgłoś do CERT Polska przez incydent.cert.pl, jeśli podejrzewasz, że strona została przejęta.

Dlaczego WordPress jest szczególnie narażony?

Luki PHP2Shell dotyczą każdej aplikacji w PHP, nie tylko WordPressa. Odkrywcy zademonstrowali atak w laboratorium m.in. na aktualnych obrazach WordPressa, Drupala i Joomli, a inna firma potwierdziła wykonanie kodu m.in. na Magento. WordPress nie jest więc „winny” tej luce. Jest jednak systemem, w którym kilka czynników ryzyka występuje jednocześnie i na dużą skalę. Warto je znać, bo to one decydują o tym, czy pojedyncza luka kończy się incydentem.

Czy popularność czyni WordPress celem?

Według W3Techs WordPress działa na 39,6% wszystkich stron internetowych i na 58,3% stron, których system CMS da się rozpoznać (stan na 22 października 2026). Dla atakującego to prosty rachunek: jedno narzędzie skanujące pod WordPressa trafia w ogromną liczbę stron. Wordfence w samym pierwszym kwartale 2026 roku zablokował 16 miliardów prób zgadywania haseł i 9,1 miliarda innych ataków na chronione strony, a malware wykrył na 474 tysiącach stron. To nie jest wada systemu, tylko konsekwencja jego zasięgu.

Ile podatności jest we wtyczkach, a ile w samym WordPressie?

Katalog WordPress.org liczy ponad 72 tysiące wtyczek, do tego dochodzą tysiące motywów i dodatków komercyjnych. Patchstack naliczył w 2025 roku 11 334 nowe podatności w ekosystemie WordPressa, około 42% więcej niż rok wcześniej. 91% z nich dotyczyło wtyczek, 9% motywów, a w samym rdzeniu WordPressa znaleziono tylko 6 podatności o niskim priorytecie. Rok wcześniej proporcje były podobne: 96% wtyczki, 4% motywy.

Wniosek jest istotny dla właściciela strony: bezpieczeństwo WordPressa zależy przede wszystkim od tego, ile i jakich dodatków zainstalowano. Każda wtyczka to kod innego autora, z innym tempem poprawek.

Jak szybko atakujący wykorzystują nowe luki?

Według Patchstacka 46% podatności zgłoszonych w 2025 roku nie miało poprawki od autora w chwili publicznego ujawnienia. Około połowa podatności o dużym wpływie była wykorzystywana w ciągu 24 godzin od ujawnienia, a ważona mediana czasu do pierwszego ataku dla najczęściej atakowanych luk wyniosła 5 godzin. Sekurak opisał w październiku 2026 próby wykorzystania luki w WordPressie zaobserwowane kilka godzin po wydaniu poprawki.

Z drugiej strony ataki często trafiają w strony, które poprawkę mogły mieć od dawna. Przykład z 2026 roku: luka w wtyczce Gravity SMTP została naprawiona w marcu, a szczyt ataków na nią Wordfence odnotował w czerwcu, ponad 17 milionów zablokowanych prób.

Co z porzuconymi wtyczkami?

Wtyczka, której autor przestał ją rozwijać, nie dostanie poprawki nawet po wykryciu luki. W 2024 roku z katalogu WordPress.org usunięto 1 614 wtyczek i motywów z powodu niezałatanych podatności. Usunięcie z katalogu nie odinstalowuje wtyczki ze stron, na których już działa. Właściciel strony często w ogóle o tym nie wie, bo panel nie pokazuje wtedy dostępnej aktualizacji.

Dlaczego brak aktualizacji jest tak częsty?

Aktualizacje na WordPressie bywają odkładane z obawy, że coś się zepsuje, zwłaszcza gdy strona ma kilkanaście wtyczek zależnych od siebie. Według oficjalnych statystyk WordPress.org około 29% instalacji działa na wersji WordPressa starszej niż 7.0. Raport Sucuri za 2023 rok wskazywał, że 39,1% zainfekowanych stron oczyszczanych przez tę firmę miało nieaktualny CMS w chwili infekcji.

Dobry przykład szybkiej reakcji to lipiec 2026: po wykryciu krytycznej luki w samym rdzeniu (nazwanej wp2shell) WordPress wydał poprawki 7.0.2, 6.9.5 i 6.8.6 i wymusił automatyczne aktualizacje. Mimo to w próbie ponad 124 tysięcy stron kilka dni później około 18% wciąż nie było załatanych, a atakujący instalowali na podatnych stronach webshelle.

Ile stron na WordPressie działa na starym PHP?

Według statystyk WordPress.org ok. 36% instalacji WordPressa działa na PHP 8.1 lub starszym, czyli na wersjach bez wsparcia bezpieczeństwa projektu PHP, a ok. 22% na PHP 7 lub starszym (wyliczenie na podstawie danych WordPress.org z 22 października 2026). Dla całego internetu W3Techs podaje, że wśród stron korzystających z PHP 26,9% działa na PHP 7, a 7,7% na PHP 5.

Stara wersja PHP oznacza, że poprawki dla luk takich jak PHP2Shell zależą wyłącznie od tego, czy hosting lub dystrybucja wykonają backport. Duże polskie hostingi tym razem to zrobiły, ale nie jest to obowiązek, który można zakładać zawsze i wszędzie.

Czym grożą pirackie (nulled) motywy i wtyczki?

Płatne motywy i wtyczki rozpowszechniane za darmo poza oficjalnymi kanałami to częste źródło złośliwego kodu. W raporcie za 2020 rok Wordfence wykrył malware z takich dodatków na ponad 206 tysiącach stron, czyli w ponad 17% wszystkich infekcji, które zidentyfikował. Nowszy przykład z września 2025: zmodyfikowane kopie dwóch dużych wtyczek premium wyłączały inne wtyczki, w tym zabezpieczające, i dawały atakującemu trwały dostęp do strony. Pirackie dodatki nie dostają też aktualizacji, więc każda późniejsza luka zostaje na stronie na stałe.

Dlaczego proste hasło do panelu to wciąż problem?

Adres panelu logowania WordPressa jest standardowy i znany każdemu automatowi. Próby zgadywania haseł liczone są w miliardach na kwartał. Słabe lub powtarzane hasło administratora, brak logowania dwuskładnikowego i wiele kont z pełnymi uprawnieniami to najprostsza droga do przejęcia strony, niezależna od jakichkolwiek luk w kodzie.

Czym jest xmlrpc.php i czy trzeba go wyłączać?

Plik xmlrpc.php to starszy interfejs WordPressa do zdalnej publikacji treści, z którego korzystały m.in. aplikacje mobilne i zewnętrzne edytory. Przed laty pozwalał na sprawdzenie setek haseł w jednym żądaniu. WordPress od wersji 4.4 ogranicza ten mechanizm, ale xmlrpc.php nadal jest celem ataków na hasła i omija zabezpieczenia ustawione tylko na formularzu logowania. Jeśli strona go nie używa, rozsądnie jest go zablokować. Część firm hostingowych robi to domyślnie.

Jak luka w PHP łączy się z bezpieczeństwem WordPressa?

Luka w PHP i luki we wtyczkach to dwa różne poziomy, ale skutki się sumują:

PHP2Shell nie wymaga żadnej wtyczki. Projekt PHP opisuje, że w konfiguracji z mod_php atak może zadziałać, zanim wykona się kod samej aplikacji. Dobrze utrzymany WordPress na niezałatanym PHP nadal jest więc zagrożony.
Stare PHP i stare wtyczki zwykle idą w parze. Strona, której nikt nie aktualizuje, ma zwykle zarówno nieaktualne dodatki, jak i starą wersję PHP, bo nowsze PHP wymagałoby zaktualizowania wtyczek.
Skutki są takie same. Niezależnie od tego, czy atakujący wejdzie przez PHP, czy przez wtyczkę, zwykle zostawia na serwerze plik dający stały dostęp, dodaje konto administratora albo wstrzykuje spam i przekierowania. Patchstack zwraca uwagę, że tradycyjne zabezpieczenia hostingowe w jego testach zatrzymywały tylko część ataków na luki specyficzne dla WordPressa.
Wyciek danych dostępowych. Jedna z luk PHP2Shell może prowadzić do ujawnienia zawartości pamięci procesu. Na WordPressie mogą się tam znaleźć m.in. dane sesji i klucze, dlatego po incydencie warto zmienić hasła i klucze w pliku wp-config.php.

WordPress nadal jest dobrym systemem, jeśli ktoś się nim regularnie opiekuje: aktualizuje rdzeń, wtyczki i PHP, ogranicza dodatki do niezbędnych, pilnuje haseł i kopii zapasowych. Problem zaczyna się, gdy strona jest „zrobiona i zostawiona”. Jeśli rozważają Państwo zmianę technologii, porównanie podejść opisaliśmy w artykułach Czysty HTML czy WordPress? i Jaka alternatywa dla WordPressa?.

Czy warto przenieść stronę z WordPressa?

Nie każdą. Rozbudowany sklep z wieloma integracjami często lepiej zostawić na obecnej platformie i zadbać o regularną opiekę techniczną. Jeśli jednak strona to kilka lub kilkadziesiąt podstron, blog, galeria i formularz, a działa na kilkunastu wtyczkach, prostsze rozwiązanie zwykle oznacza mniej miejsc, które trzeba stale łatać.

Jeśli chcą Państwo przenieść stronę z WordPressa na bezpieczniejsze rozwiązanie, przygotowujemy CMS dopasowany do potrzeb, bez zbędnych wtyczek i dodatków. Przenosimy treści i adresy URL z przekierowaniami 301, tak aby strona zachowała widoczność w Google, i przygotowujemy prosty panel do edycji tekstów i zdjęć. Szczegóły opisujemy na stronie migracja z WordPressa na dedykowany CMS. Jeśli wolą Państwo zostać przy obecnej technologii, możemy ją uporządkować w ramach modernizacji strony.

Zapraszamy do kontaktu: kontakt@wardriving.pl, tel. +48 601 999 178.

Źródła

Stan wiedzy na 22 października 2026 roku. Sytuacja się rozwija, a komunikaty producentów i hostingów mogą być aktualizowane.

PHP2Shell: krytyczne luki w PHP (CVE-2026-109618 i CVE-2026-109619). Co powinni zrobić właściciele stron?