Luki PHP CVE-2026-109618 i 109619: łatki dostępne

Krytyczne luki RCE w PHP core, CVE-2026-109618 i CVE-2026-109619

Poprawki na krytyczne luki CVE-2026-109618 i CVE-2026-109619 są już dostępne. W HitMe trwają prace nad wdrożeniem aktualizacji PHP. Wcześniej na hostingu wdrożyliśmy tymczasowe obejście; nie zastępuje ono instalacji poprawionej wersji. Poniżej zachowujemy historię komunikatów i bieżący status prac.

Ostatnia aktualizacja: 22.10.2026, 21:53 (czas polski).

Aktualizacje

22.10.2026, 21:53 - CloudLinux zakończył publikację poprawionych pakietów alt-php dla CloudLinux OS 7, 8 i 9 we wszystkich gałęziach PHP wymienionych w komunikacie dostawcy (5.2-5.6, 7.0-7.4 i 8.0-8.5). Wydanie stabilne zakończono o 00:07 UTC, czyli 02:07 czasu polskiego. Dostępność pakietów nie oznacza ich instalacji na każdym serwerze. Uzupełniliśmy też opis zakresu luk i ograniczeń obejść na podstawie oficjalnych ostrzeżeń PHP.
21.10.2026, 19:05 - Trwa wdrażanie poprawek PHP 8.2-8.5. Na serwerach z administracją wcześniej zastosowaliśmy ustawienia prewencyjne, a teraz instalujemy właściwe łatki. CloudLinux publikuje pakiety alt-PHP sukcesywnie; zapowiedziany termin to 19:00 UTC, czyli 21:00 czasu polskiego. Klientom korzystającym z PHP starszego niż 8.2 poza CloudLinux zalecamy migrację do poprawionych wydań. Same ustawienia prewencyjne nie gwarantują bezpieczeństwa.
21.10.2026, 16:56 - Trwa wdrażanie poprawek PHP 8.2-8.5. Przed ich instalacją wdrożyliśmy zalecane ustawienia prewencyjne. Na serwerach z administracją najpierw zastosowaliśmy ustawienia ograniczające ryzyko, a teraz wdrażamy właściwe łatki. Dostępność części pakietów zależy od harmonogramu dostawców, w tym CloudLinux alt-PHP.
21.10.2026, 16:19 - PHP.net udostępnił poprawki o 15:56 czasu polskiego. Poprawione wydania to PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. W HitMe trwa patchowanie; nie oznacza to zakończenia aktualizacji na wszystkich serwerach.
21.10.2026, przed południem - Na hostingu HitMe wdrożyliśmy tymczasowe obejście: wyłączyliśmy session.upload_progress. Klienci hostingu nie muszą nic robić. Aktualizacje PHP wdrożymy, gdy tylko pojawią się poprawione wersje.
21.10.2026, rano - Społeczność udostępniła reguły tymczasowej blokady na brzegu (Cloudflare, nginx, Caddy, Traefik) dla luki nazywanej nieoficjalnie PHP2Shell. Link do nich znajdziesz w sekcji „Co zrobić teraz”.
21.10.2026, rano - Cloudflare wdrożył początkowy zestaw reguł WAF dla znanych wektorów ataku na te luki. Reguły są dostępne dla wszystkich klientów Cloudflare, także na darmowym planie.
21.10.2026, rano - Pojawiły się pierwsze exploity, ale też obejście, które pozwala przetrwać do instalacji łatki (opis niżej).
20.10.2026 - Zespół PHP zapowiedział wydanie poprawek bezpieczeństwa na 21 października, godz. 14:00 UTC (16:00 w Polsce). Termin przyspieszono, bo informacje o lukach wyciekły przed końcem embarga.

Starsze komunikaty pokazują stan wiedzy i działań w podanym czasie. Aktualny stan opisujemy w najnowszym wpisie powyżej i w sekcji „Co robimy w HitMe”.

Co wiadomo o lukach w PHP

