21 października 2026 | PHP | Bezpieczeństwo IT
21 października 2026 zespół bezpieczeństwa PHP opublikował aktualizacje dla wszystkich nadal wspieranych wersji PHP. Zamykają one dwie krytyczne podatności, znane jako PHP2Shell. BSI wydał w tej sprawie ostrzeżenie i żąda, by dotknięte systemy załatać niezwłocznie. Kto prowadzi serwer WWW z PHP, powinien działać jeszcze dziś. Dotyczy to także wszystkich, którzy „tylko” prowadzą WordPress, Nextcloud lub Joomla, ponieważ te aplikacje działają na PHP.
Ten artykuł podsumowuje, co się stało, które wersje PHP są dotknięte, jakiej wersji potrzeba teraz i jak w kilka minut sprawdzić, czy serwer jest zabezpieczony.
Spis treści tego artykułu
- Co się stało? Przebieg w czasie
- Obie podatności PHP w skrócie
- Kogo to dotyczy?
- Te wersje PHP są bezpieczne
- Jak sprawdzić i zaktualizować serwer
- PHP 8.1 i starsze: brak oficjalnej aktualizacji
- Środki przejściowe i pytanie „Wyłączyć serwer z sieci?”
- Najczęstsze pytania
- Wsparcie ze strony Biricon IT Services
Co się stało? Przebieg w czasie
Zespół bezpieczeństwa PHP zapowiedział publikację poprawek z wyprzedzeniem, aby hosterzy i administratorzy mieli czas na przygotowanie. Sama publikacja miała miejsce 21 października 2026. BSI wydał swoje ostrzeżenie (wersja 1.1) jeszcze tego samego dnia.
- 20 października 2026: Wcześniejsze ostrzeżenie zespołu bezpieczeństwa PHP, że następnego dnia pojawią się aktualizacje bezpieczeństwa.
- 21 października 2026, 14:00 UTC (16:00 czasu CEST): Poprawki dla PHP 8.5, 8.4, 8.3 i 8.2 zostają opublikowane.
- 21 października 2026: BSI ostrzega przed „krytycznymi podatnościami, które zagrażają aplikacjom webowym na całym świecie” i zaleca niezwłoczne załatanie. Według informacji BSI więksi dostawcy hostingu częściowo prewencyjnie wyłączyli serwery z sieci.
Obie podatności PHP w skrócie
Chodzi o dwa oddzielne błędy w jądrze PHP: CVE-2026-109618 i CVE-2026-109619. Oba mogą według informacji zespołu bezpieczeństwa PHP prowadzić do tego, że atakujący może wykonać kod programu na serwerze bez logowania (unauthenticated Remote Code Execution). Podatności są oceniane na CVSS v4.0: 9,2 (krytyczna).
| Cecha | Znaczenie |
|---|---|
| Identyfikatory | CVE-2026-109618 i CVE-2026-109619 |
| Ocena | CVSS v4.0: 9,2 — krytyczna |
| Skutek | Wykonanie kodu na serwerze (Remote Code Execution), bez logowania |
| Przyczyna 1 | Uszkodzona pamięć, gdy PHP podczas przetwarzania nie dostaje już pamięci operacyjnej (Out-of-Memory) |
| Przyczyna 2 | Przestarzały stan globalny, który pozostaje w pamięci między żądaniami |
| Szczególnie zagrożone | Apache z mod_php |
Według oceny BSI w momencie publikacji nie było potwierdzonych ataków, były jednak niepotwierdzone wskazówki o próbach wykorzystania. W przypadku krytycznych luk w tak szeroko rozpowszechnionym oprogramowaniu należy, jak uczy doświadczenie, liczyć się z tym, że atakujący analizują poprawki i przygotowują zautomatyzowane ataki. Okno czasowe na załatanie jest dlatego krótkie.
Kogo to dotyczy?
Dotknięty jest zasadniczo każdy serwer, na którym działa PHP, niezależnie od tego, jak PHP jest podłączone: PHP-FPM, mod_php w Apache, php-cgi, FrankenPHP lub LiteSpeed. Najwyższe jest ryzyko według zespołu bezpieczeństwa PHP w przypadku Apache z mod_php.
BSI wyraźnie wymienia aplikacje, które opierają się na PHP i dlatego mogą być współdotknięte:
- Systemy zarządzania treścią: WordPress, Drupal, TYPO3, Joomla
- Systemy sklepowe: Magento
- Chmura i składowanie plików: Nextcloud
- Interfejsy firewalli: pfSense, OPNsense
Sama aplikacja nie musi być w tym celu wadliwa. Luka leży w PHP, dlatego aktualizacja samego WordPress, Nextcloud & spółki nie pomaga. Należy zaktualizować wersję PHP na serwerze. W przypadku firewalli takich jak pfSense i OPNsense poprawiona wersja PHP przychodzi z odpowiednią aktualizacją firmware producenta.
Te wersje PHP są bezpieczne
Podatności są naprawione w poniższych wersjach. Wszystko poniżej uchodzi za podatne.
| Gałąź PHP | Wymagane minimum | Uwaga |
|---|---|---|
| PHP 8.5 | 8.5.12 | bieżąca gałąź |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Wsparcie kończy się 31 grudnia 2026 |
| PHP 8.1 i starsze | brak oficjalnej aktualizacji, patrz na dole | |
Jak sprawdzić i zaktualizować serwer
1. Ustalić zainstalowaną wersję PHP
W wierszu poleceń serwera php -v pokazuje wersję PHP wiersza poleceń. Serwer WWW może używać innej wersji PHP. Należy dlatego sprawdzić także wersję PHP-FPM, względnie modułu Apache, na przykład za pomocą php-fpm8.3 -v lub przez stronę, która wyświetla phpinfo() (następnie natychmiast ją usunąć).
2. Zainstalować aktualizację przez menedżer pakietów
W Debianie, Ubuntu, RHEL i pokrewnych poprawiona wersja przychodzi przez zwykły menedżer pakietów, na przykład apt update && apt upgrade lub dnf upgrade. W przypadku obcych źródeł, takich jak Sury-PPA czy repozytorium Remi, nowe pakiety pojawiają się zwykle szybko.
apt changelog php8.3-fpm lub rpm -q --changelog php | grep CVE-2026-1096).
3. Zrestartować usługę PHP
Sama aktualizacja pakietu nie wystarczy: działające procesy PHP zachowują stary kod w pamięci. Należy zrestartować PHP-FPM (systemctl restart php8.3-fpm) względnie Apache (systemctl restart apache2) i sprawdzić potem, czy procesy zostały uruchomione po aktualizacji.
4. Strony na hostingu
W przypadku hostingu współdzielonego aktualizuje z reguły dostawca. W menu klienta zwykle można ustawić wersję PHP dla każdej strony. Należy wybrać tam jedną z podanych wyżej bezpiecznych wersji lub zapytać dostawcę o stan poprawek. Według informacji BSI niektórzy dostawcy prewencyjnie odłączyli serwery od sieci. Jeśli strona jest chwilowo niedostępna, może to być przyczyną.
PHP 8.1 i starsze: brak oficjalnej aktualizacji
Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji bezpieczeństwa. Operatorzy takich systemów mają dwie możliwości:
- Przejść na wspieraną wersję (zalecane). Im starsza wersja, tym większy nakład na dostosowanie aplikacji i rozszerzeń, dlatego zmianę należy wcześniej przetestować.
- Przenieść poprawki wstecz (backport). Zespół bezpieczeństwa PHP udostępnił poprawki w gałęziach rozwojowych na GitHubie. Kto kompiluje PHP samodzielnie, może przenieść te zmiany do starszych wersji. To rozwiązanie przejściowe i wymaga wiedzy fachowej.
Także PHP 8.2 jest wspierane tylko do 31 grudnia 2026. Należy dlatego zaplanować przejście na PHP 8.4 lub 8.5 już teraz i nie odkładać go na przełom roku.
Środki przejściowe i pytanie „Wyłączyć serwer z sieci?”
Zespół bezpieczeństwa PHP opisał wraz z zapowiedzią także tymczasowe środki ochronne. Zmniejszają one ryzyko, ale nie zamykają luk całkowicie. Nie zastępują aktualizacji i mają służyć wyłącznie do przeczekania czasu do aktualizacji.
To, czy serwer do czasu aktualizacji powinien zostać odłączony od sieci, zależy od jego znaczenia i dostępności. BSI wskazuje, że więksi dostawcy zrobili ten krok. Obowiązuje zasada praktyczna:
- Serwer publicznie dostępny, aktualizacja możliwa teraz: załatać natychmiast, wyłączanie nie jest potrzebne.
- Serwer publicznie dostępny, aktualizacja niemożliwa w krótkim czasie: ograniczyć dostęp (na przykład firewallem tylko dla znanych adresów) lub tymczasowo wyłączyć usługę, zwłaszcza przy
mod_php. - Serwer dostępny tylko wewnętrznie: załatać w rozsądnym czasie, pilność jest mniejsza.
Najczęstsze pytania
Czy muszę zaktualizować WordPress, Joomla lub Nextcloud?
Nie z powodu tej luki. Znajduje się ona w PHP, a nie w aplikacji. Proszę zaktualizować wersję PHP na serwerze. Aktualizacja samej aplikacji jest mimo to niezależnie od tego wskazana.
Po czym poznać, czy ktoś już wykorzystał tę lukę?
Pewna odpowiedź jest trudna. Niepokojące są nieznane pliki PHP w katalogu serwera WWW, nietypowe procesy uruchomione przez użytkownika serwera WWW, nowe konta użytkowników lub zadania cron oraz nietypowy ruch wychodzący. W razie konkretnego podejrzenia system należy poddać analizie śledczej, a w razie wątpliwości zainstalować go od nowa.
Czy wystarczy Web Application Firewall?
Zapora może przechwycić znane wzorce ataków, ale nie zastępuje aktualizacji. Więcej o współdziałaniu kilku warstw ochrony przeczytają Państwo w naszym wpisie Zabezpieczenie Odoo 19: zapora, 2FA & Web RBL. Zasady te obowiązują dla każdej aplikacji internetowej.
Czy Odoo jest dotknięte?
Nie. Odoo jest napisane w Pythonie i nie działa na PHP. Zagrożone byłyby tylko aplikacje PHP uruchomione na tym samym serwerze.
Gdzie znajdę oficjalne informacje?
Komunikat zespołu bezpieczeństwa PHP znajdą Państwo w archiwum wiadomości na php.net (wpis z 20 października 2026 r.), wersje pod adresem php.net/downloads. Ostrzeżenie BSI nosi numer 2026-297981-1032 i zostało opublikowane na stronie bsi.bund.de .
Wsparcie ze strony Biricon IT Services
Jeśli nie są Państwo pewni, jaka wersja PHP działa na Państwa serwerze, lub potrzebują pomocy przy instalacji poprawek, chętnie Państwa wesprzemy: przy inwentaryzacji wszystkich systemów PHP, przy instalowaniu aktualizacji, przy przejściu na wspieraną wersję PHP oraz przy sprawdzaniu pod kątem włamania. Jako usługodawca IT opiekujemy się serwerami, zaporami i aplikacjami internetowymi dla małych i średnich firm.
Stan na 21 października 2026 r. Sytuacja może się szybko zmienić; rozstrzygające są publikacje zespołu bezpieczeństwa PHP i BSI.