Jak sprawdzić, czy luka w PHP z 21 października dotyczy Twojej strony

W skrócie

• 21 października 2026 wyszły poprawki dwóch krytycznych dziur. Pierwsza, PHP2Shell, siedzi w samym PHP i pozwala przejąć serwer bez logowania.
• Aktualizacja WordPressa, motywu i wtyczek tu nie pomoże. Trzeba zmienić wersję PHP na 8.2.35, 8.3.36, 8.4.27 albo 8.5.12.
• PHP 8.1 i starsze nie dostaną poprawki. Druga dziura jest w Node.js, a Node 20 też zostaje bez łaty.
• Dzień później przejrzeliśmy 118 stron klientów. 14 ma wersję PHP sprzed poprawki, 61 trzeba sprawdzić w panelu hostingu.

21 października 2026 zespół PHP i twórcy Node.js wydali poprawki dwóch krytycznych dziur. Przez pierwszą obca osoba może przejąć stronę na WordPressie, Drupalu albo Joomli bez żadnego hasła, a dobry motyw i wtyczka bezpieczeństwa jej nie zatrzymają. Sprawdzenie, czy dotyczy to Twojej strony, zajmuje kwadrans.

Dzień po wydaniu poprawek przejrzeliśmy nasze serwery i strony klientów z naszego panelu. Poniżej piszemy, co znaleźliśmy, które wersje są bezpieczne i jak w siedmiu krokach sprawdzić własną stronę. Wolisz obejrzeć? Ten sam materiał jest w trzyminutowym filmie.

Co to za luka w PHP i dlaczego aktualizacja wtyczek nie pomoże?

Luka nazywa się PHP2Shell i ma dwa numery: CVE-2026-109618 i CVE-2026-109619. Dostała ocenę 9,2 na 10. PHP to język, na którym działa większość stron firmowych, w tym każda strona na WordPressie.

Błąd siedzi w miejscu, które czyta zapytanie do serwera, zanim ruszy jakikolwiek kod strony. Atakujący wysyła odpowiednio przygotowane zapytanie i uruchamia na serwerze własne polecenia. Badacze pokazali to na WordPressie, Drupalu i Joomli.

Dlatego aktualizacja WordPressa, motywu i wtyczek tym razem nic nie da. Wtyczka bezpieczeństwa też działa dopiero wtedy, gdy uruchomi się kod strony, a dziura jest wcześniej. Jedyny ratunek to zmiana wersji PHP na taką, która ma poprawkę.

Które wersje PHP i Node.js mają poprawkę?

Tego samego dnia wyszła też poprawka do Node.js, na którym działa wiele aplikacji i paneli. Najgroźniejszy błąd siedzi tam w rozpakowywaniu danych skompresowanych formatem Brotli i również pozwala wykonać cudzy kod. Zagrożone są dane, które serwer dostaje, i te, które sam pobiera z innych stron.

Ważna jest pełna wersja, z ostatnią liczbą. PHP 8.3.35 wygląda prawie tak samo jak 8.3.36, ale to właśnie ta jedna wersja różnicy decyduje, czy dziura jest zamknięta.

Co pokazał przegląd 118 stron naszych klientów?

22 października przejrzeliśmy 118 stron klientów z naszego panelu. Wersję PHP odczytaliśmy z odpowiedzi serwera, a tam, gdzie się dało, z danych, które strona przekazuje do panelu. Wynik:

• 14 stron pokazuje wersję PHP sprzed poprawki. Dwie z nich stoją na PHP 5.6 i 7.4, dla których łaty nie będzie wcale.
• 61 stron działa na hostingach, które ukrywają wersję PHP. Tam trzeba zajrzeć do panelu hostingu.
• 36 stron to sklepy i platformy, które łata ich dostawca, bez naszego udziału.

U siebie znaleźliśmy usługi na Node 20 i przełączyliśmy je na wersję z poprawką. Na serwerze ze stronami statycznymi działało PHP, z którego żadna strona nie korzystała, więc je wyłączyliśmy. Dla każdej strony klienta mamy teraz wiersz z hostingiem, wersją PHP, wersją WordPressa i oceną ryzyka, a zespół przechodzi tę listę od stron, dla których nie ma żadnej poprawki.

Grzegorz Wysocki
CEO emedia

Komentarz autora: Na serwerze ze stronami statycznymi działało PHP, z którego nic nie korzystało. Wyłączyliśmy je tego samego dnia. Najbezpieczniejsza usługa to ta, której nie ma, więc przy takiej luce warto najpierw sprawdzić, co w ogóle musi działać, a dopiero potem łatać resztę.

Jak sprawdzić swoją stronę w 15 minut?

Siedem kroków, w kolejności od najważniejszego:

