21 października 2026 roku zespół PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. To nie jest zwykła aktualizacja. Poprawki usuwają dwie krytyczne luki, które według oficjalnego komunikatu mogą pozwolić na zdalne wykonanie kodu bez logowania. Komunikat na php.net mówi wprost: nie ma pełnych obejść, jedynym bezpiecznym wyjściem jest aktualizacja.

Jeśli Twoja strona działa na WordPressie, WooCommerce, PrestaShopie, Laravelu albo dowolnym innym systemie w PHP, ta informacja dotyczy Ciebie. Poniżej tłumaczę, co się stało, dlaczego czas gra tu kluczową rolę i jak przeprowadzić aktualizację bez wyłączania sklepu na pół dnia.

Co dokładnie się stało

Chodzi o dwie podatności w samym silniku PHP, a nie w jednej wtyczce czy motywie:

  • CVE-2026-109618, „RCE via OOM corruption”. Gdy PHP-owi zabraknie pamięci w trakcie obsługi żądania, część wewnętrznych danych zostaje zainicjowana tylko w połowie. Sprzątanie po żądaniu traktuje je potem jak poprawne. Atakujący może do tego doprowadzić specjalnie spreparowanym żądaniem, np. wysyłką formularza.
  • CVE-2026-109619, „RCE via stale global state”. Stan należący do jednego żądania potrafi przetrwać po zwolnieniu pamięci. Kolejne żądanie obsługiwane przez ten sam proces może z niego skorzystać. Poza przejęciem serwera grozi to też wyciekiem danych z pamięci.

Obie luki mają ocenę CVSS 4.0 na poziomie 9.2 na 10, czyli kategorię „krytyczna”. W mediach pojawiła się nieoficjalna nazwa „PHP2Shell”.

Kogo to dotyczy

Według zespołu PHP: wszystkich instalacji PHP obsługujących żądania z sieci. To obejmuje PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Największe ryzyko dotyczy mod_php. Tam skuteczność ataku potwierdzono w praktyce: wystarcza jedno żądanie bez logowania i atak zaczyna się, zanim wykona się jakakolwiek linijka kodu Twojej strony.

To ważne, bo oznacza, że nie chronią Cię aktualne wtyczki, dobre hasła ani wtyczka bezpieczeństwa w WordPressie. Problem leży poziom niżej — w silniku, który uruchamia całą stronę.

Bezpieczne są wersje:

  • PHP 8.5.12 lub nowsze
  • PHP 8.4.27 lub nowsze
  • PHP 8.3.36 lub nowsze
  • PHP 8.2.35 lub nowsze

PHP 8.1 i starsze nie dostaną poprawki od twórców PHP. Te wersje mają status end-of-life. Część dystrybucji Linuksa i dostawców wsparcia LTS wydaje własne łatki, ale jeśli Twój hosting tego nie robi, jedyną drogą jest przejście na nowszą wersję.

Dlaczego nie warto czekać ani tygodnia

Wiem, jak to wygląda z perspektywy właściciela firmy: strona działa, klienci kupują, „jakoś to będzie”. Przy tej luce to podejście jest wyjątkowo ryzykowne. Z trzech powodów.

1. Poprawka to instrukcja dla atakujących. Od momentu publikacji łatki każdy może porównać stary i nowy kod źródłowy i zobaczyć, co naprawiono. Przy poważnych lukach automatyczne skanery zaczynają szukać podatnych serwerów zwykle w ciągu kilku dni, czasem godzin. Część firm zajmujących się bezpieczeństwem już informuje o kodzie exploita krążącym w sieci i pierwszych próbach ataków. Te doniesienia nie są jeszcze w pełni potwierdzone — ale nie warto czekać, aż będą.

2. Atak nie wymaga logowania. Nie trzeba znać hasła do panelu ani mieć konta w sklepie. Wystarczy, że serwer odpowiada na żądania z internetu — a każda strona to robi.

3. Skutki są poważne. Zdalne wykonanie kodu to najgorszy możliwy scenariusz. Atakujący może podmienić stronę, wstrzyknąć skrypt kradnący dane kart płatniczych, rozsyłać spam z Twojej domeny albo pobrać bazę klientów. Ten ostatni przypadek to już nie tylko problem techniczny, ale też obowiązek zgłoszenia naruszenia do UODO w ciągu 72 godzin zgodnie z RODO. O tym, jak wygląda sprzątanie po takim incydencie, pisałem w poradniku co zrobić, gdy strona została zhakowana.