Dwie podatności w rdzeniu PHP: CVE-2026-109618 i CVE-2026-109619, ocenione na 9.2 w CVSS v4.0. Oficjalne szczegóły są już publiczne.
CVE-2026-109618: błąd obsługi wyczerpania pamięci może doprowadzić do zdalnego wykonania kodu. Opis zespołu PHP.
CVE-2026-109619: nieprawidłowo zachowany stan między żądaniami obsługiwanymi przez ten sam proces może prowadzić do użycia zwolnionej pamięci i RCE. Opis zespołu PHP.

Zagrożone są wszystkie instalacje PHP obsługujące żądania WWW, w tym PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed. Według zespołu PHP najwyższe ryzyko dotyczy mod_php, dla którego zademonstrowano atak jeszcze przed wykonaniem kodu aplikacji. Obie luki usuwają wydania PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12, a pełną ochronę daje wyłącznie aktualizacja. Wyjątkowe poprawki źródłowe dla PHP 7.4, 8.0 i 8.1 nie oznaczają wznowienia wsparcia tych gałęzi. Oficjalny komunikat PHP.

Oficjalne ustalenia zamiast wcześniejszych przypuszczeń

Wcześniej opisywaliśmy podejrzenia dotyczące mechanizmu session.upload_progress. Jest on jedną z potwierdzonych ścieżek dla CVE-2026-109619, ale nie wyjaśnia obu luk ani wszystkich wariantów ataku. Samo jego wyłączenie nie zapewnia pełnej ochrony.

Co zrobić teraz

1. Zainstaluj poprawioną wersję PHP

Wydano PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Zaktualizuj odpowiednią gałąź lub sprawdź poprawiony pakiet u dostawcy systemu. Jeśli administrujesz VPS-em lub serwerem dedykowanym, zweryfikuj instalację i zrestartuj procesy PHP obsługujące strony. Oficjalny komunikat PHP.

Jak zmienić wersję PHP oraz włączyć potrzebne moduły na hostingu, opisujemy w instrukcji Zmiana wersji oraz modułów PHP.

2. Do czasu instalacji poprawki: ogranicz ryzyko

Wyłączenie session.upload_progress blokuje potwierdzone ścieżki związane z sesją, lecz nie pozostałe warianty. W php.ini:

session.upload_progress.enabled = 0

Lub w konfiguracji puli PHP-FPM:

php_admin_value[session.upload_progress.enabled] = 0

Następnie zrestartuj wszystkie procesy PHP. Ustawienie musi obowiązywać przed przetwarzaniem żądania; nie polegaj na ini_set() ani pliku .user.ini w PHP-FPM. Pełne zalecenia i ograniczenia obejść opisuje oficjalne ostrzeżenie. Aktualizacja pozostaje konieczna.

Według oficjalnych ostrzeżeń żadna ogólna zmiana konfiguracji nie daje pełnej ochrony. Pozostałe obejścia mają wąski zakres:

PHP 8.5: ustawienie fatal_error_backtraces = 0 na poziomie administracyjnym i restart wszystkich procesów PHP blokuje tylko potwierdzoną ścieżkę związaną ze śladem stosu przy błędach krytycznych.
Ustawienia per żądanie: usuń nieprawidłowe lub przestarzałe dyrektywy konfiguracji, które generują komunikaty diagnostyczne przed inicjalizacją żądania. Samo ukrywanie błędów nie pomaga.
CVE-2026-109618: wymuszenie memory_limit = -1 na poziomie administracyjnym usuwa kontrolowany przez atakującego błąd przekroczenia limitu pamięci PHP, ale sam błąd alokacji nadal może zostać wykorzystany. Wyłączenie limitu ma też skutki dla stabilności, więc nie jest to uniwersalna recepta. Ogranicz na proxy lub serwerze rozmiar zdekodowanego żądania, liczbę części i nagłówków multipart oraz zagnieżdżenie danych, a post_max_size ustaw zachowawczo. Limity powinny obejmować także żądania bez poprawnego nagłówka Content-Length. Limity kontenera lub cgroup mogą ograniczyć wpływ na dostępność, ale nie usuwają ryzyka. Nie zastępuj tych kroków limitami RLIMIT_AS ani RLIMIT_DATA.

Szczegóły i ograniczenia: ostrzeżenie dla CVE-2026-109618 i ostrzeżenie dla CVE-2026-109619.

3. WAF jako dodatkowa warstwa ochrony