1. Sprawdź wersję PHP. W WordPressie wejdź w Narzędzia, Zdrowie witryny, Informacje i Serwer. Bez WordPressa wersję pokaże panel hostingu.
2. Porównaj ją z listą. Jeśli jest niższa niż 8.2.35, 8.3.36, 8.4.27 albo 8.5.12, zmień ją w panelu hostingu albo zapytaj hosting, kiedy wgra poprawkę.
3. PHP 8.1 albo starsze przenieś na 8.3 lub 8.4. Najpierw zrób kopię strony, a po zmianie przeklikaj formularze i koszyk.
4. Masz własny serwer? Zrestartuj PHP. Bez restartu PHP-FPM albo Apache dalej działa stara wersja.
5. Sprawdź Node.js na serwerze. Polecenie node -v uruchom tam, gdzie działa aplikacja, a nie na swoim laptopie. Node 20 przenieś na 22 albo 24.
6. Wyłącz to, czego nie używasz. PHP na serwerze ze stronami statycznymi to tylko dodatkowe drzwi.
7. Zmień hasła, jeśli strona była podatna. Poprawka zamyka dziurę, ale nie cofa tego, co mogło już wyciec: hasła do bazy, klucze API, dostępy.

Wersję PHP czasem widać też z zewnątrz, w nagłówku odpowiedzi serwera X-Powered-By. Wiele hostingów go ukrywa, więc brak tej informacji nie znaczy, że strona jest bezpieczna. Wtedy zostaje panel hostingu.

Co zrobić, jeśli strona stoi na PHP 8.1 albo starszym?

Dla PHP 8.1 i starszych poprawki nie będzie, więc jedyna droga to przejście na 8.3 albo 8.4. Stare strony często nie są na to gotowe: przestarzały motyw albo wtyczka potrafi po zmianie wersji wyłączyć formularz, koszyk albo całą stronę.

Dlatego zaczynamy od pełnej kopii strony i bazy, potem zmieniamy wersję i sprawdzamy najważniejsze miejsca: formularz kontaktowy, koszyk, płatności i panel administracyjny. Jeśli coś przestaje działać, wracamy na chwilę do kopii i aktualizujemy albo wymieniamy wtyczkę, która blokuje zmianę. Strona na PHP 5.6 albo 7.4 zwykle wymaga już szerszej naprawy niż sama zmiana wersji.

Jak emedia może w tym pomóc?

Możemy przejść tę listę za Ciebie:

• Bezpłatne sprawdzenie: wyślij adres strony przez formularz kontaktowy, a powiemy, na jakiej wersji PHP stoi i co trzeba zrobić.
• Zmiana wersji PHP z kopią i testami: w ramach opieki technicznej strony WordPress pilnujemy wersji, kopii i aktualizacji na bieżąco.
• Gdy coś już się stało: odwirusowanie strony WordPress i naprawa strony, która przestała działać po zmianie wersji.

Podsumowanie

Luka PHP2Shell omija wszystko, co zwykle chroni stronę na WordPressie, bo działa, zanim ruszy kod strony. Pomaga tylko wersja PHP z poprawką, a dla PHP 8.1 i starszych przejście na 8.3 lub 8.4. Sprawdź wersję w Zdrowiu witryny, porównaj z listą i, jeśli strona była podatna, zmień hasła i klucze API. Jeśli nie wiesz, od czego zacząć, wyślij nam adres strony.

Przeczytaj także

• Firmowa strona na WordPressie jest pod ciągłym atakiem. 4 fakty o jej bezpieczeństwie
• Fałszywe domeny sklepu: jak się bronić przed scamem
• Opieka techniczna strony WordPress: wersje, kopie i aktualizacje pod naszą opieką

Najczęstsze pytania

Jak to powstaje. Tematy, opinie i ostatnie słowo: Grzegorz Wysocki, właściciel emedia. Pierwsza wersja robocza i zebranie źródeł: model Claude Opus 5.5 w narzędziu Claude Code. Nic nie idzie na stronę bez przeczytania i poprawienia przez człowieka. Grafiki składamy sami, sceny powstają z pomocą AI na bazie zdjęcia autora.

Na czym to stoi. Node.js, wydania bezpieczeństwa z 21 października 2026. Sekurak, krytyczne podatności w PHP. CyberDefence24, krytyczna podatność w PHP. Przegląd stron klientów z panelu emedia, 22 października 2026. Czego nie wiemy, o tym piszemy wprost.

Realizacja: artykuł zrealizowany przez człowieka we współpracy z systemami AI. Redakcję i publikację firmuje autor. Wykorzystane systemy: Anthropic oraz OpenAI.

Opublikowano 23.10.2026, ostatnia aktualizacja treści 23.10.2026