21 października 2026 roku twórcy PHP wydali łatkę poza zwykłym harmonogramem. Powód: dwie krytyczne luki w samym rdzeniu języka — nie w WordPressie, nie w konkretnym sklepie, tylko w silniku, na którym działa prawie każda strona w internecie. Ocena zagrożenia sięga 9,2 na 10. Piszemy o tym, bo dotyczy to również naszych klientów, a „zaktualizuj PHP” czasem jest prostsze do powiedzenia niż do zrobienia.

Co się stało

Badacze z firmy Wiz znaleźli w PHP dwie luki, oznaczone jako CVE-2026-109618 i CVE-2026-109619. W uproszczeniu: przy pewnych warunkach PHP źle sprząta po sobie pamięć między kolejnymi żądaniami na tym samym serwerze. Skutkiem bywa wyciek fragmentów pamięci procesu — czasem cudzej sesji, hasła, klucza API — a w gorszym wariancie zdalne wykonanie kodu na serwerze, bez logowania się gdziekolwiek.

Najważniejsze zdanie z tego opisu: błąd nie wymaga żadnej luki w kodzie strony. Dotyczy samego PHP, więc działa nawet na najprostszej, pustej stronie, jeśli tylko w ogóle przyjmuje dane od użytkownika — formularz kontaktowy, wycenę, logowanie, upload pliku.

Kogo to dotyczy

Oficjalną łatkę dostały wersje PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12 — wszystkie wydane 21 października. Starsze gałęzie, 8.1 i niżej, w tym bardzo popularne jeszcze 7.4 i 7.3, oficjalnej poprawki od twórców PHP nie dostaną, bo producent zakończył już ich wsparcie. Jedyna szansa dla takich serwerów to własny backport od firmy hostingowej — część dużych dostawców to robi, ale trzeba to sprawdzić, nie założyć.

Samo spojrzenie na numer wersji PHP nie wystarczy. Backport bezpieczeństwa często nie zmienia numeru — serwer może pokazywać „starą” wersję, a mimo to być już załatany. Jedyny pewny sposób to zapytać dostawcę hostingu wprost albo sprawdzić to narzędziem, które wie, czego szukać.

Dlaczego „po prostu zaktualizuj” czasem nie wystarcza

Dla strony napisanej w nowoczesnym frameworku albo w czystym PHP aktualizacja bywa prosta: zmiana wersji w panelu hostingu i test. Problem zaczyna się tam, gdzie strona stoi na starszym silniku sklepu internetowego.

PrestaShop w starszych wydaniach gałęzi 1.7 oficjalnie wspiera PHP tylko do wersji 7.4. Żeby bezpiecznie przejść na załataną wersję PHP, trzeba najpierw zaktualizować sam PrestaShop — czasem o kilka wydań w górę — zanim nowsze PHP w ogóle zadziała bez błędów.

OpenCart w wydaniach z gałęzi 2.x ma podobne ograniczenie: starszy kod nie jest pisany pod PHP 8 i potrafi się na nim wywalić w nieoczywistych miejscach. Bezpieczne przejście zwykle wymaga wcześniejszej aktualizacji do serii 3.x, a dopiero potem zmiany wersji PHP.

To oznacza, że na części stron „zaktualizuj PHP” jest w rzeczywistości projektem: trzeba najpierw unowocześnić sam sklep, dopiero potem bezpiecznie podnieść PHP, i na końcu przetestować, że nic się nie wysypało.

Co możesz sprawdzić sam

  • Zapytaj dostawcę hostingu wprost, czy alt-php (albo odpowiednik Twojego hostingu) na Twoim koncie zawiera poprawki CVE-2026-109618 i CVE-2026-109619 — z datą wdrożenia, nie samym „tak, mamy najnowsze PHP”.
  • Nie poprzestawaj na numerze wersji z panelu — backport może go nie zmieniać.
  • Jeśli masz PrestaShop, OpenCart albo inny starszy silnik sklepu, zapytaj, na jakiej wersji PHP realnie działa i czy ta wersja jeszcze dostaje łatki bezpieczeństwa.
  • Do czasu potwierdzenia traktuj serwer jako możliwy do zdalnego przejęcia, nie jako bezpieczny z założenia.

Sprawdziliśmy to też w naszym skanerze

Dopisaliśmy tę konkretną lukę do EXIOSCAN AI, naszego darmowego skanera bezpieczeństwa. Skaner czyta wersję PHP widoczną z zewnątrz i sprawdza ją pod kątem dokładnie tych dwóch łatek z 21 października — nie tylko tego, czy wersja jest „stara" w ogólnym sensie. Jeśli brakuje łatki, dostajesz ostre, wyraźne ostrzeżenie, nie ogólnikowe „rozważ aktualizację".

Przeskanuj swoją stronę w EXIOSCAN AI — wpisujesz adres, wynik dostajesz w kilkanaście sekund, bez rejestracji. Jeżeli wynik Cię zaniepokoi albo masz starszy silnik sklepu, który wymaga planu migracji, robimy też pełny audyt bezpieczeństwa od środka z konkretną wyceną napraw.

Źródła

Szczegółowy opis techniczny luki opublikowali badacze, którzy ją znaleźli: Wiz Research — PHP2Shell. Oficjalne ogłoszenie łatki i listę poprawionych wersji podał producent: php.net — ogłoszenie z 21.10.2026. Komunikat w tej sprawie wydało też Ministerstwo Cyfryzacji: gov.pl — ważny komunikat o lukach w PHP.