php2shell: dwie krytyczne luki w PHP są załatane. Zaktualizuj PHP na swojej stronie dzisiaj

21 października 2026 projekt PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają one dwie krytyczne luki, CVE-2026-109618 i CVE-2026-109619, które mogą pozwolić atakującemu uruchomić kod na serwerze bez logowania się. Zespół PHP zaleca wszystkim użytkownikom natychmiastową aktualizację (php.net).

Jeśli Twoja strona działa na WordPressie, WooCommerce, Joomli, Drupalu albo innym oprogramowaniu w PHP, to dotyczy Ciebie. Błąd jest w samym PHP, nie w WordPressie ani we wtyczce, więc aktualizacja WordPressa go nie usuwa. Trzeba zaktualizować PHP, a zwykle robi to firma hostingowa.

Co się stało

• 20 października 2026: zespół bezpieczeństwa PHP zapowiedział wydanie poprawek na 21 października 2026, godz. 14:00 UTC (16:00 czasu polskiego). Poprawki dotyczą dwóch krytycznych luk z oceną CVSS v4.0 9.2 (php.net).
• 21 października 2026, 03:02 UTC: Cloudflare włączył reguły zapory przeciw temu atakowi dla swoich klientów, także na darmowym planie. Według Cloudflare szczegóły wyciekły przed oficjalnym wydaniem i firma widziała ruch atakujący jej klientów (blog Cloudflare).
• 21 października 2026: PHP opublikował poprawione wersje i dwa komunikaty bezpieczeństwa, GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp, oba z oceną Critical, 9.2.

Obie luki nazwano „php2shell” (blog Cloudflare, BleepingComputer). Brytyjskie NCSC zaleca aktualizację, a jeśli systemu nie da się szybko zaktualizować ani zabezpieczyć, rozważenie jego wyłączenia (NCSC).

Kogo to dotyczy

Według PHP zagrożona jest każda instalacja PHP obsługująca żądania WWW, w tym PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko PHP przypisuje mod_php, gdzie pokazany exploit działa jednym żądaniem bez logowania, zanim uruchomi się jakikolwiek kod aplikacji (php.net).

Oba komunikaty uznają za podatne wszystkie wersje poniżej 8.2.35, 8.3.36, 8.4.27 i 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). Starsze gałęzie także: NCSC podaje PHP od wersji 5 (NCSC), Cloudflare PHP 5.4 i nowsze (blog Cloudflare).

Jeśli Twoja strona używa PHP i nikt nie aktualizował PHP od popołudnia 21 października, przyjmij, że jest podatna.

Jak sprawdzić wersję PHP na swojej stronie

W WordPressie: wejdź w Narzędzia > Kondycja witryny > Informacje i rozwiń sekcję Serwer. Znajdziesz tam wersję PHP, na której działa strona (dokumentacja WordPress.org). Jeśli Kondycja witryny pokazuje też komunikat o przestarzałej wersji PHP, potraktuj to jako pilne.

W panelu hostingu: większość paneli (cPanel, Plesk, DirectAdmin i panele poszczególnych firm) ma stronę do podglądu lub wyboru wersji PHP, często nazwaną „Wersja PHP”, „PHP selector” albo „Ustawienia PHP”. Jeśli jej nie znajdziesz, zapytaj hosting.

Porównaj to, co widzisz, z poprawionymi wersjami poniżej. Jedno zastrzeżenie: dystrybucje Linuksa i dostawcy wsparcia długoterminowego (LTS) dostali poprawki wcześniej i wydają własne pakiety (php.net). Ich numer wersji może nie odpowiadać numerom projektu PHP, nawet gdy poprawka jest w środku. Jeśli Twój hosting używa pakietów z dystrybucji, pewną odpowiedź da hosting, nie sam numer.

Co zrobić teraz

1. Przejdź na poprawioną wersję

Poprawione wersje: php.net. Daty wsparcia: PHP Supported Versions.

Jeśli masz PHP 8.2, zaktualizuj teraz do 8.2.35 i zaplanuj przejście na 8.3 lub nowsze. Po 31 grudnia 2026 PHP 8.2 nie dostanie już poprawek bezpieczeństwa (php.net).

2. Jeśli masz PHP 8.1, 8.0, 7.4 lub starsze

