21 października 2026 roku zespół PHP wydał poprawki dwóch krytycznych podatności, CVE-2026-109618 i CVE-2026-109619, nazywanych razem PHP2Shell. Atakujący nie potrzebuje loginu ani hasła. Wystarczy jedno spreparowane żądanie do strony, żeby uruchomić na serwerze własny kod i przejąć stronę. Kilka godzin po publikacji poprawek firma watchTowr zgłosiła próby wykorzystania obu luk, a Cloudflare poinformował, że widzi pierwsze ataki.
Jeśli strona, sklep internetowy albo panel administracyjny działają na PHP, serwer potrzebuje zaktualizowanej wersji PHP jeszcze dziś.
Co się stało
20 października zespół PHP zapowiedział krytyczne wydanie, a 21 października o 14:00 UTC opublikował poprawione wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Zespół PHP ocenia obie luki na 9,2 w skali 10 według CVSS v4.0, czyli na poziomie krytycznym. Pierwsza dotyczy tego, jak PHP zachowuje się przy braku pamięci. Druga pozwala, by dane z jednego żądania przedostały się do kolejnego żądania obsługiwanego przez ten sam proces na serwerze.
Problem obejmuje wszystkie sposoby uruchamiania PHP na serwerze WWW: PHP-FPM, Apache z mod_php, php-cgi, LiteSpeed i FrankenPHP. Za najbardziej narażony zespół PHP uznaje Apache z mod_php. W komunikacie opisano zademonstrowany exploit, w którym jedno żądanie bez logowania uruchamia atak, zanim wykona się jakikolwiek kod strony.
Do wieczora 21 października żadna firma zajmująca się bezpieczeństwem nie zgłosiła potwierdzonego włamania. Kod, który rzekomo wykorzystuje te luki, krąży już jednak w sieci, a masowe ataki mogą ruszyć w każdej chwili.
Kogo to dotyczy?
Wystarczy jedno „tak” w poniższych punktach.
- Strona działa na WordPressie, WooCommerce, Laravelu, OpenCart, Bitriksie, Drupalu, Magento lub innym systemie w PHP.
- Firma ma panel administracyjny, portal klienta albo API napisane w PHP. Backend aplikacji mobilnej też się liczy.
- Hosting ani programista nie potwierdzili, że PHP na serwerze jest już zaktualizowany.
- Na serwerze działa panel do zarządzania hostingiem, na przykład aaPanel. Niektóre panele nie udostępniły zaktualizowanego PHP w dniu wydania.
- Wersja PHP to 8.1 lub starsza.
Jeśli nie znacie odpowiedzi, to już wystarczający powód, żeby zapytać dziś.
Co atakujący może zrobić ze stroną
Wykonanie kodu na serwerze daje atakującemu taki sam dostęp, jaki ma sama strona. W praktyce oznacza to:
- pełną kontrolę nad stroną: zmiany treści, nowe konta administratorów, przekierowanie odwiedzających;
- dostęp do bazy danych: imiona i nazwiska klientów, adresy e-mail, adresy, zamówienia;
- złośliwe oprogramowanie lub strony ze spamem podrzucone na serwer;
- ostrzeżenie Google w wynikach wyszukiwania i w przeglądarce, które zatrzymuje ruch i sprzedaż do czasu wyczyszczenia strony.
Sprzątanie po włamaniu potrafi trwać kilka dni, a czasem kończy się przebudową strony od zera. Aktualizacja to kwestia godzin.
Co zrobić dziś
1. Sprawdźcie wersję PHP. Pokazuje ją panel hostingu, zwykle w sekcji „Wersja PHP” lub „Ustawienia PHP”. W WordPressie trzeba otworzyć „Narzędzia → Stan witryny → Informacje → Serwer”. W Ubuntu po aktualizacji bezpieczeństwa numer może nadal wyglądać na stary, na przykład 8.3.6, bo Ubuntu łata pakiet i zostawia numer wersji. Hosting albo programista musi sprawdzić wersję pakietu.
2. Poproście hosting lub programistę o aktualizację PHP. Tę wiadomość można wysłać bez zmian:
Dzień dobry. 21 października 2026 roku PHP wydał poprawki krytycznych podatności CVE-2026-109618 i CVE-2026-109619 (PHP2Shell). Proszę o potwierdzenie, że PHP na naszym serwerze jest zaktualizowany do poprawionej wersji (8.5.12, 8.4.27, 8.3.36, 8.2.35 lub załatany pakiet dystrybucji) i że PHP-FPM lub Apache został zrestartowany. Jeśli działamy na PHP 8.1 lub starszym, proszę o informację, jak planujecie wdrożyć poprawkę. Proszę też o sprawdzenie logów serwera pod kątem śladów wykorzystania luki od 21 października.
3. Przy PHP 8.1 lub starszym zaplanujcie przejście na wspieraną wersję. Dla 7.4, 8.0 i 8.1 zespół PHP opublikował poprawki wyłącznie w kodzie źródłowym. Ktoś musi więc skompilować PHP ze źródeł z tymi poprawkami albo przenieść stronę na nowszą wersję.
Wyłączenie session.upload_progress.enabled w ustawieniach PHP zamyka część ścieżki ataku. Zespół PHP zaznacza, że nie czyni to serwera bezpiecznym. To rozwiązanie tymczasowe, do czasu aktualizacji.
Wersja PHP i co zrobić
| Wersja PHP | Co zrobić |
|---|---|
| 8.5 | Zaktualizować do 8.5.12 |
| 8.4 | Zaktualizować do 8.4.27 |
| 8.3 | Zaktualizować do 8.3.36 |
| 8.2 | Zaktualizować do 8.2.35. Wsparcie dla 8.2 kończy się 31 grudnia 2026 roku, więc warto zaplanować kolejną aktualizację |
| 8.1, 8.0, 7.4 | Brak oficjalnej aktualizacji. Skompilować PHP z poprawkami ze źródeł albo przejść na wspieraną wersję |
| 7.3 i starsze | Brak poprawki od zespołu PHP. Przejść na wspieraną wersję |
Ubuntu wydało już poprawione pakiety. W przypadku innych dystrybucji Linuksa warto sprawdzić komunikat bezpieczeństwa dostawcy.
Jak poradziliśmy sobie z tym u naszych klientów
Zespół PHP opublikował poprawki o 14:00 UTC. Nasi inżynierowie zaczęli pracę mniej więcej godzinę później. Dwie godziny po tym, około 17:00 UTC, wszystkie utrzymywane przez nas serwery były zabezpieczone: 88 projektów objętych naszym wsparciem.
Na każdym serwerze najpierw wyłączaliśmy podatny mechanizm, a potem instalowaliśmy poprawiony PHP. Panele takie jak aaPanel nie miały zaktualizowanego PHP w dniu wydania, więc kompilowaliśmy PHP ze źródeł z poprawkami. Tak samo postąpiliśmy z projektami na PHP 7.4, 8.0 i 8.1, których zespół PHP już nie aktualizuje. Po aktualizacji przejrzeliśmy logi serwerów w poszukiwaniu śladów wykorzystania luki. Nie znaleźliśmy żadnych.
Nasz automatyczny monitoring działa całą dobę, a inżynierowie reagują, gdy zgłosi incydent.
Jak to zrobiliśmy, krok po kroku: jak załataliśmy 88 projektów PHP w trzy godziny.
Nie macie pewności, czy strona jest bezpieczna?
Sprawdzimy wersję PHP i zaktualizujemy ją w ciągu jednego dnia roboczego. Jeśli strona działa na PHP 8.1 lub starszym, powiemy, co w danym przypadku będzie szybsze i tańsze: własna kompilacja PHP z poprawkami czy przejście na nowszą wersję.
Poproście nas o sprawdzenie strony
Jeśli potem potrzebna jest stała opieka, zapraszamy na strony o wsparciu stron internetowych i wsparciu serwerów. Dla sklepów na WordPressie i WooCommerce mamy osobną stronę. Jeśli podejrzewacie, że ktoś dostał się do serwera przed aktualizacją, albo chcecie wiedzieć, co jeszcze jest otwarte, odpowie na to test penetracyjny.
FAQ
Czy trzeba aktualizować, jeśli strona działa na WordPressie?
Tak. WordPress działa na PHP, a luka tkwi w samym PHP. Aktualizacja WordPressa i wtyczek jej nie usuwa, serwer potrzebuje poprawionej wersji PHP.
Czy hosting zaktualizuje PHP automatycznie?
Niektórzy dostawcy tak robią, inni czekają, a na wielu serwerach VPS i dedykowanych nikt nie zaktualizuje PHP bez prośby. Warto poprosić dostawcę o pisemne potwierdzenie z dokładnym numerem wersji.
Czy strona przestanie działać po aktualizacji?
Aktualizacja w obrębie tej samej gałęzi, na przykład z 8.3.x do 8.3.36, zawiera tylko poprawki bezpieczeństwa i błędów i rzadko wpływa na stronę. Przejście z 7.4 lub 8.1 na nowszą gałąź może zepsuć stare wtyczki lub kod, więc taki krok trzeba najpierw przetestować.
Czy wystarczy wyłączyć session.upload_progress?
Nie. To zamyka część jednej ze ścieżek ataku. Zespół PHP podkreśla, że problem rozwiązuje wyłącznie aktualizacja.
Źródła
- Komunikat zespołu PHP: https://www.php.net/archive/2026.php
- Komunikaty bezpieczeństwa: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w i https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
- Próby ataków i doniesienia o kodzie exploitów: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote