Aktualizacje PHP są już dostępne

Zaktualizuj do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35.

PHP security advisory
PHP downloads
Advisories: CVE-2026-109618 i CVE-2026-109619

Dystrybucje Linuksa i dostawcy LTS otrzymali poprawki z wyprzedzeniem – sprawdź aktualizacje u swojego dostawcy. Jeśli korzystasz z wolontariackiego repozytorium rpms.remirepo.net, PHP informuje, że aktualizacje nie pojawią się dzisiaj i zaleca przejście na pakiety dystrybucyjne lub budowanie ze źródeł.

PHP 8.1 i starsze wersje nie otrzymują już aktualizacji od projektu PHP. Niektóre dystrybucje i dostawcy LTS oferują backported poprawki – skontaktuj się z dostawcą lub przejdź na wspieraną wersję. Dla osób budujących ze źródeł zespół bezpieczeństwa PHP przygotował minimalne backporty dla PHP 7.4, PHP 8.0 i PHP 8.1.

Live timeline

13:57 UTC – Krótko po wydaniu aktualizacji telemetria pokazuje wyłącznie ataki rozpoznawcze (probing), bez twardego dowodu na naruszenia. Sytuacja prawdopodobnie się zmieni, gdy szczegóły aktualizacji staną się publiczne. Aktualizacja jest absolutnie konieczna.
13:52 UTC – PHP wydaje wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, usuwające obie podatności.
Wcześniej 21 października – Na wszelki wypadek usługi, w tym holenderskie rządowe DigiD i MijnOverheid, The SEO Framework oraz duże japońskie platformy, zostały wyłączone do czasu wydania poprawki.
07:43 UTC – CTO Cloudflare informuje o wczesnych atakach i wdrożeniu wstępnych reguł WAF dla znanych wektorów exploita.
07:34 UTC – Wielokrotne przypadki aktywnej eksploatacji zgłoszone do Patchstack przez partnerów hostingowych.
20 października – Szczegóły wyciekły przed skoordynowanym ujawnieniem. Zespół bezpieczeństwa PHP ogłasza wydanie na 21 października.

Co wiemy

Dwie podatności są śledzone jako CVE-2026-109618 i CVE-2026-109619. Zespół bezpieczeństwa PHP ocenia obie jako Critical (CVSS v4.0 9.2).
CVE-2026-109618: Obsługa braku pamięci (out-of-memory) może przerwać PHP, gdy wewnętrzne dane żądania są tylko częściowo zainicjalizowane. Czyszczenie żądania może następnie potraktować nieprawidłowe dane jako poprawne.
CVE-2026-109619: Wewnętrzny stan należący do żądania może przetrwać po zwolnieniu jego pamięci. Późniejsze żądanie obsługiwane przez tego samego workera może wykorzystać ten nieaktualny stan, zanim normalna inicjalizacja go zresetuje.
Podatności znajdują się w interpreterze PHP, a nie w konkretnej aplikacji – każda strona działająca na podatnej wersji PHP jest narażona.
Wiz Research, które zgłosiło błędy do PHP, stwierdza, że każda wersja PHP wstecz do 5.4 jest dotknięta przynajmniej jedną z tych podatności. Zademonstrowano zdalne wykonanie kodu bez uwierzytelnienia na najnowszych obrazach kontenerów WordPress, Drupal i Joomla. Nawet prosta aplikacja „Hello World” na podatnej wersji PHP może zostać wykorzystana. Pokazano też możliwość odczytu pamięci workera PHP (hasła, tokeny, klucze API) bez osiągnięcia wykonania kodu. Wiz potwierdza, że poprawka PHP rozwiązuje problem u źródła, w tym inne warianty.
Szczegóły wyciekły 20 października, przed skoordynowanym ujawnieniem. Podatność nazwano „PHP2Shell”. Firma security watchTowr potwierdziła, że luki są rzeczywiste jeszcze przed wydaniem.
Kilka organizacji wyłączyło usługi prewencyjnie do czasu pojawienia się poprawki:
- Holenderski nadawca NOS podał, że offline poszły m.in. DigiD, MijnOverheid, strona holenderskiej Izby Reprezentantów, Tweakers oraz własna strona holenderskiego National Cyber Security Centre.
- Japoński portal ITmedia donosi o awaryjnym utrzymaniu na kilku dużych serwisach, w tym Kodmon, Shadowverse: Worlds Beyond i Sakura Rental Server – prawdopodobnie powiązanych z tą podatnością. Oczekiwano, że dołączą m.in. BASE i Xserver.
- Twórcy The SEO Framework poinformowali o wyłączeniu swoich serwerów.
Cloudflare informuje, że strony PHP stojące za Cloudflare mają wstępny zestaw reguł WAF dla znanych wektorów exploita (dostępny dla wszystkich klientów, w tym darmowych). To tylko rozwiązanie tymczasowe. Reguły działają wyłącznie, gdy serwer akceptuje ruch wyłącznie z Cloudflare.
CERT-EU wydał advisory, a brytyjskie National Cyber Security Centre opublikowało alert wzywający organizacje do natychmiastowej aktualizacji.