Dla porównania: aktualizacja PHP na dobrze przygotowanym serwerze to zwykle kilkanaście minut pracy.

Skala problemu: wiele stron działa na przestarzałym PHP

Według W3Techs (stan na 21 października 2026) około 35% stron używających PHP działa na wersjach 7.x lub starszych, które od dawna nie dostają poprawek bezpieczeństwa. Do tego dochodzą strony na PHP 8.0 i 8.1, również bez wsparcia.

Jeśli Twoja strona jest w tej grupie, aktualizacja „o numerek” nie wystarczy. Trzeba przejść na wspieraną gałąź — i warto od razu wybrać taką, która posłuży dłużej. PHP 8.2 traci wsparcie bezpieczeństwa już 31 grudnia 2026, więc przy większej migracji lepiej celować w 8.3, 8.4 lub 8.5.

Krok 1: Sprawdź, jakiej wersji PHP używasz

Najprostsze sposoby:

  • Panel hostingu. W cPanelu, Plesku, DirectAdminie i panelach polskich hostingów wersja PHP jest zwykle widoczna w ustawieniach domeny.
  • WordPress. Kokpit → Narzędzia → Zdrowie witryny → Informacje → Serwer.
  • Serwer z dostępem SSH. Polecenie php -v pokazuje wersję wiersza poleceń. Strona może jednak korzystać z innej wersji przez PHP-FPM — sprawdź też systemctl status dla usługi php-fpm.

Uwaga na serwery z Debianem, Ubuntu lub RHEL. Dystrybucje często przenoszą poprawki do starszej wersji pakietu bez zmiany numeru. Serwer może pokazywać np. PHP 8.3.6 i mimo to być załatany. Wtedy sprawdź dziennik zmian pakietu i poszukaj numerów CVE-2026-109618 i CVE-2026-109619:

  • Debian/Ubuntu: apt changelog php8.3-fpm | head -50
  • RHEL/AlmaLinux/Rocky: rpm -q --changelog php | head -50

Krok 2: Przygotuj się, zanim cokolwiek zmienisz

Pilność nie zwalnia z ostrożności. Pięć minut przygotowań oszczędza godziny nerwów:

  1. Zrób pełną kopię zapasową — pliki strony i bazę danych osobno. Na VPS-ie najlepiej snapshot całej maszyny.
  2. Zapisz obecny stan — wersję PHP i listę modułów (php -m), żeby po aktualizacji porównać, czy niczego nie brakuje.
  3. Jeśli zmieniasz gałąź (np. z 7.4 lub 8.1 na 8.3+), testuj najpierw na kopii strony. Sprawdź, czy wtyczki, motyw i moduły obsługują nową wersję. Dla WooCommerce w najnowszych wydaniach minimum to PHP 8.3, dla Laravela 13 — PHP 8.3 do 8.5.
  4. Przy aktualizacji w obrębie tej samej gałęzi (np. 8.4.26 → 8.4.27) ryzyko niezgodności jest minimalne — to wydania wyłącznie z poprawkami.

Krok 3: Zaktualizuj PHP

Hosting współdzielony

Na hostingu współdzielonym zwykle nie aktualizujesz PHP samodzielnie — robi to firma hostingowa. Masz dwa zadania:

  • Zapytaj hosting, czy wdrożył już wersje 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 albo poprawki dla CVE-2026-109618 i CVE-2026-109619. Duzi dostawcy dostali łatki z wyprzedzeniem, ale nie każdy wdraża je od razu.
  • Jeśli używasz PHP 8.1 lub starszego, przełącz domenę na wspieraną wersję w panelu. W cPanelu robi się to w sekcji MultiPHP Manager, w Plesku w ustawieniach PHP domeny, w OVHcloud w zakładce hostingu („Wersja PHP”). Przy innych panelach poszukaj opcji „Wersja PHP” w ustawieniach domeny albo zapytaj support.

