21 października 2026 roku PHP, język, na którym działa większość stron firmowych, dostało pilne poprawki dwóch krytycznych luk. W całej Europie wyłączano strony, a nasze telefony dzwoniły bez przerwy. Wyjaśniamy, które wersje są bezpieczne i co zrobić, gdy stara strona na nowym PHP nie działa.
Opublikowano: 03.11.2026 · stan na listopad 2026 · Redakcja Tworzenie Stron Rzeszów
20 października szczegóły luk wyciekły do internetu, dzień przed planowanym ogłoszeniem. 21 października PHP opublikowało poprawki i tego samego dnia zaczęły się pierwsze próby ataków. Niemiecki urząd ds. bezpieczeństwa informacji (BSI) zalecał wyłączanie stron do czasu aktualizacji. Wiele organizacji tak zrobiło: w Niemczech m.in. urzędy, portale policji i duży szpital uniwersytecki, a także instytucje w innych krajach Europy. Media mówiły o tym przez kilka dni.
U nas telefony dzwoniły bez przerwy. Najczęstsze pytanie: „czy nasza strona jest bezpieczna?”.
Tak, jeśli działa na PHP. Luki są w samym PHP, a nie w WordPressie czy w konkretnej wtyczce, więc dotyczą prawie każdej strony firmowej i sklepu. Atak nie wymaga logowania i działa, zanim strona w ogóle się uruchomi. Dlatego wtyczka bezpieczeństwa w WordPressie tu nie pomoże.
Bezpieczne są tylko wersje PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 lub nowsze (stan na listopad 2026). Starsze wersje (7.4, 8.0, 8.1) nie dostały oficjalnej poprawki, bo twórcy PHP już ich nie wspierają.
Jak sprawdzić wersję: w panelu WordPressa: Narzędzia → Zdrowie witryny → Informacje → Serwer. Albo zapytaj firmę hostingową. Jeśli widzisz 7.x, 8.0 albo 8.1, strona wymaga aktualizacji.
To się zdarza. Starsze strony, zwłaszcza z motywami i dodatkami sprzed kilku lat, często nie działają na PHP 8. W naszym teście strony z 2018 roku przełączenie na PHP 8 zamieniło całą stronę, razem z logowaniem do panelu, w białą stronę z błędem.
Wtedy są dwie drogi: naprawić stary kod albo przepisać stronę od nowa w tym samym wyglądzie. W przypadku trzech takich stron przepisanie dało stronę kilka razy szybszą na telefonie, z jedną wtyczką zamiast kilkunastu: zobacz przebudowę strony WordPress 1:1 z pomiarem przed i po.
Więcej o objawach i pierwszych krokach: strona niezabezpieczona, strona nie działa albo pokazuje błąd i stara strona. Jak pilnujemy aktualnego PHP na stałe, opisujemy w opiece nad stroną.
Dla administratorów: fakty z komunikatów PHP, sprawdzenie obrazów Dockera i błędy starej strony na PHP 8. Nie opisujemy, jak wykorzystać luki. Wersje i daty: stan na listopad 2026.
| Element | Szczegóły |
|---|---|
| Luki | CVE-2026-109618: obsługa braku pamięci przerywa budowę danych żądania, a sprzątanie traktuje je jako poprawne. CVE-2026-109619: stan żądania przeżywa zwolnienie pamięci i używa go kolejne żądanie tego samego workera. |
| Ocena | „Critical”, zdalne wykonanie kodu bez uwierzytelnienia; CVSS 4.0: 9.2 (zapowiedź z 20.10.2026) |
| Zakres | każda instalacja obsługująca żądania WWW: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed; exploit pokazany dla mod_php przed kodem aplikacji |
| Poprawki | 21.10.2026: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 („update immediately”) |
| Bez wydań | „PHP 8.1 and older no longer receive updates from the PHP project”; dla 7.4, 8.0 i 8.1 tylko minimalne backporty w kodzie źródłowym (dla budujących ze źródeł) i pakiety dostawców LTS |
| Dystrybucje | „Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages” |
| Obejście | dla CVE-2026-109619: session.upload_progress.enabled=0 i restart każdego workera, w php.ini, puli FPM albo konfiguracji serwera; nie przez ini_set() ani .user.ini. Według PHP zmniejsza narażenie, ale nie zabezpiecza instalacji. |
| Dalszy ciąg | 23.10.2026: komunikat o CVE-2026-115560 (rzadki wariant przy zmianie session.serialize_handler w czasie działania); zalecane to samo session.upload_progress.enabled=0 do następnego wydania |
Przebieg: 20.10.2026 wyciek szczegółów i zapowiedź; 21.10.2026 ok. 14:00 UTC wydania poprawek, tego samego dnia pierwsze próby ataków; zalecenie BSI wyłączania stron do aktualizacji; masowe wyłączenia stron instytucji w Europie.
Oficjalne obrazy Dockera (docker run --rm php:<tag>-cli-alpine php -r 'echo PHP_VERSION;', 02.11.2026):
| tag | wersja | poprawka PHP2Shell |
|---|---|---|
php:7.4 | 7.4.33 | nie (ostatnie wydanie gałęzi) |
php:8.0 | 8.0.30 | nie |
php:8.1 | 8.1.34 | nie |
php:8.2 | 8.2.35 | tak |
php:8.3 | 8.3.36 | tak |
php:8.4 | 8.4.27 | tak |
php:8.5 | 8.5.12 | tak |
Stara strona na PHP 8 (nasze odtworzenie typowej strony z 2018 r.: WordPress 4.9, Elementor 2.x, motyw i wtyczki z tamtego czasu). PHP 7.4: działa, z ostrzeżeniami o przestarzałych funkcjach. PHP 8.0 i 8.1: wszystkie adresy HTTP 500, pusta strona, także logowanie:
PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in /var/www/html/wp-includes/load.php:651
Ten sam błąd daje WordPress 4.9.35, najnowsze wydanie tej gałęzi. Po aktualizacji samego Elementora strona pada z innego powodu, przez dodatek z 2018 r.:
PHP Fatal error: Uncaught Error: Class 'Elementor\Scheme_Typography' not found in /var/www/html/wp-content/plugins/essential-addons-for-elementor-lite/elements/fancy-text/fancy-text.php:287
php:7.4 zostaje na
7.4.33 i żadne przebudowanie obrazu tego nie zmieni. Przełączenie niekompatybilnej strony na starsze PHP, żeby
„działała”, oznacza dziś brak poprawki.session.upload_progress.enabled=0 ogranicza jedną ścieżkę ataku i działa tylko ustawione
przed analizą żądania (php.ini, pula FPM); ini_set() i .user.ini są za późno.| Etykieta | Wartość |
|---|---|
| Bezpieczne wydania PHP (stan na 2026-11) | 8.2.35, 8.3.36, 8.4.27, 8.5.12 lub nowsze |
| Gałęzie bez oficjalnej poprawki | 7.4 (ostatnie 7.4.33), 8.0 (8.0.30), 8.1 (8.1.34) |
| Strona z 2018 r. na PHP 8.0 | wszystkie adresy HTTP 500, także logowanie do panelu |
| Ocena luk | CVSS 4.0: 9.2, bez uwierzytelnienia |
Odczyt źródeł: 02.11.2026. Informacje o wyłączaniu stron w Europie i zaleceniu BSI pochodzą z doniesień medialnych z października 2026 r.
Dla firm, które chcą mieć stronę WordPress na hostingu z certyfikatem SSL, codziennymi kopiami i monitoringiem w jednej opłacie rocznej, bez pilnowania paneli i terminów.
500 zł netto / rok
Gdy strona pokazuje błąd, nie da się zalogować do panelu albo strona została zainfekowana i trzeba ją wyczyścić.
Wycena indywidualna
Co dostajesz
Przed naprawą: cenę do akceptacji. Po naprawie: krótki opis przyczyny i tego, co zrobić, żeby problem nie wrócił.
Rozmawiamy o nowej stronie, hostingu albo problemie z obecną stroną. Wycenę nowej strony dostajesz bezpłatnie w 24 h.
Dostępni: poniedziałek–piątek, 9:00–17:00