--- title: "PHP2Shell: które wersje PHP są bezpieczne i co teraz zrobić" description: "Dwie krytyczne podatności PHP, CVE-2026-109618 i CVE-2026-109619, zostały naprawione w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Kogo dotyczą, które wersje są bezpieczne, co sprawdzić na serwerach i co zrobić, jeśli nadal używasz PHP 8.1 lub starszego." author: "Luboš Zápotočný" published: "2026-10-21" language: "pl" canonical: "https://zapolu.com/pl/blog/php2shell-aktualizacja-php/" --- # PHP2Shell: które wersje PHP są bezpieczne i co teraz zrobić 21 października 2026 roku projekt PHP wydał [PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35](https://www.php.net/archive/2026.php#2026-10-21-5) w celu usunięcia dwóch krytycznych podatności, CVE-2026-109618 i CVE-2026-109619. Obie pozwalają atakującemu wykonać dowolny kod na serwerze WWW bez uwierzytelnienia. Obie luki określa się wspólną nazwą PHP2Shell, od exploita, który badacze opracowali, łącząc oba błędy ([podsumowanie Sansec](https://sansec.io/research/php2shell)). W komunikacie bezpieczeństwa PHP czytamy, że „tylko aktualizacja jest pełnym rozwiązaniem”. Wszystkie podane niżej informacje o dostawcach sprawdziliśmy 21 października 2026 roku w źródłach, do których prowadzą odnośniki. ## Zakres zagrożenia Według [ogłoszenia PHP](https://www.php.net/archive/2026.php#2026-10-21-5) ryzyko obejmuje „wszystkie instalacje PHP obsługujące żądania WWW”, niezależnie od sposobu połączenia PHP z serwerem WWW. Dotyczy to aplikacji Magento, Mage-OS, WordPress, Drupal, Laravel i Symfony oraz każdego własnego kodu PHP. Sansec informuje, że badacze uruchomili kod bez logowania w Magento 2.4.9, WordPressie, Drupalu, Nextcloudzie i innych aplikacjach. PHP przetwarza request atakującego, zanim otrzyma go aplikacja, dlatego własny kod sklepu i jego rozszerzenia nie mogą zablokować ataku. Druga podatność może ponadto ujawnić zawartość pamięci serwera. Serwer, który działał na podatnej wersji i był dostępny z internetu, mógł ujawnić hasła, klucze API lub dane sesji. Po jego aktualizacji warto rozważyć zmianę używanych przez niego danych uwierzytelniających. Sprzedawcy korzystający z Shopify nie mają własnej instalacji PHP do aktualizacji, ponieważ platformę hostuje Shopify ([FAQ Shopify](https://www.shopify.com/faq)). Własne aplikacje napisane w PHP i hostowane na Twoich serwerach są zagrożone tak samo jak każdy inny kod PHP. ## Bezpieczne wersje | Gałąź | Bezpieczna od | Koniec wsparcia bezpieczeństwa | | ------ | --------- | --------------------- | | 8.5 | 8.5.12 | 31 grudnia 2029 r. | | 8.4 | 8.4.27 | 31 grudnia 2028 r. | | 8.3 | 8.3.36 | 31 grudnia 2027 r. | | 8.2 | 8.2.35 | 31 grudnia 2026 r. | | 8.1 i starsze | brak poprawki od projektu PHP | zakończone | Daty wsparcia pochodzą ze [strony obsługiwanych wersji](https://www.php.net/supported-versions.php) PHP. System działający na PHP 8.2 wymaga natychmiastowej aktualizacji, a przed końcem roku także przejścia na nowszą gałąź, chyba że korzysta z własnych pakietów PHP Debiana 12, które utrzymuje zespół długoterminowego wsparcia Debiana ([DLA-4848-1](https://security-tracker.debian.org/tracker/DLA-4848-1)). ## Kontrola serwerów Instalacja aktualizacji zwykle przebiega szybko. Największe ryzyko polega na przekonaniu, że została zainstalowana, choć tak nie jest. Oto pytania, które warto zadać administratorowi Twoich serwerów: - **Którą wersję PHP faktycznie uruchamia serwer WWW?** Może się ona różnić od wersji widocznej w wierszu poleceń, a na jednym serwerze może działać równolegle kilka wersji PHP. - **Czy numer wersji potwierdza obecność poprawki?** Ubuntu na przykład dodaje poprawkę do swojego starszego pakietu PHP, dlatego zaktualizowany serwer z Ubuntu 24.04 nadal wyświetla wersję PHP 8.3.6 ([komunikat Ubuntu](https://ubuntu.com/security/notices/USN-8948-1)). W takim przypadku z komunikatem dostawcy musi się zgadzać wersja pakietu. - **Czy PHP zostało zrestartowane po aktualizacji?** Działający proces PHP przechowuje stary kod w pamięci aż do restartu. - **Czy obrazy Dockera zostały przebudowane?** Działający kontener nie aktualizuje się sam. Oficjalne obrazy PHP w Docker Hub zostały przebudowane z poprawionymi wersjami jeszcze tego samego dnia, 21 października, dlatego obraz zbudowany na ich podstawie przed tą przebudową nadal zawiera podatną wersję. - **Czy zajmuje się tym dostawca hostingu?** W przypadku Adobe Commerce on Cloud [strona ustawień PHP](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/configure/app/php-settings) Adobe nie podaje, kiedy aktualizowane jest wydanie poprawkowe PHP, a 21 października nie znaleźliśmy komunikatu Adobe o tych podatnościach. Sprawdź wersję po najbliższym wdrożeniu, a jeśli nadal jest niższa od bezpiecznego wydania, zwróć się do pomocy technicznej Adobe. ## Sklepy Magento w starszych wersjach Według [wymagań systemowych](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements) Adobe sklep Magento może działać tylko na określonych wersjach PHP. Sklepy w wersjach 2.4.8 i 2.4.9 mogą już dziś przejść na bezpieczne wydanie. Sklep w wersji 2.4.7 może działać na PHP 8.3, co jest lepszym wyborem niż 8.2. Najnowsze wydania poprawkowe wersji 2.4.4 i 2.4.5 obsługują wyłącznie PHP 8.1, które nie otrzymuje już poprawek od projektu PHP, a same te linie wydań nie są już objęte wsparciem bezpieczeństwa Adobe ([polityka cyklu życia](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy)). Do czasu aktualizacji Magento taki sklep jest zdany na poprawkę od dostawcy systemu operacyjnego (następna sekcja). ## PHP 8.1 i starsze Projekt PHP nie publikuje już nowych wydań gałęzi 8.1 ani starszych. Opublikował minimalne poprawki w postaci kodu źródłowego dla wersji 8.1, 8.0 i 7.4 i odsyła użytkowników do ich dostawców. Niektórzy dostawcy już je udostępnili: - **Ubuntu** naprawiło PHP 8.1 w Ubuntu 22.04 w ramach zwykłych aktualizacji ([USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)), a starsze wersje PHP w starszych wydaniach Ubuntu dla klientów Ubuntu Pro ([USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)). - **Repozytoria Ondřeja Surý'ego**, popularne źródło PHP dla Debiana i Ubuntu, opublikowały poprawione pakiety PHP w wersjach od 5.6 do 8.1 ([PPA](https://launchpad.net/~ondrej/+archive/ubuntu/php)). - **Red Hat** poprawił pakiety PHP 7.4 w RHEL 8, ale dla pozostałych wersji PHP w RHEL 8, 9 i 10 nie udostępnił jeszcze poprawki ([dane Red Hat](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-109618.json)). Projekt PHP określa te poprawki jako „minimalne zabezpieczenie dla wersji EOL”. Zamykają one znane ścieżki ataku w wersji, która nie otrzymuje żadnych innych poprawek bezpieczeństwa. Aktualizacja do wspieranej wersji PHP nadal jest konieczna. ## Środki doraźne przed aktualizacją PHP wymienia zmiany konfiguracji, które obniżają ryzyko, i zaznacza, że „ograniczają one narażenie na określone ścieżki ataku, ale nie czynią instalacji bezpieczną”. Należą do nich wyłączenie śledzenia postępu przesyłania w sesji (session upload progress) i zmniejszenie maksymalnego rozmiaru requestu, a pełna lista znajduje się w [ogłoszeniu PHP](https://www.php.net/archive/2026.php#2026-10-21-5). Cloudflare również [wdrożył reguły zapory](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) chroniące przed tymi podatnościami. Oba środki obniżają ryzyko do czasu instalacji aktualizacji. Jako rozwiązanie tymczasowe sugeruje się czasem blokowanie requestów multipart, czyli formatu, którego przeglądarki używają do przesyłania plików. Jak wynika z [analizy Sansec](https://sansec.io/research/php2shell), w sklepie Magento blokuje to także przesyłanie zdjęć produktów w panelu Admin, a w niektórych sklepach również koszyk lub checkout. Po każdej takiej zmianie złóż zamówienie testowe. ## Stan wykorzystania podatności Cloudflare informuje, że szczegóły wyciekły przed wydaniem, i pisze: „zaobserwowaliśmy ruch wymierzony w naszych klientów” ([wpis Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)). Gdy sprawdzaliśmy 21 października, żadnej z tych CVE nie było jeszcze w katalogu CISA [Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Jeśli nie masz pewności, na jakiej wersji PHP działają Twoje serwery ani czy aktualizacja dotarła do każdego z nich, możemy je sprawdzić i przeprowadzić aktualizację. Utrzymywanie aktualnej wersji PHP jest częścią naszej [stałej opieki](/pl/services/ongoing-care/), a jednorazową aktualizację wystarczy zlecić, wysyłając nam [wiadomość](/pl/contact/).