Jeśli używasz Cloudflare lub innego WAF, korzystaj z aktualnych reguł dostawcy. Nie traktuj ich jako zamiennika aktualizacji PHP.

4. Administrujesz serwerem? Możesz dodatkowo zablokować ruch na brzegu

Dla administratorów opublikowano reguły tymczasowej blokady PHP2Shell dla Cloudflare, nginx, Caddy i Traefik: wpis @heyandras na X.

Takie blokady mogą zakłócić wysyłanie plików i działanie aplikacji. Nie zastępują poprawionej wersji PHP ani nie chronią przed ruchem omijającym proxy.

5. Starsze PHP: sprawdź poprawki dostawcy i zaplanuj migrację

Wszystkim klientom korzystającym z PHP starszego niż 8.2 poza systemem CloudLinux zalecamy migrację do poprawionego wydania PHP 8.2 lub nowszej wspieranej gałęzi. Samo zastosowanie ustawień prewencyjnych nie daje gwarancji bezpieczeństwa: ogranicza wybrane ścieżki ataku, ale nie usuwa błędów w PHP i nie wyklucza innych sposobów ich wykorzystania. CloudLinux udostępnia własne poprawki także dla starszych gałęzi; sprawdź dostępność oraz instalację konkretnego poprawionego pakietu alt-PHP. Udostępnienie wyjątkowych poprawek źródłowych przez PHP dla starszych wersji również nie oznacza wznowienia ich regularnego wsparcia. Zobacz Kiedy warto wykonać aktualizację PHP.

Co robimy w HitMe

Trwa wdrażanie poprawek PHP. Przed instalacją łatek wykonaliśmy prace prewencyjne i zastosowaliśmy zalecane ustawienia ograniczające ryzyko. Aktualizacje wdrażamy sukcesywnie, w miarę dostępności poprawionych pakietów. Same ustawienia prewencyjne nie zapewniają pełnej ochrony i nie zastępują aktualizacji PHP.

Hosting (WWW, WordPress, PrestaShop, Elastyczny): ustawienia prewencyjne zostały wdrożone. Aktualizujemy PHP w miarę udostępniania odpowiednich pakietów przez dostawców. Klienci hostingu nie muszą wykonywać tych prac samodzielnie.
Serwery z administracją (Hosting Dedykowany VPS i serwery dedykowane): najpierw wdrożyliśmy ustawienia prewencyjne, a teraz instalujemy poprawki dla PHP 8.2-8.5. Prace trwają.
VPS i serwery bez administracji: aktualizację PHP wykonaj samodzielnie. Jeśli korzystasz z PHP starszego niż 8.2 poza systemem CloudLinux, zalecamy migrację do poprawionego wydania PHP 8.2 lub nowszej wspieranej gałęzi. Same zmiany konfiguracji nie gwarantują bezpieczeństwa i nie wykluczają innych ścieżek ataku.

CloudLinux: dostępność pakietów i weryfikacja poprawek

CloudLinux alt-PHP: według komunikatu dostawcy poprawione pakiety alt-php dla CloudLinux OS 7, 8 i 9 są dostępne w wydaniu stabilnym dla wszystkich wymienionych gałęzi: PHP 5.2-5.6, 7.0-7.4 i 8.0-8.5. Publikację zakończono 22 października o 00:07 UTC (02:07 czasu polskiego). Dotyczy to wyłącznie pakietów alt-php na tych systemach. Inne systemy i rodziny pakietów, w tym natywne pakiety php, mają własne harmonogramy. CloudLinux przenosi poprawki do starszych wersji, więc numer wersji może być niższy niż w wydaniu PHP.net; na przykład poprawiony pakiet alt-php85 ma wersję 8.5.11-5. Dlatego sprawdź pełną wersję pakietu i jego changelog pod kątem obu CVE:

rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'

Dostępność pakietów u dostawcy nie oznacza ich instalacji na konkretnym serwerze. Szczegóły: status CloudLinux.

Źródła

Podziel się

Komentarze wyświetlą się automatycznie po włączeniu „Komentarze (Disqus)” w ustawieniach cookies.

Krytyczne luki w PHP (CVE-2026-109618, CVE-2026-109619). Łatki już dostępne [aktualizowane]