Serwer VPS lub dedykowany z Debianem / Ubuntu

  1. Odśwież listę pakietów: sudo apt update
  2. Sprawdź, co jest do aktualizacji: apt list --upgradable | grep php
  3. Zainstaluj aktualizacje: sudo apt full-upgrade albo tylko pakiety PHP, np. sudo apt install --only-upgrade php8.3-fpm php8.3-cli
  4. Uruchom ponownie PHP-FPM: sudo systemctl restart php8.3-fpm (zmień numer na swoją wersję)
  5. Przy Apache z mod_php: sudo apache2ctl -t, a potem sudo systemctl restart apache2

Jeśli korzystasz z repozytorium Ondřeja Surý (popularne źródło nowszych wersji PHP na Debianie i Ubuntu), aktualizacja przebiega tak samo — pakiety przychodzą z tego repozytorium.

Serwer z RHEL, AlmaLinux lub Rocky Linux

  1. Sprawdź dostępne poprawki bezpieczeństwa: sudo dnf updateinfo list --security
  2. Zaktualizuj PHP w obrębie włączonej gałęzi: sudo dnf update "php*"
  3. Uruchom ponownie usługę: sudo systemctl restart php-fpm lub sudo systemctl restart httpd

Jeśli używasz repozytorium Remi, aktualizacja również odbywa się przez dnf update.

Docker

Pobierz nowy obraz i przebuduj kontener: docker pull php:8.4-fpm, potem docker build --pull -t moja-aplikacja . i ponowne wdrożenie. Jeśli w Dockerfile masz przypiętą konkretną wersję (np. php:8.4.26-fpm), podnieś ją do wersji z poprawką.

Krok 4: Sprawdź, czy wszystko działa

  • php -v oraz wersja widoczna dla strony (np. w Zdrowiu witryny WordPressa) pokazują poprawioną wersję albo pakiet z poprawką CVE w dzienniku zmian.
  • Lista modułów zgadza się z zapisaną przed aktualizacją.
  • Strona, logowanie, koszyk, płatności i formularze kontaktowe działają.
  • W logach PHP-FPM i serwera WWW nie ma nowych błędów: journalctl -u php8.3-fpm -n 50

Nie możesz zaktualizować dziś? Ogranicz ryzyko

Zespół PHP podaje kilka ustawień, które zmniejszają ryzyko, ale go nie usuwają. Traktuj je jako rozwiązanie na kilka godzin, nie zamiast aktualizacji. Większość z nich wymaga dostępu do konfiguracji serwera, więc na hostingu współdzielonym zwykle nie da się ich zastosować.

  • Ustaw session.upload_progress.enabled=0 w php.ini lub konfiguracji puli FPM i uruchom ponownie wszystkie procesy. Ustawienie przez ini_set() albo .user.ini nie wystarczy.
  • Ustaw niski post_max_size: 8M dla stron bez wysyłania plików, 32M, jeśli upload jest potrzebny.
  • Ustaw memory_limit=-1 tak, by aplikacja nie mogła go nadpisać (np. przez php_admin_value) — ale tylko razem z limitem pamięci na poziomie kontenera lub cgroup, inaczej ryzykujesz zawieszenie serwera.
  • Na PHP 8.5 ustaw fatal_error_backtraces=0.

Źródła

Informacje o lukach pochodzą z oficjalnego komunikatu zespołu PHP oraz zgłoszeń GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp. Daty wsparcia wersji: php.net/supported-versions. Statystyki: W3Techs. Stan na 21 października 2026 r. Doniesienia o atakach w sieci pochodzą od firm trzecich i nie zostały potwierdzone w oficjalnym komunikacie.

Potrzebujesz pomocy z aktualizacją serwera?

Jeśli nie wiesz, jakiej wersji PHP używa Twoja strona, nie masz pewności, czy hosting wdrożył poprawkę, albo po prostu nie chcesz ryzykować samodzielnej aktualizacji — pomogę Ci zaktualizować serwer. Sprawdzę wersję PHP, zrobię kopię zapasową, przeprowadzę aktualizację i upewnię się, że strona, sklep i formularze działają tak jak wcześniej. Jeśli strona działa na wersji bez wsparcia, przygotuję bezpieczne przejście na nowszą.

Napisz do mnie albo zadzwoń: +48 791 509 560.