Podatności CVE-2026-109618 i CVE-2026-109619 zwane php2shell
Wczoraj 21 października 2026 roku zespół rozwijający PHP opublikował aktualizacje bezpieczeństwa usuwające dwa krytyczne exploity oznaczone jako CVE-2026-109618 i CVE-2026-109619.
Obie luki otrzymały ocenę 9,2 na 10 w skali CVSS 4.0, co w tłumaczeniu na ludzki język jest alarmem nuklearnym. Dziury te umożliwiają zdalne wykonanie kodu na podatnym serwerze bez konieczności wcześniejszego uwierzytelnienia. Co to znaczy? Wyobraź sobie jak by to było nie mieć drzwi w mieszkaniu w ekwiwalent nocy oczyszczenia dla świata IT. Trochę słabo…
Jak podaje zespół odpowiedzialny za PHP w oficjalnych komunikatach, na podatność narażone są wersję od 5 wzwyż, czyli naście lat wstecz.
Wszyscy biją na alarm
Sprawa jest na tyle poważna, że CERT-EU oraz ENISA i instytucje współpracujące, i nawet FBI (tak, fbi) zaleciły organizacjom pilne zidentyfikowanie podatnych systemów i wdrożenie poprawek.
Kogo dotyczą te podatności? Czy mój WordPress jest bezpieczny?
W tym wypadku łatwiej jest dać znać, kogo nie dotyczą. W szczególności narażone są natomiast projekty oparte o:
- WordPress / WooCommerce
- Drupal
- Magento
- Joomla
- Prestashop
- Laravel
- Symfony
Jeżeli używacie w swoim biznesie jakiejkolwiek z tych rzeczy, a wasz administrator nie poinformował Was o aktualizacji… Niestety, jak to mawiają w internecie: kolega problem.
Ważne: aktualizacja WordPressa nie jest tym samym co aktualizacja PHP. Możesz mieć aktualną wersję CMS-a, a jednocześnie korzystać z podatnej wersji środowiska PHP na serwerze. Obie warstwy trzeba sprawdzić osobno.
Co zrobić, jak się ochronić?
21 października (i 22 października pewnie też) można było zauważyć wiele portali wyłączonych do czasu opublikowania łatki. Była to jedna z rekomendacji dla wszystkich, którzy nie byli w stanie pozwolić sobie na włam. Natomiast łatka została już opublikowana dla najnowszych wersji php8.
Wersje załatane
Poprawki zostały opublikowane kolejno w wersjach:
- PHP 8.2.35;
- PHP 8.3.36;
- PHP 8.4.27;
- PHP 8.5.12.
Dla starszych wersji zgodnie z komunikatami aktualizacje nie będą wprowadzane oficjalnymi kanałami dystrybucji. Systemy oparte na legacy muszą na prędkości się aktualizować, lub liczyć na łaskę niektórych dystrybutorów oraz community z backportami.
W twojej organizacji problem może być większy
Jeśli czytasz ten artykuł, cieszę się, że tu jesteś. Jeśli na co dzień pracujesz w branży, prawdopodobnie nie znajdziesz tu niczego, czego już nie wiesz. Jeśli jednak szukasz pomocy i nie wiesz, od czego zacząć, poniżej znajdziesz kilka wskazówek.
- Skontaktuj się z administratorem swojego serwisu / aplikacji bądź strony
- Poproś o informacje na temat tych dwóch luk, i czy zostały podjęte działania (jeżeli możesz, zadzwoń)
- Ważne! Jeżeli nie masz opłaconego wsparcia technicznego ani utrzymania aplikacji, wykonawca będzie musiał najprawdopodobniej Cię za to policzyć
- Uzbroić się w cierpliwość
Czy powinienem porzucić PHP?
Niekoniecznie. To wszystko zależy.
W wielu przypadkach wystarczające będzie zaktualizowanie środowiska, uporządkowanie zależności i wdrożenie właściwych procedur utrzymaniowych. W ostateczności będzie wymagało to tzw. “hardeningu”.
Są jednak sytuacje, w których warto rozważyć szerszą modernizację. Dotyczy to szczególnie systemów opartych na niewspieranych wersjach oprogramowania, porzuconych bibliotekach lub architekturze, której utrzymanie staje się coraz bardziej uciążliwe i drogie. Ostatnimi czasy php i serwisy takie jak WordPress, które na nim bazują borykają się z passą problemów i podatności w swoich systemach bezpieczeństwa. Pisaliśmy o tym w ostatnim artykule
[UPDATE] Luka była wykorzystywana już 4 tygodnie temu
Załatałeś PHP, ale czy na pewno jesteś bezpieczny? Nie jest to pewne. Researcherzy informują - zaobserwowano wykorzystywanie luk nawet 4 tygodnie przed 21 października.
Wszystkim zaleca się upewnić czy nie doszło do wykorzystania luki przed jej dojściem do szerszego grona ludzi.
Jak sprawdzić czy zostałem “trafiony” przez php2shell?
Poniżej podlinkujemy narzędzie, które pomaga wykryć wykorzystanie exploitu na Twoim serwerze. Nie odpowiadamy za nie osobiście. Przed uruchomieniem go na Twoim serwerze zalecamy upewnić się czy jest ono wolne od złośliwego oprogramowania. Jeżeli nie jesteś pewien, skontaktuj się z nami na patryk@svvandigital.com lub napisz do swojego administratora
https://gist.github.com/Sairahcaz/2c22b4a68fd5b75e410c7f9f69f485a0
Nie masz pewności, czy Twoja strona lub aplikacja jest odpowiednio zabezpieczona?
Sama aktualizacja PHP to dopiero pierwszy krok. Warto również upewnić się, że środowisko działa na wspieranej wersji, sprawdzić czy aplikacja nie korzysta z podatnych zależności, i potwierdzić, że serwer nie nosi śladów wcześniejszego włamania.
W ramach przeglądu bezpieczeństwa możemy:
- zweryfikować wersję PHP i sprawdzić, czy została załatana,
- ocenić, czy aktualizacja nie wymaga dodatkowych zmian w aplikacji,
- sprawdzić podstawowe konfiguracje bezpieczeństwa serwera i aplikacji,
- przeanalizować dostępne logi pod kątem podejrzanej aktywności,
- przygotować listę wykrytych problemów i rekomendowanych działań.
Nie musisz znać się na administracji serwerami. Potrzebujemy jedynie podstawowych informacji o Twojej stronie lub aplikacji, aby ustalić zakres weryfikacji.
Skontaktuj się z nami, aby omówić sytuację i ustalić zakres prac.