Projekt PHP nie wydaje już aktualizacji dla PHP 8.1 i starszych. Część dystrybucji i dostawców LTS udostępnia przeniesione poprawki. Ze względu na wagę luk zespół PHP opublikował też minimalne poprawki źródłowe dla PHP 7.4, 8.0 i 8.1, przeznaczone dla osób kompilujących PHP samodzielnie lub bez dostawcy LTS (php.net).

Dla typowej strony firmowej na hostingu współdzielonym lub zarządzanym odpowiedź jest prostsza: przełącz w panelu hostingu wersję PHP na wspieraną (8.3 lub nowszą) albo poproś o to hosting. Potem sprawdź stronę, bo stare wtyczki i motywy czasem nie działają na nowszym PHP.

3. Zapytaj hosting

Wyślij do hostingu krótką wiadomość:

Dzień dobry, czy PHP na moim koncie (domena: example.pl) ma już poprawki na CVE-2026-109618 i CVE-2026-109619? Jaka dokładnie wersja PHP lub pakiet jest u mnie używana i kiedy aktualizacja zostanie wykonana, jeśli jeszcze jej nie ma?

Jeśli masz własny serwer i korzystasz z prowadzonego przez wolontariusza repozytorium rpms.remirepo.net, PHP informuje, że 21 października nie będzie tam aktualizacji, i zaleca przejście na pakiety z dystrybucji albo kompilację ze źródeł (php.net).

4. Zapora daje kilka dni, ale nie zastępuje aktualizacji

Cloudflare wdrożył reguły przeciw znanym metodom ataku na wszystkich planach z WAF, także na darmowym (blog Cloudflare). CTO Cloudflare nazwał je rozwiązaniem tymczasowym i wezwał do aktualizacji (Tenable). Samo PHP pisze, że pełnych obejść nie ma, a aktualizacja to jedyny bezpieczny wybór (php.net).

Dwa ograniczenia. Reguły obejmują znane wzorce ataku, a atakujący już zmieniali swoje żądania, żeby je ominąć (blog Cloudflare). Reguły nic też nie dają, jeśli atakujący może połączyć się z serwerem bezpośrednio po adresie IP, więc serwer powinien przyjmować ruch WWW tylko z Cloudflare (Sansec).

5. Jeśli nie możesz zaktualizować dzisiaj

PHP podaje zmiany konfiguracji, które ograniczają znane ścieżki ataku, ale nie czynią serwera bezpiecznym (php.net). To ustawienia serwera, więc na hostingu współdzielonym musi je wprowadzić hosting. Przekaż tę listę swojemu developerowi lub hostingowi:

• Dla CVE-2026-109618: ustaw memory_limit=-1 tak, żeby aplikacje nie mogły tego nadpisać (np. php_admin_value w puli FPM lub konfiguracji Apache), ustaw niski post_max_size (8M bez przesyłania plików, 32M z przesyłaniem) i upload_max_filesize poniżej tej wartości, a na serwerze WWW lub proxy ogranicz rozmiar żądania, liczbę pól, części multipart i nagłówków. Nie używaj RLIMIT_AS ani RLIMIT_DATA.
• Dla CVE-2026-109619: ustaw session.upload_progress.enabled=0 w php.ini, puli FPM lub konfiguracji serwera i zrestartuj wszystkie procesy (ini_set() i .user.ini tu nie działają). Na PHP 8.5 ustaw też fatal_error_backtraces=0 i zrestartuj wszystkie procesy. Usuń błędne lub przestarzałe ustawienia stosowane dla pojedynczych żądań, które generują ostrzeżenia.

Szczegóły techniczne

Obie luki mają to samo źródło: gdy żądanie kończy się nieprawidłowo, PHP może zostawić pamięć w uszkodzonym stanie, któremu potem ufa (BleepingComputer, blog Cloudflare).

