Dwie krytyczne podatności PHP usunięte: sprawdź aktualizacje

21 października 2026 r. twórcy PHP wydali poprawki dwóch krytycznych podatności: CVE-2026-109618 i CVE-2026-109619. Obie mogą umożliwić napastnikowi wykonanie kodu na serwerze bez uwierzytelnienia. Te podatności są znane pod wspólną nazwą PHP2Shell.

Poprawki są dostępne w PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Zespół PHP zaleca natychmiastową aktualizację. Sprawdzenia wymagają również starsze gałęzie, w tym PHP 5.6: także są podatne.

Dlaczego te podatności są groźne

Błędy znajdują się w samym PHP, które wykonuje kod strony. Aktualizacja WordPressa, innego systemu CMS lub wtyczek nie wystarczy. Obie podatności otrzymały ocenę 9,2 w skali CVSS v4.0 i dotyczą zarządzania pamięcią.

• CVE-2026-109618: obsługa braku pamięci może przerwać żądanie, zanim PHP zakończy inicjalizację danych wewnętrznych. Późniejsze porządkowanie może spowodować nieprawidłowy dostęp do pamięci.
• CVE-2026-109619: stan wewnętrzny może przetrwać zwolnienie pamięci, z której korzystał. Kolejne żądanie obsługiwane przez ten sam proces roboczy może użyć nieaktualnych danych.

Aktualizacje trzeba sprawdzić dla PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Według twórców największe ryzyko dotyczy konfiguracji z mod_php: zademonstrowano atak pojedynczym żądaniem bez uwierzytelnienia, jeszcze przed wykonaniem kodu aplikacji.

Badacze Wiz zademonstrowali również odczyt pamięci procesu PHP bez uzyskania zdalnego wykonania kodu. W pamięci mogą znajdować się hasła, tokeny i klucze API. Ryzyko wykracza więc poza modyfikację plików strony.

Nginx z PHP-FPM również wymaga aktualizacji. Badacze Calif opublikowali demonstrację ataku na taką konfigurację. Wśród przetestowanych aplikacji wymieniają WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony i WHMCS. To wyniki demonstracji badawczych, a nie lista serwisów, na które się włamano.

Do której wersji zaktualizować PHP?

Jeśli PHP pochodzi z pakietów Linuksa, dostawca może przenieść poprawkę do starszej wersji bez zmiany jej głównego numeru. Sprawdź pełną wersję pakietu i komunikat bezpieczeństwa dostawcy: samo oznaczenie „PHP 8.3” nie wystarczy. Zalecenia CERT-EU.

Co zrobić, jeśli strona działa na PHP 5.6, 7.x, 8.0 lub 8.1?

Starsze gałęzie również są podatne. Projekt PHP zakończył ich oficjalne wsparcie, ale poprawki mogą dostarczać dystrybucje, zewnętrzne repozytoria i dostawcy rozszerzonego wsparcia.

• PHP z repozytorium Sury, w tym PHP 5.6. Ondřej Surý poinformował, że poprawki obu podatności CVE powinny objąć wszystkie wersje PHP w jego repozytorium dla wszystkich obsługiwanych przez nie wydań Debiana i Ubuntu. Najpierw będą dostępne pakiety amd64, następnie ARM w miarę ukończenia kompilacji; terminów nie podano. Sprawdź poprawiony pakiet dla swojej gałęzi PHP, systemu i architektury. Ta zapowiedź dotyczy pakietów Sury, a nie wszystkich instalacji PHP 5.6. Komentarz opiekuna Sury PHP.
• Pakiety dystrybucji lub dostawcy rozszerzonego wsparcia. Znajdź jego komunikat bezpieczeństwa i zainstaluj zalecany pakiet.
• PHP kompilowane ze źródeł. Zespół PHP opublikował minimalne poprawki dla PHP 7.4, 8.0 i 8.1. Dostępność odpowiedniej poprawki dla pozostałych starszych gałęzi trzeba sprawdzić osobno.
• PHP zarządzane przez panel hostingu. Zapytaj dostawcę, czy wersja używana przez stronę otrzymała poprawki i czy musisz coś zrobić.