Jak zabezpieczyć swoje strony

Zaktualizuj do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do spatchowanego pakietu od dostawcy.
Znajdź wszystkie instalacje PHP, które uruchamiasz (serwery, kontenery, środowiska stagingowe, urządzenia i oprogramowanie firm trzecich bundlujące PHP), żeby wiedzieć, co wymaga aktualizacji.
Jeśli korzystasz z PHP 8.1 lub starszego – skontaktuj się z dostawcą w sprawie backported poprawki albo przejdź na wspieraną wersję.
Unikaj nieoficjalnych wtyczek „fix” i wklejanych fragmentów kodu. Nie są zweryfikowane i mogą zepsuć stronę.
Jeśli nie możesz zaktualizować od razu, a strona jest wysokiego ryzyka – rozważ wyłączenie jej lub przełączenie w tryb konserwacji. Podobną radę daje brytyjskie NCSC.

Jeśli nie możesz zaktualizować od razu

Tylko aktualizacja stanowi pełne rozwiązanie. PHP wymienia poniższe środki, które ograniczają ekspozycję na konkretne ścieżki ataku, ale nie czynią instalacji bezpieczną. Pełne szczegóły znajdują się w advisory.

Dla CVE-2026-109618 (korupcja przy out-of-memory):

Ustaw memory_limit=-1 w sposób, którego aplikacje nie mogą nadpisać (np. php_admin_value w puli FPM lub konfiguracji Apache). Sprawdź, czy żadne ustawienie puli, katalogu ani aplikacji nie przywraca skończonego limitu. Awaria alokacji może nadal dotrzeć do podatnej ścieżki.
Ustaw niski post_max_size: 8M jeśli nie potrzebujesz uploadów plików, 32M jeśli potrzebujesz. Trzymaj upload_max_filesize poniżej tej wartości. Rozważ też egzekwowanie limitów rozmiaru żądania, liczby pól i części multipart na poziomie serwera WWW lub proxy.
Użyj limitu kontenera lub cgroup jako granicy dostępności – najlepiej takiego, który zabija tylko dotkniętego workera. Nie używaj RLIMIT_AS ani RLIMIT_DATA, bo mogą one powodować podatną awarię alokacji.

Dla CVE-2026-109619 (nieaktualny globalny stan):

Ustaw session.upload_progress.enabled=0 i zrestartuj wszystkie workery. Użyj php.ini, puli FPM lub konfiguracji serwera – nie ini_set() ani .user.ini. Blokuje to potwierdzone ścieżki sesji, ale nie inne warianty.
Na PHP 8.5 ustaw fatal_error_backtraces=0 i zrestartuj wszystkie workery. Blokuje to tylko potwierdzoną ścieżkę fatal-backtrace.
Usuń nieprawidłowe lub przestarzałe ustawienia stosowane per-request, które generują diagnostykę przed inicjalizacją. Ukrywanie diagnostyki przez error_reporting, display_errors lub @ nie pomaga.
Napraw dostępne dla atakującego błędy fatalne i timeouty wykonania.

Oznaki, że serwer mógł zostać zaatakowany

Podatności działają poniżej warstwy aplikacji, więc logi aplikacji mogą pokazywać niewiele. Wiz Research zaleca obserwowanie:

Nietypowych żądań multipart, po których pojawiają się błędy limitu pamięci lub powtarzające się odpowiedzi HTTP 500.
Niespodziewanie dużych lub zniekształconych ciasteczek PHPSESSID w odpowiedziach.
Niewyjaśnionych restartów workerów PHP.

Te oznaki mogą ukierunkować dochodzenie, ale nie stanowią dowodu w żadną stronę. Jeśli je zauważysz – i tak musisz zaktualizować. Traktuj też serwer jako potencjalnie skompromitowany i rozważ rotację przechowywanych na nim poświadczeń, ponieważ podatności umożliwiają również ujawnienie zawartości pamięci.

Aktualizuj natychmiast. To jedna z tych podatności, przy których opóźnienie aktualizacji to gra z ogniem.

PHP wydał poprawkę. Zaktualizuj swój serwer ASAP