CVE-2026-109618, RCE przez uszkodzenie przy braku pamięci (GHSA-w8hw-w9fx-j79w). Gdy brakuje pamięci, PHP przerywa żądanie przez longjmp(). W niektórych miejscach pamięć żądania jest dostępna, zanim zostanie w pełni zainicjowana. Jeśli wtedy nie powiedzie się dowolna alokacja, procedura zamykania żądania może odczytać niedokończone dane. Atakujący może wymusić brak pamięci żądaniami multipart: treścią bez użytecznej długości, częścią z ogromną liczbą nagłówków albo wieloma pustymi polami plików z zagnieżdżonymi nazwami. W Apache z mod_php dzieje się to podczas automatycznego parsowania treści, zanim ruszy kod aplikacji. Zdalne wykonanie kodu z uprawnieniami procesu serwera WWW potwierdzono dla mod_php z domyślnymi limitami. FPM uznano za podatny na podstawie analizy kodu, choć pełnego exploita dla FPM nie pokazano. Poprawka zastępuje longjmp() opóźnionym, łagodnym zatrzymaniem w bezpiecznym punkcie i twardym _exit() po przekroczeniu wyższego progu.

CVE-2026-109619, RCE przez nieaktualny stan globalny (GHSA-6wmf-4rv5-p3rp). Proces PHP przechowuje stan globalny (błędy, sesje, obiekty, rozszerzenia), który wskazuje na pamięć należącą do jednego żądania. Błąd krytyczny, w tym brak pamięci albo Maximum execution time exceeded, może pominąć wyzerowanie tego stanu. Kolejne żądanie obsłużone przez ten sam proces może wtedy użyć zwolnionej pamięci przed normalną inicjalizacją (use after free). Potwierdzono dwie takie ścieżki: ostrzeżenia z ustawień INI stosowanych dla żądania przed inicjalizacją oraz postęp przesyłania sesji (session upload progress), włączony domyślnie i niewymagający wywołania session_start() przez aplikację. Podstawą potwierdzonego exploita dla mod_php jest ścieżka fatal_error_backtraces w PHP 8.5. Ścieżkę sesji sprawdzono na mod_php i FPM. Ukrywanie błędów przez error_reporting, display_errors czy @ nie chroni.

Oba komunikaty mają ocenę 9.2 i wektor CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: atak przez sieć, bez uprawnień, bez udziału użytkownika, wysoka złożoność ataku i pełny wpływ na poufność, integralność i dostępność serwera.

Co sprawdza ShieldWave

Z zewnątrz nikt nie stwierdzi, czy serwer ma poprawkę. Skan widzi natomiast wersję PHP, którą serwer sam o sobie podaje.

• Darmowy skan na shieldwave.io czyta nagłówek odpowiedzi X-Powered-By. Jeśli serwer zgłasza wersję PHP starszą niż poprawione wydanie swojej gałęzi albo gałąź, która poprawki w ogóle nie dostanie, raport pokazuje ustalenie php2shell z oboma numerami CVE i wersją, na którą trzeba przejść. Wiele hostingów ukrywa ten nagłówek, a dystrybucje łatają PHP bez zmiany numeru, więc takie ustalenie oznacza „zapytaj hosting”, a jego brak nie dowodzi, że serwer ma poprawkę.
• Wtyczka Ensomedia Security dla WordPressa pokazuje wersję PHP, na której działa strona, i to, czy ta gałąź jest jeszcze wspierana (strona wtyczki). To wyłapuje najgorszy przypadek w tej sytuacji: stronę na PHP 8.1, 8.0, 7.4 lub starszym, dla którego nie ma oficjalnej poprawki. Wtyczka jest darmowa, nie wymaga konta i jest w katalogu WordPress.org. W kokpicie wejdź w Wtyczki > Dodaj nową i wyszukaj „Ensomedia Security”.

Dokładny poziom poprawek sprawdź w Kondycji witryny i w tabeli powyżej, a potwierdź w hostingu.

Źródła

Oficjalne:

• Projekt PHP, ogłoszenia wydań i komunikat bezpieczeństwa, 20 i 21 października 2026: https://www.php.net/
• Komunikat bezpieczeństwa PHP GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• Komunikat bezpieczeństwa PHP GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Wspierane wersje PHP: https://www.php.net/supported-versions.php
• Rekord CVE-2026-109618 (CNA: PHP Group): https://www.cve.org/CVERecord?id=CVE-2026-109618
• UK NCSC, Critical security issue affecting PHP: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• Dokumentacja WordPress.org, Site Health screen: https://wordpress.org/documentation/article/site-health-screen/

Inne:

• Blog Cloudflare, Cloudflare deploys protections against php2shell vulnerability: https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws: https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/
• Tenable, php2shell FAQ: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
• Sansec, PHP2Shell: https://sansec.io/research/php2shell