Poprawka usuwa te dwie podatności, ale nie przywraca pełnego wsparcia starej gałęzi. Zainstaluj dostępny pakiet, a przejście na wspieraną wersję PHP zaplanuj osobno.

Aktualizacje PHP w Ubuntu, Debianie i AlmaLinux

Stan sprawdzony 21 października 2026 r. Dla oficjalnych repozytoriów Ubuntu i Debiana potwierdzono następujące wersje pakietów z poprawkami:

Numery w tabeli dotyczą oficjalnych pakietów danej dystrybucji. Dla Sury i innych zewnętrznych repozytoriów sprawdź ich własne wersje pakietów. Poprawka może zostać przeniesiona do starszego PHP bez zmiany głównego numeru wersji. Ubuntu USN-8948-1.

Canonical wydało poprawki obu podatności CVE dla wymienionych wersji Ubuntu. Debian opublikował komunikat DSA-6574-1 dla Trixie, a w security trackerze wersja dla Bookworm jest już oznaczona jako poprawiona. Sprawdź dostępność pakietu na swoim serwerze lustrzanym i dla swojej architektury. Debian Security Tracker.

AlmaLinux: według oficjalnego komunikatu pakiety są przygotowywane dla wspieranych strumieni AlmaLinux 8, 9 i 10: najpierw testing, następnie production po weryfikacji. Wydanie w stabilnych repozytoriach nie jest jeszcze potwierdzone. Dotyczy to własnych pakietów AlmaLinux, a nie zewnętrznych repozytoriów PHP. Komunikat AlmaLinux.

Pierwsza tura obejmuje PHP 7.4 i 8.2 w AlmaLinux 8; PHP 8.0, 8.2 i 8.3 w AlmaLinux 9; PHP 8.3 i 8.4 w AlmaLinux 10. Wycofane strumienie PHP 7.2, 7.3 i 8.0 w AlmaLinux 8 oraz PHP 8.1 w AlmaLinux 9 nie należą do tej tury.

Aktualizacje PHP w panelach hostingowych i CloudLinux

Stan sprawdzony 21 października 2026 r. Wydawanie poprawek trwa: dostępność pakietu zależy od gałęzi PHP, systemu operacyjnego i repozytorium.

cPanel. Przedstawiciel cPanel poinformował o wydaniu poprawek dla ea-php74, ea-php80, ea-php81, ea-php82, ea-php83, ea-php84 i ea-php85. Obejmują one także przestarzałe gałęzie 7.4, 8.0 i 8.1. Sprawdź aktualizacje wszystkich używanych wersji ea-php, a nie tylko wersję panelu. Komunikat cPanel.

Plesk. Pracownik na oficjalnym forum poinformował, że kompilacje z poprawkami dla PHP 7.4, 8.0 i 8.1 są gotowe i przechodzą testy. Nie potwierdza to jeszcze dostępności każdego pakietu. Sprawdź osobno swoją gałąź i platformę; dostępność kompilacji dla Linuksa nie potwierdza dostępności wersji dla Windows. Odpowiedź pracownika Plesk.

FASTPANEL. W chwili sprawdzania nie znaleźliśmy osobnego oficjalnego komunikatu o PHP2Shell ani listy poprawionych pakietów. Obecność wersji PHP w panelu nie potwierdza instalacji poprawki: sprawdź zainstalowany pakiet i repozytorium lub poproś pomoc techniczną o potwierdzenie.

DirectAdmin. PHP stron jest zwykle kompilowane przez CustomBuild, więc aktualizacja pakietów systemowych może nie wystarczyć. Sprawdź dostępne wersje w CustomBuild → Updates lub poleceniem da build versions; plik custom_versions.txt może wymuszać starszą wersję. W chwili sprawdzania nie znaleźliśmy pełnej, potwierdzonej przez producenta listy poprawek, zwłaszcza dla starszych gałęzi. Instrukcje użytkowników forum polegające na ręcznej zmianie numerów wersji nie są równoznaczne z oficjalnym wydaniem.

