Śledź Administratorzy PHP stają przed koniecznością pilnej aktualizacji zabezpieczeń po ogłoszeniu przez opiekunów wydania poza cyklem, które dotyczy dwóch krytycznych luk. Wady, śledzone przez badaczy bezpieczeństwa jako CVE-2026-109618 i CVE-2026-109619, otrzymały od zespołu bezpieczeństwa PHP ocenę CVSS v4.0 na poziomie 9.2. Badacze z watchTowr opisują oba problemy jako luki umożliwiające zdalne wykonanie kodu.
Wydanie awaryjne zaplanowano na 21 października 2026 roku o godzinie 14:00 UTC. PHP przyspieszyło ujawnienie informacji po tym, jak informacje o lukach wyciekły przed planowaną datą skoordynowanego wydania. W momencie pisania tego tekstu, PHP nie ujawniło wrażliwych komponentów, wymagań dotyczących eksploatacji, dotkniętych wydań ani technicznych przyczyn podstawowych i mówi, że te szczegóły zostaną dołączone do aktualizacji zabezpieczeń.
Badacze nieformalnie nazwali parę podatności „PHP2Shell”, choć nazwa ta nie pochodzi od Projektu PHP. Wczesny wyciek twierdził, że luki te mogą dotyczyć wydań PHP sięgających PHP 5 i przypisano im oceny CVSS 10.0. Jednakże oficjalna ocena PHP wynosi 9.2, a twierdzenia o zakresie wersji nie zostały jeszcze potwierdzone przez oficjalne doradztwo sprzedawcy.
Mimo to potencjalny wpływ jest znaczny. PHP napędza ogromną liczbę stron internetowych, aplikacji webowych, systemów zarządzania treścią, platform e-commerce, API, paneli hostingowych i usług korporacyjnych na zamówienie. Jeśli zdalne wykonanie kodu zostanie potwierdzone w powszechnie wdrażanych konfiguracjach, udana eksploatacja mogłaby dać atakującym bezpośrednią drogę od narażonej aplikacji internetowej do kompromitacji na poziomie serwera.
Zespoły ds. bezpieczeństwa poszukujące możliwości wykrywania CVE-2026-109618 powinny priorytetyzować monitorowanie oparte na zachowaniu, podczas gdy sygnatury specyficzne dla eksploatacji pozostają niedostępne. Podejrzana aktywność obejmuje nieoczekiwane uruchamianie powłok, interpretatorów, narzędzi wiersza poleceń lub narzędzi pobierania przez procesy PHP lub serwera sieciowego.
Klienci SOC Prime mogą korzystać z platformy AI-Native Detection Intelligence, aby uzyskać dostęp do ciągle aktualizowanej treści detekcyjnej dotyczącej wykorzystywania podatności i powiązanego zachowania po kompromitacji. Zasady wykrywania można stosować w różnych środowiskach SIEM, EDR i Data Lake oraz dostosowywać do ram ATT&CK® MITRE.
Kliknij Odkryj wykrycia aby uzyskać dostęp do odpowiednich treści SOC dotyczących pojawiających się podatności. Aby wykryć CVE-2026-109619 i powiązane próby eksploatacji, obrońcy powinni połączyć analizę behawioralną z telemetrią serwera sieciowego, punktu końcowego i sieci, gdy tylko stanie się dostępna inteligencja techniczna.
Zespoły ds. bezpieczeństwa mogą również korzystać z Prime Architect, aby przekształcić pojawiającą się inteligencję dotyczącą podatności w zasady Sigma i niestandardowe zapytania do polowania, zatwierdzać logikę wykrywania, wizualizować potencjalne przepływy ataku i szybko przetłumaczyć treści detekcyjne w obsługiwanych platformach bezpieczeństwa.
Skontaktuj się z działem sprzedaży
Analiza CVE-2026-109618 i CVE-2026-109619
W dniu 20 października 2026 roku zespół bezpieczeństwa PHP wydał wstępne ostrzeżenie, że dwie krytyczne luki zostaną zaadresowane poprzez wyjątkową aktualizację zabezpieczeń następnego dnia. Obie otrzymały ocenę CVSS v4.0 na poziomie 9.2, a administratorzy zostali wezwani do przygotowania się do natychmiastowych aktualizacji. PHP zastrzegło sobie również możliwość wcześniejszego wydania poprawek, jeśli informacje techniczne zostaną upublicznione lub wykryta zostanie aktywna eksploatacja.
Ogłoszenie to było następstwem wycieku informacji o dwóch ukrytych podatnościach. Opublikowany materiał zidentyfikował CVE-2026-109618 i CVE-2026-109619 oraz scharakteryzował obie jako luki umożliwiające zdalne wykonanie kodu. Następnie watchTowr potwierdziło dla BleepingComputer, że podatności są realne i dodało, że jego badacze uważają, że udało im się pomyślnie zreprodukować jedną z nich.
Istnieją jednak istotne różnice między informacjami ujawnionymi w wycieku a tym, co oficjalnie potwierdziło PHP.
PHP przypisało obu lukom ocenę CVSS v4.0 na poziomie 9.2, w przeciwieństwie do oceny CVSS 10.0 krążącej w wycieku. PHP nie potwierdziło również, które gałęzie są narażone, czy eksploatacja wymaga konkretnego modelu wdrażania PHP lub konfiguracji, ani czy wymagana jest autoryzacja.
Twierdzenie, że CVE-2026-109618 wpływa na wersje PHP 5, 6, 7 i 8 pochodzi od badacza oraz wyciekły informacje, a nie oficjalne doradztwo PHP. watchTowr sam zauważa, że zakres ten nie został jeszcze potwierdzony przez sprzedawcę.
Dlatego szczegółowa analiza CVE-2026-109618 musi oddzielić potwierdzone fakty od wstępnych badań. To, co jest obecnie potwierdzone, to że PHP uważa dwie luki za krytyczne, ocenia obie na 9.2 i uważa, że ryzyko wymaga awaryjnego wydania zabezpieczeń poza cyklem. Badacze charakteryzują wady jako luki RCE, ale ich podstawowe mechanizmy pozostają w ukryciu.
To rozróżnienie ma znaczenie również przy ocenie starszych środowisk PHP. Projekt PHP obecnie zapewnia aktualizacje zabezpieczeń tylko dla obsługiwanych gałęzi od 8.2 do 8.5. PHP 8.2 i 8.3 otrzymują poprawki zabezpieczeń, podczas gdy 8.4 i 8.5 pozostają pod aktywnym wsparciem. Starsze gałęzie, w tym PHP 8.1, 8.0, PHP 7.x i PHP 5.x, są zakończone i nie otrzymają poprawek upstream, jeśli okażą się ostatecznie narażone.
Może to stworzyć szczególnie trudny scenariusz naprawczy dla organizacji obsługujących stare aplikacje, które nie mogą być łatwo migrowane. Systemy PHP, mające styczność z Internetem, byłyby istotnym zagrożeniem, jeśli zgłaszana szeroka ekspozycja wersji zostanie potwierdzona.
Nie ma dostępnego publicznie PoC dla CVE-2026-109618 w momencie pisania. watchTowr twierdzi, że wierzy, iż pomyślnie odtworzyło problem, ale celowo wstrzymuje informacje techniczne do momentu, gdy dostępne będą poprawki zabezpieczeń. Huntress również nie odtworzył podatności i nie był świadomy publicznie dostępnego kodu exploitu.
Do 21 października nie zaobserwowano aktywnej eksploatacji przez badaczy cytujących w obu raportach. W momencie raportu The Hacker News, podatności te nie były również wymienione w katalogu znanych wykorzystywanych podatności CISA.
W konsekwencji, IOCs dla CVE-2026-109619 nie zostały jeszcze opublikowane. Obecnie nie ma potwierdzonych złośliwych adresów IP, domen, skrótów ładunków, wzorców żądań exploita lub innych wskaźników specyficznych dla kampanii bezpośrednio związanych z eksploatacją tej podatności.
Do czasu udostępnienia szczegółów exploita obrońcy powinni zamiast tego monitorować ogólne oznaki naruszeń serwera PHP. Cenne działania obejmują spawning powłok przez php-fpm, php-cgi, httpd lub apache2, silniki skryptów, narzędzia do pobierania lub inne nieoczekiwane wykonywalne. Nowe web shels, niewyjaśnione modyfikacje w katalogu głównym sieci, zadania cron, zaplanowane zadania, nowo utworzone konta i anormalne połączenia wychodzące powinny również wywołać dochodzenie.
Oczekuje się, że precyzyjne szczegóły CVE-2026-109619 wyjaśnią wrażliwy komponent PHP, wymagania ataku, dotknięte gałęzie, zależności konfiguracyjne i wersje naprawione, gdy tylko PHP opublikuje wydanie zabezpieczeń.
Łagodzenie skutków CVE-2026-109618 i CVE-2026-109619
Administratorzy PHP powinni najpierw zbudować dokładny inwentarz każdego wdrożenia PHP w środowisku. Obejmuje to konwencjonalne serwery internetowe Linuksa i Windows, a także środowiska uruchomieniowe PHP wbudowane w urządzenia, aplikacje firm trzecich, platformy hostingowe i produkty administracyjne, takie jak cPanel lub Plesk.
W celu natychmiastowego łagodzenia skutków CVE-2026-109619, organizacje powinny przygotować się na wdrożenie awaryjnej aktualizacji zabezpieczeń PHP, jak tylko dostępne będą wydania poprawione. Aplikacje internetowe powiązane z Internetem powinny uzyskać najwyższy priorytet, ponieważ systemy dostępne zdalnie zazwyczaj oferują największą możliwość eksploatacji.
Organizacje korzystające z paczek PHP dostarczanych przez dystrybucję powinny sprawdzić swojego dostawcę Linuksa lub dostawcę hostingu pod kątem aktualizacji zabezpieczeń z powrotem, zamiast zakładać, że sam numer wersji PHP determinować będzie ekspozycję.
Starsze instalacje PHP wymagają szczególnej uwagi. Jeśli narażona aplikacja działa na wersji PHP, która wygasła i dla której nie ma dostępnej oficjalnej poprawki, organizacje powinny priorytetowo potraktować migrację do obsługiwanej wersji. Gdy natychmiastowa migracja nie jest możliwa, należy zmniejszyć ekspozycję, ograniczając dostęp zewnętrzny, umieszczając aplikację za odpowiednimi kontrolami sieciowymi lub tymczasowo izolując system.
Wytyczne CERT-EU, na które powołuje się The Hacker News, zalecają rozważenie izolacji aplikacji powiązanych z Internetem od publicznych sieci, gdy nie można natychmiast zastosować poprawki.
Obrońcy powinni dodatkowo wzmocnić monitorowanie wokół wykonywania PHP. Alarmuj, gdy pracownicy PHP lub procesy serwera internetowego uruchamiają narzędzia takie jak powłoki, PowerShell, Bash, Python, Perl, curl, wget lub inne programy, które są nieoczekiwane dla aplikacji.
Jeśli podejrzewana jest eksploatacja, należy odizolować dotknięty serwer i zabezpieczyć dowody przed naprawą. Odpowiednie artefakty obejmują:
- Logi dostępu i błędów serwera sieciowego
- Logi aplikacji PHP i środowiska wykonawczego
- Telemetria punktów końcowych i procesów
- Niedawno utworzone lub zmodyfikowane pliki
- Zawartość katalogu głównego serwera sieciowego
- Zadania cron i zaplanowane zadania
- Nowo utworzone konta lub klucze SSH
- Połączenia sieciowe wychodzące
- Działania uwierzytelniania i administracyjne
Zespoły ds. bezpieczeństwa powinny również przeprowadzać retrospektywne polowania po opublikowaniu wskaźników technicznych. Jeśli wzorce zapytań HTTP specyficzne dla exploita lub cechy charakterystyczne ładunku staną się publiczne, historyczna telemetria sieciowa i proxy mogła zidentyfikować próby kompromitacji, które miały miejsce przed zastosowaniem poprawek.
Organizacje powinny unikać polegania wyłącznie na WAF jako trwałym zamienniku poprawek. Do czasu ujawnienia technicznych przyczyn podstawowych nie ma potwierdzonej ogólnej zasady WAF, która może niezawodnie blokować obie podatności bez znajomości mechanizmów ich eksploatacji.
Korzystając z platformy AI-Native Detection Intelligence Platform firmy SOC Prime, zespoły ds. bezpieczeństwa mogą stale wzmacniać swoją pozycję wykrywania, gdy pojawia się nowa inteligencja dotycząca tych podatności PHP.
Zastrzeżenie: Treści dotyczące wykrywania mogą nie być dostępne dla każdego CVE. Sprawdź platformę SOC Prime, aby uzyskać informacje o bieżącym pokryciu. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdzaj regularnie, ponieważ nowa inteligencja zagrożeń i treści wykrywania są stale dodawane.
FAQ
Co to są CVE-2026-109618 i CVE-2026-109619 i jak działają?
CVE-2026-109618 i CVE-2026-109619 to dwa krytyczne podatności PHP, które badacze z watchTowr opisują jako luki umożliwiające zdalne wykonanie kodu. PHP oficjalnie potwierdziło dwa krytyczne problemy z ocenami CVSS v4.0 wynoszącymi 9.2, ale nie ujawniło jeszcze ich technicznych przyczyn podstawowych ani mechanizmów eksploatacji. W momencie pisania tego tekstu, nie ma więc możliwości wiarygodnego opisania dokładnego przepływu ataku. Oczekuje się, że PHP opublikuje informacje techniczne z jego awaryjnym wydaniem zabezpieczeń.
Kiedy CVE-2026-109618 i CVE-2026-109619 zostały po raz pierwszy odkryte?
Informacje o podatnościach stały się publiczne 20 października 2026 r., po tym jak szczegóły dwóch embargowanych podatności PHP rzekomo wyciekły przed planowanym ujawnieniem. PHP później tego samego dnia wydało oficjalne ostrzeżenie i zaplanowało awaryjne wydanie zabezpieczeń na 21 października 2026 r., o godzinie 14:00 UTC.
Jaki jest wpływ CVE-2026-109618 i CVE-2026-109619 na systemy?
Badacze bezpieczeństwa charakteryzują obie luki jako problemy z zdalnym wykonywaniem kodu. Jeśli ta ocena zostanie potwierdzona przez PHP, udana eksploatacja mogłoby potencjalnie umożliwić atakującemu wykonanie kodu na narażonym serwerze PHP i kontynuowanie wdrażania złośliwego oprogramowania, kradzieży poświadczeń, utrzymywania się, przemieszczania bocznego lub dostępu do danych w zależności od przywilejów dotkniętych usługami. PHP nie opublikowało jeszcze precyzyjnych warunków eksploatacji, więc dokładny wpływ i wymagania pozostają zależne od nadchodzącego doradztwa sprzedawcy.
Czy CVE-2026-109618 i CVE-2026-109619 nadal mogą mnie dotyczyć w 2026 roku?
Tak. Na dzień 21 października 2026 r. zaplanowano wydanie awaryjnego zabezpieczenia na godzinę 14:00 UTC, a podatności pozostają niezałatane w obecnie wdrożonych wersjach. Badacze twierdzili, że wersje PHP sięgające PHP 5 mogą być dotknięte, ale PHP nie potwierdziło oficjalnie tego zakresu wersji. Organizacje powinny zinwentaryzować wszystkie wdrożenia i użyć nadchodzącego doradztwa sprzedawcy, aby określić rzeczywistą ekspozycję.
Jak mogę się chronić przed CVE-2026-109618 i CVE-2026-109619?
Przygotuj się do natychmiastowej instalacji aktualizacji zabezpieczeń PHP, gdy zostaną one wydane, priorytetowo traktując serwery powiązane z Internetem. Wykonaj inwentaryzację instalacji PHP, w tym środowisk uruchomieniowych umieszczonych w aplikacjach i urządzeniach, oraz zidentyfikuj systemy działające na wygasłych gałęziach. Dopóki poprawki nie zostaną wdrożone, zwiększ monitorowanie dla nietypowych procesów potomnych PHP i wykonywania poleceń po stronie serwera. Systemy, które nie mogą być szybko załatane, powinny mieć zmniejszoną ekspozycję zewnętrzną lub, tam gdzie to możliwe operacyjnie, być tymczasowo izolowane. Jeśli zostanie wykryta podejrzana aktywność, odizoluj serwer i zabezpiecz telemetrię sieciową, PHP, punktu końcowego i serwera sieciowego do badania kryminalistycznego.
