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.

Co właściciel strony powinien zrobić teraz

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 ograniczają konkretne ścieżki ataku, ale nie eliminują obu podatności. Jeśli szybka instalacja poprawek jest niemożliwa, CERT-EU zaleca rozważenie czasowego ograniczenia publicznego dostępu do podatnych aplikacji. Środki techniczne opisano w komunikacie CERT-EU 2026-018.

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.

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.

Czy zgłoszono próby wykorzystania podatności?

AWS poinformowało o próbie wykorzystania PHP2Shell w swoim systemie pułapek MadPot już 17 października, przed publicznym ujawnieniem podatności. To obserwacja próby ataku na pułapkę, a nie potwierdzenie udanego włamania do wszystkich podatnych systemów. Po instalacji poprawki warto sprawdzić logi, nieoczekiwane zmiany plików i uruchomienia procesów; AWS zaleca analizę zdarzeń co najmniej od 17 października. Badanie AWS.

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.

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 Linuksie, FreeBSD i Windows

Dane zaktualizowano 22 października 2026 r. Dostępność poprawki zależy od repozytorium, strumienia PHP i architektury. Dla oficjalnych pakietów Ubuntu i Debiana potwierdzono następujące wersje:

Ubuntu i Debian: pakiety z poprawkami

Numery w tabeli dotyczą oficjalnych pakietów wymienionych dystrybucji. Dla Sury i innych zewnętrznych repozytoriów sprawdź ich własne wersje pakietów. 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: poprawki w production

AlmaLinux 8, 9 i 10: poprawki wszystkich dostarczanych strumieni PHP trafiły do production. Obejmują też wcześniej pominięte PHP 7.2, 7.3 i 8.0 w AlmaLinux 8 oraz PHP 8.1 w AlmaLinux 9. Ta wyjątkowa poprawka nie oznacza dalszego wsparcia wycofanych strumieni. Wersje poprawionych pakietów AlmaLinux.

Porównaj pełny numer pakietu z tabelą AlmaLinux, na przykład poleceniem rpm -q php-common. Poprawki przeniesiono do starszych wersji PHP, więc samo php -v nie wystarczy. Jeśli wcześniej włączono almalinux-testing, nie jest już potrzebne do tych poprawek.

Arch, RHEL, SUSE, FreeBSD i Windows

Sprawdzono w oficjalnym komunikacie Arch Linux z 21 października, drzewie FreeBSD Ports i VuXML, komunikacie Red Hat, bazie SUSE oraz katalogu downloads.php.net/~windows/releases. Szczegóły: FreeBSD Ports, RHSA-2026:87080, statusy SUSE.

Aktualizacje PHP w panelach hostingowych i CloudLinux

Stan sprawdzony 22 października 2026 r. Rozróżniaj PHP stron, PHP samego panelu i pakiety CloudLinux: ich aktualizacje są oddzielne.

cPanel

Oficjalny komunikat potwierdza poprawki EasyApache4: ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5 oraz poprawione wersje 8.2–8.5 z tabeli powyżej. Dla samego panelu podano cPanel & WHM 110.0.153, 134.0.66, 136.0.50 i 138.0.18. To osobna aktualizacja względem PHP stron. Komunikat cPanel.

DirectAdmin

Programista fln potwierdził wydanie w kanałach current i stable: zaktualizowano PHP 8.2–8.5 i dodano poprawki dla PHP 7.4, 8.0 i 8.1. Na oficjalnym forum podano polecenia da update i da build php. Aktualizacja panelu nie uruchamia automatycznie kompilacji PHP, jeśli automatyzacja CustomBuild nie jest włączona. Sprawdź też przypięte wersje w custom_versions.txt.

Plesk

Opublikowana ocena NCSC-NL potwierdza poprawione kompilacje PHP 8.2–8.5 dla Linuksa. Starsze gałęzie, kompilacje Windows i wewnętrzny sw-engine wymagają osobnego sprawdzenia: poprawione PHP stron nie potwierdza aktualizacji samego panelu. Nie potwierdziliśmy dostępności poprawek wszystkich tych komponentów.

CloudLinux

Status z 22 października potwierdza poprawione alt-php w stable dla CloudLinux 7/8/9; dla CloudLinux 10 są dostępne przez przeznaczone dla niego repozytoria. Wydano też poprawione ea-php52–85. Część systemowych pakietów PHP nadal jest udostępniana stopniowo: odróżniaj je od alt-php i ea-php. Aktualny status CloudLinux.

Imunify360 automatycznie dostarcza reguły WAF 8.83–8.85, ale nie zastępują one poprawek PHP. CloudLinux ostrzega również, że aktualizacje security-only mogą nie wykazywać poprawionych pakietów do czasu publikacji metadanych bezpieczeństwa; sprawdź zwykłe aktualizacje i changelog pakietów.

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.

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.