ispmanager. Systemowe PHP pochodzi z repozytorium systemu operacyjnego, a alternatywne wersje są instalowane z repozytorium ispmanager w /opt/. Sprawdź oba źródła: aktualizacja systemowego PHP nie potwierdza usunięcia błędów w alternatywnych interpreterach stron. W chwili sprawdzania nie znaleźliśmy osobnego oficjalnego komunikatu o tych CVE ani listy poprawionych pakietów. To brak potwierdzenia, a nie dowód braku poprawek.

CloudLinux. Zapowiedziano poprawki dla alt-php 5.2–8.5; część pakietów, w tym alt-php74, już wydano. Sprawdź swój system i gałąź. Imunify360 ruleset 8.83 jest w Stable dla włączonego WAF, lecz nie zastępuje aktualizacji PHP. Status wydań CloudLinux.

Na jednym serwerze mogą działać jednocześnie PHP samego panelu, systemowe PHP, ea-php i alt-php. Aktualizacja jednej rodziny pakietów nie potwierdza usunięcia błędów w pozostałych. Po instalacji aktualizacji uruchom ponownie odpowiednie procesy i sprawdź, z którego interpretera korzysta każda strona.

Dlaczego problem dotyczy tak wielu stron?

PHP działa na serwerze: obsługuje formularze, sprawdza uwierzytelnienie, pobiera dane z bazy i generuje strony. Właściciel strony może korzystać wyłącznie z panelu zarządzania i nie wiedzieć, którą wersję PHP ma na hostingu.

Na PHP działają WordPress, Drupal, Joomla i MediaWiki. Język służy też do tworzenia własnych aplikacji, między innymi z użyciem Laravel. Sprawdzić trzeba więc także strony bez gotowego CMS. Różnice między systemami zarządzania treścią opisujemy w poradniku wyboru CMS.

Wikipedia korzysta z MediaWiki, a NASA, NASA Science i WhiteHouse.gov z WordPressa. 21 października Wikimedia Foundation poinformowała o czasowym wyłączeniu części usług pomocniczych, w tym Toolforge i Cloud VPS, do czasu bezpiecznego wdrożenia poprawek. Zespół starał się przy tym uniknąć przerw w działaniu samych wiki. Był to środek zapobiegawczy, a nie komunikat o włamaniu.

CMS i PHP aktualizuje się osobno. Aktualny WordPress z najnowszymi wtyczkami może nadal działać na PHP bez wymaganej poprawki. Jeśli atak następuje przed uruchomieniem aplikacji, mechanizmy kontrolne CMS nie zdążą jeszcze zadziałać.

Jak sprawdzić, czy strona otrzymała poprawkę?

Na hostingu zacznij od pytania do pomocy technicznej: „Czy PHP używane przez moją stronę ma poprawki CVE-2026-109618 i CVE-2026-109619?” Jeśli serwerem zarządzasz samodzielnie lub robi to Twój administrator:

1. Sprawdź wszystkie wersje PHP obsługujące żądania WWW. Różne strony na jednym serwerze mogą korzystać z różnych gałęzi.
2. Zainstaluj poprawione pakiety i uruchom ponownie odpowiednie procesy PHP.
3. Upewnij się, że strona używa zaktualizowanej wersji. PHP w wierszu poleceń może różnić się od wersji obsługującej stronę.
4. Sprawdź strony, logowanie, formularze i przesyłanie plików.

Czy ustawienia mogą zapewnić tymczasową ochronę?

Tylko aktualizacja w pełni usuwa problem. Tymczasowe ustawienia opisane przez twórców ograniczają konkretne ścieżki ataku, ale nie eliminują obu podatności. Jeśli szybkie zainstalowanie poprawek jest niemożliwe, CERT-EU zaleca rozważenie czasowego ograniczenia publicznego dostępu do podatnych aplikacji. Administratorzy znajdą środki techniczne w komunikacie CERT-EU podlinkowanym wyżej.