--- title: "PHP2Shell: przewodnik dotyczący przyczyn i środków zaradczych" description: "Poznaj wady cyklu życia PHP2Shell, aktualizacje środowiska wykonawczego, tymczasowe środki zaradcze, wybór poprawek i weryfikację poprzez bieżącą ścieżkę żądania Web." language: "pl" url: "https://keendigit.com/pl/insights/php2shell-remediation-guide" author: "KeenDigit" published: "2026-10-22" --- # PHP2Shell: przewodnik dotyczący przyczyn i środków zaradczych Poznaj wady cyklu życia PHP2Shell, aktualizacje środowiska wykonawczego, tymczasowe środki zaradcze, wybór poprawek i weryfikację poprzez bieżącą ścieżkę żądania Web. **Źródła sprawdzone na dzień 22 października 2026 r.** **Audience: PHP operatorzy aplikacji, osoby odpowiedzialne za bezpieczeństwo i inżynierowie obsługujący niestandardowe kompilacje PHP.** W tym artykule podsumowano przyczynę, zakres wpływu, formalny proces naprawy, tymczasowe środki zaradcze i oficjalną implementację łaty luki PHP2Shell. Tekst główny jest cytowany przy użyciu numerów, takich jak [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1); wszystkie linki źródłowe są wymienione w załączniku na końcu tekstu. Fragment konfiguracji to szablon wdrożenia, który należy dostosować w oparciu o rzeczywistą wersję, możliwości biznesowe i relację dziedziczenia konfiguracji. ## TL;DR: Kroki naprawy i sugestie 1. **Zaktualizuj środowisko wykonawcze PHP**: zaktualizuj odpowiednią gałąź do co najmniej **8.2.35, 8.3.36, 8.4.27 lub 8.5.12**. W przypadku pakietów dystrybucyjnych użyj pełnej wersji pakietu, która według dostawcy zawiera poprawki dla obu CVE. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-10) 2. **Zastąp wszystkie stare procesy**: uruchom ponownie lub przywróć każdą PHP worker, usługę hostingową i kontener po aktualizacji i potwierdź, że stare instancje zostały zakończone. 3. **Sprawdź poprzez rzeczywistą ścieżkę żądania Web**: sprawdź Web SAPI, pełną wersję pakietu i działającą instancję. Samo sprawdzenie `php -v` nie gwarantuje, że usługa na żywo jest naprawiona. 4. **Uruchom sprawdzanie regresji biznesowej i przywróć normalne budżety zasobów**: logowanie testowe, obsługa sesji, przesyłanie, importowanie i obsługa błędów. Jeżeli limit pamięci PHP został tymczasowo usunięty, po zastosowaniu łatki przywróć odpowiedni, skończony budżet. 5. **Jeśli natychmiastowa aktualizacja jest niemożliwa**: ogranicz niezaufany ruch, zanim osiągnie PHP. Oceń postęp wyłączania przesyłania i fatalne ślady wsteczne PHP 8.5 zgodnie z opisem w sekcji 5. Ograniczenia konfiguracyjne i reguły WAF mają ograniczony zasięg i nie mogą zastąpić aktualizacji. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) ## 1. Przegląd podatności i ocena ryzyka PHP2Shell w tym artykule odnosi się do dwóch luk poziomu Critical oficjalnie ujawnionych przez PHP 21 października 2026 r. Obie są związane z zarządzaniem pamięcią i cyklem życia żądań silnika PHP, stwarzając ryzyko nieuwierzytelnionego zdalnego wykonania kodu. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) | Projekt | CVE-2026-109618 | CVE-2026-109619 | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | oficjalna nazwa | RCE via OOM corruption | RCE via stale global state | | podstawowe kwestie | Niewystarczająca ilość pamięci powoduje nieprawidłowy skok, pozostawiając stan, który nie zakończył jeszcze inicjalizacji. | Stan globalny pozostający w procesie roboczym wskazuje na zwolnioną pamięć żądań. | | Typowy czas wystąpienia | Proces inicjowania, wykonywania lub czyszczenia bieżącego żądania | Poprzednie żądanie opuszcza status, a kolejne żądania zużywają go z wyprzedzeniem. | | Czy OOM jest warunkiem koniecznym? | Należy do podstawowego mechanizmu wyzwalającego lukę | Nie; mogą również dotyczyć innych błędów krytycznych i czyszczenia po diagnozie | | Podstawowy kierunek naprawy | Bezpiecznie obsługuj błędy alokacji i żądaj zakończenia | Napraw własność stanu, czas czyszczenia i wczesną inicjalizację | | Wymagania dotyczące utylizacji | musi zostać naprawiony | należy naprawić w tym samym czasie | Podstawa: dwa oficjalne biuletyny dotyczące bezpieczeństwa i zgłoszenia poprawek. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-4) ### 1.1 Omówienie wdrożeń, których to dotyczy PHP oficjalnie uznaje wdrożenia **all PHP obsługujące żądania Web**, w tym PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP i LiteSpeed. Zademonstrowany atak mod\_php może nastąpić przed uruchomieniem kodu aplikacji, więc kontrole logowania, oprogramowanie pośredniczące platformy i sprawdzanie poprawności przesyłania aplikacji nie mogą objąć tej ścieżki. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1) Należy rozróżnić pomiędzy „należy naprawić wdrożenie” a „całkowicie udowodniono określony łańcuch ataków”. Ogłoszenie CVE-2026-109618: FPM opuści proces potomny po niepowodzeniu uruchomienia żądania, blokując odpowiednią ścieżkę czyszczenia mod\_php po niepowodzeniu uruchamiania; jednakże ścieżka OOM po pomyślnym uruchomieniu jest nadal zagrożona. W ogłoszeniu zauważono również, że nie zademonstrowano jeszcze pełnego exploita FPM dla tego CVE. Tego ograniczenia nie można wykorzystać do wywnioskowania, że ​​FPM jest bezpieczny, zwłaszcza CVE-2026-109619 nie można zignorować. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) Bezpośrednie granice uprawnień umożliwiające pomyślną eksploatację zależą od tożsamości procesu obsługującego PHP i zasobów, do których ma on dostęp. Ogólnie rzecz biorąc, należy zwrócić uwagę na kod strony internetowej, katalog przesyłania, dane uwierzytelniające bazę danych, tokeny usług i możliwości dostępu do sieci wewnętrznej; „zdalne wykonanie kodu” nie oznacza naturalnego uzyskania uprawnień roota. Ocena konsekwencji opiera się na modelu uprawnień do procesu, a rzeczywisty wpływ należy ocenić w połączeniu z uprawnieniami do wdrożenia. Zwykłe jednorazowe skrypty CLI nie mają tego samego wpisu HTTP; ale procesy, które przez długi czas obsługują zadania zewnętrzne w CLI lub w trybie osadzonym, powinny nadal być uwzględnione w inwentarzu czasu wykonywania i cyklu życia. Aktualizowane są tylko zależności CMS, framework lub Composer, a podstawowy silnik PHP nie jest automatycznie zastępowany. ## 2. Analiza przyczyn ### 2.1 Najpierw zapoznaj się z dwoma cyklami życia PHP worker często obsługuje wiele żądań kolejno. Pamięć przydzielona podczas żądania może zostać równomiernie zwolniona na końcu żądania, podczas gdy sam proces roboczy i niektóre jego pola globalne nadal istnieją. Dlatego silnik musi utrzymywać dwa ograniczenia: - **Ograniczenie inicjalizacji**: Dane widoczne dla innych kodów muszą być w stanie, który można bezpiecznie odczytać, przejść i zniszczyć. - **Ograniczenie cyklu życia**: po zwolnieniu pamięci żądań, pola o dłuższym czasie życia nie mogą w dalszym ciągu traktować adresów w tej pamięci jako prawidłowego stanu. Te dwa ograniczenia odpowiadają głównym trybom awarii obu grup luk. Poniższy proces stanowi opis mechanizmu, który łączy w sobie ogłoszenia i kompilację łatek. Nie oznacza to, że każde wdrożenie ma dokładnie tę samą osiągalną ścieżkę. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) ### 2.2 CVE-2026-109618: OOM przerwał niedokończoną aktualizację statusu Stara implementacja wykorzystuje nielokalny skok typu `longjmp()` do obsługi OOM, a powiązana ścieżka opuszcza bieżący kontekst wykonania poprzez `zend_bailout()`. Niebezpieczeństwo polega na tym, że fragment kodu C mógł opublikować nowy obiekt, tablicę lub status żądania do innego kodu, ale nie zakończył jeszcze całej inicjalizacji pól; w tym momencie jakikolwiek błąd alokacji w danym momencie może spowodować pominięcie normalnych etapów zamykania. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) Proces awarii można podzielić na cztery etapy: 1. Utwórz lub zaktualizuj wewnętrzną strukturę żądania i udostępnij ją. 2. Późniejsza alokacja pamięci kończy się niepowodzeniem i zostaje wyzwolony OOM. 3. Przebieg wykonywania przeskakuje od bieżącej funkcji, a kod pierwotnie użyty do zakończenia inicjalizacji lub przywrócenia stanu nie jest wykonywany. 4. Oczyszczanie żądania kontynuuje przetwarzanie tych struktur i traktuje nieprawidłowe treści jako prawidłowe pola lub adresy. Problem nie polega na tym, że brak pamięci zawsze powoduje RCE. Raczej wyczerpanie pamięci **zmienia przepływ sterowania i narusza założenia silnika dotyczące prawidłowych struktur**. Nieudana alokacja nie musi bezpośrednio dotyczyć struktury, która ostatecznie zostanie błędnie odczytana. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) #### Dlaczego w przypadku mniejszych żądań może zabraknąć pamięci Liczba bajtów w treści żądania i wykorzystanie sterty po przeanalizowaniu to nie to samo. Pole A może odpowiadać wielu ciągom znaków, elementom tablicy i obiektom metadanych wewnątrz PHP; złożoność strukturalna wejścia będzie miała wpływ na stopień wzmocnienia pamięci. Problemy z elementami wieloczęściowymi wymienione w oficjalnym ogłoszeniu obejmują: lukę w sprawdzaniu rozmiaru początkowego, gdy brakuje dostępnej długości deklaracji, liczba nagłówków dla pojedynczej części nie jest wystarczająco ograniczona, a kontrolki pustych plików nadal generują metadane, a zagnieżdżone nazwy dodatkowo zwiększają obciążenie tablicy. Własne odwinięcie, dekodowanie lub ponowne przypisanie danych wejściowych przez aplikację może również być źródłem OOM. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) Można z tego wyciągnąć dwa ochronne wnioski: - Przed wprowadzeniem PHP należy w jak największym stopniu wdrożyć ograniczenia treści żądania i należy wziąć pod uwagę rzeczywistą długość odczytu i złożoność strukturalną. - Indywidualne ograniczenie rozmiaru pliku, liczby plików lub zamknięcie tylko jednego portalu przesyłania nie może objąć wszystkich źródeł OOM. #### Dlaczego uwierzytelnianie aplikacji może być za późno W mod\_php treść żądania może być automatycznie analizowana podczas fazy inicjalizacji żądania; nawet jeśli uruchomienie się nie powiedzie, powiązane czyszczenie żądań będzie nadal wykonywane. Dlatego potwierdzone ścieżki ataku mogą wystąpić przed kodem aplikacji. Aby ograniczyć ryzyko na tym etapie, należy nałożyć ograniczenia na odwrotne proxy, serwer Web lub inną granicę poprzedzającą przetwarzanie żądania PHP. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) ### 2.3 CVE-2026-109619: Pamięć żądań została zwolniona, globalne odniesienie jest nadal aktywne Ten problem dotyczy błędu, sesji, obiektu lub stanu rozszerzenia: pole jest przechowywane w lokalizacji roboczej o długotrwałym dostępie, ale dane, do których odwołuje się pole, należą do pojedynczego żądania. Dopóki odwołanie nie zostanie odpowiednio wyczyszczone przed zwolnieniem sterty żądań, kolejne żądania mogą napotkać stan zawieszony, tworząc stan bezużyteczny. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) Oficjalna analiza dzieli warunki eksploatacji na „producentów” i „konsumentów”: | rola lub stan | znaczenie | Konsekwencje dla ochrony | | -------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | producent państwowy | Umieść stan będący własnością tego żądania w lokalizacji, do której będzie można uzyskać dostęp później | Aby sprawdzić, czy po nieprawidłowym wyjściu odpowiednie czyszczenie zostało zakończone | | Stan pozostaje | Nie został oczyszczony lub został oczyszczony, a następnie ponownie napełniony w wyniku późnej operacji. | Samo jednorazowe wyczyszczenie na wcześniejszym etapie wyłączania może nie wystarczyć | | ponowne wykorzystanie przez pracownika | Ten sam pracownik kontynuuje przetwarzanie kolejnych żądań | Wielu pracowników to tylko różnica w harmonogramie, a nie gwarancja bezpieczeństwa pamięci | | konsument z wyprzedzeniem | Odczytaj, zwolnij lub określ wartość resztkową przed normalną inicjalizacją odpowiedniego stanu. | Przed inicjalizacją należy sprawdzić INI, sesję i inne ścieżki | Warunki te muszą być spełnione łącznie; żaden dziennik błędów sam w sobie nie dowodzi, że luka została pomyślnie wykorzystana. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) #### Nie wymaga OOM jako warunku wstępnego Błędy krytyczne mogą przerwać publikację i przywracanie sparowanego stanu. Błędy kompilacji lub analizowania, nieprzechwycone błędy, błędy `require` i przekroczenia limitu czasu wykonania mogą spowodować pozostawienie określonych stanów. Diagnostyka niekrytyczna na późniejszym etapie czyszczenia może również ponownie wypełnić informacje o błędach, które zostały już usunięte. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) Dlatego zmiana `memory_limit` na nielimitowany nie obejmuje tego zestawu luk. #### „Przed inicjalizacją” należy traktować osobno Moment pojawienia się dwóch typów potwierdzonych konsumentów jest inny: - **Early INI diagnostyka**: Niektóre konfiguracje zastosowane na żądanie powodują wyświetlenie ostrzeżenia, powiadomienia lub wycofania przed normalną inicjalizacją modułu wykonującego, a przetwarzanie diagnostyczne może uzyskać dostęp do starego stanu błędu. - **postęp przesyłania sesji**: sesja może zostać przetworzona wcześniej podczas procesu analizowania treści żądania, ale zwykły moduł `RINIT` nie został jeszcze ukończony; nie można wywnioskować, że ścieżka nie istnieje, ponieważ aplikacja nie wywołuje jawnie `session_start()`. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) Nie wszystkie konfiguracje INI mają ten sam czas ryzyka. Konfigurację na poziomie katalogu mod\_php i `PHP_VALUE` / `PHP_ADMIN_VALUE` przekazywaną przez front-end FPM należy odróżnić od zwykłej konfiguracji startowej `php.ini`, FPM pool i FPM `.user.ini`. Te ostatnie mają inny czas konfiguracji i nie można ich zbiorczo nazwać tymi samymi wczesnymi konsumentami. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) Wyłączenie `display_errors`, `log_errors`, zmniejszenie `error_reporting`, lub użycie `@` wpływa jedynie na widoczność diagnozy; dostęp do odpowiedniego stanu wewnętrznego mógł zostać uzyskany przed podjęciem decyzji o wyprowadzeniu dziennika. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) ## 3. Napraw wersję i wybór poprawki ### 3.1 Oficjalna baza poprawek nadrzędnych | Bieżący oddział PHP | Pierwsza wersja zawierająca tę oficjalną poprawkę | Sugestie | | ------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | 8.2 | 8.2.35 | Uaktualnij do tej wersji lub kolejnej wersji zawierającej te same poprawki | | 8.3 | 8.3.36 | To samo co powyżej | | 8.4 | 8.4.27 | To samo co powyżej | | 8.5 | 8.5.12 | To samo co powyżej | | 8.1 i wcześniejsze wersje | Ogólne wsparcie Upstream zostało zakończone | Nadaj priorytet migracji do obsługiwanych oddziałów; krótkoterminowa wersja kontrolna lub backport producenta LTS | Wersja i status wsparcia oparte są na oficjalnym ogłoszeniu PHP, a datą bazową jest 22 października 2026 r. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1) Są to **progi poprawek dla poszczególnych gałęzi**. Nie można ich zastąpić stwierdzeniem, że każda wersja poniżej 8.5.12 jest podatna na ataki: wersje takie jak 8.2.35 i 8.4.27 w innych gałęziach zawierają już poprawki. ### 3.2 Sprawdź pełną wersję pakietu dystrybucyjnego Dystrybucje często dodają poprawki bezpieczeństwa w oparciu o starsze wersje. Akceptacja powinna również sprawdzić wersję wydania, źródło repozytorium, pełną wersję pakietu i biuletyn bezpieczeństwa. Na przykład wersja pakietu poprawek Ubuntu 24.04 LTS wymieniona dla Ubuntu USN-8948-1 to: ```text 8.3.6-0ubuntu0.24.04.13 ``` Jego poprzednią częścią jest nadal `8.3.6`, ale pełna wersja pakietu tej dystrybucji jest uwzględniona w tym ogłoszeniu poprawki. Ten wniosek dotyczy tylko odpowiedniej dystrybucji i źródła pakietu i nie można go uogólnić na żadną kompilację, która również wyświetla `8.3.6`. [S10](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-10) ### 3.3 Wybór odpowiedniego patcha | scena | Plan priorytetowy | Kluczowe punkty akceptacji | | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Korzystanie z pakietu dystrybucyjnego PHP | Zainstaluj aktualizacje zabezpieczeń wydane przez producenta | Ogłoszenie dotyczy zarówno modeli CVE; pełna wersja pakietu jest poprawna | | Użyj oficjalnego kontenera PHP lub samodzielnie utworzonego obrazu | Zaktualizuj podstawowe środowisko wykonawcze, przebuduj i wdróż | Działająca instancja używa nowego obrazu; wszystkie stare kopie zostały usunięte | | Samokompilowane obsługiwane gałęzie | Użyj oficjalnej wersji zabezpieczeń tej gałęzi lub pełnego oficjalnego zestawu poprawek | Dopasowywanie gałęzi, uzupełnianie zależności, zgodność rozszerzeń i przekazywanie regresji | | Z zastrzeżeniem 7.4, 8.0, 8.1 | Nadaj priorytet backportowi dostawcy; jeśli to konieczne, oceń oficjalny oddział awaryjnego kodu źródłowego | Zidentyfikuj zmiany w zachowaniu i zaplanuj migrację do obsługiwanych wersji | Oficjalne łatki zostały wydane i właściwe poprawki powinny zaczynać się od tych łatek. Fragmenty kodu w sekcji 6 mają na celu zilustrowanie najważniejszych elementów projektu i przeglądu i nie stanowią kompletnej poprawki, którą można zastosować niezależnie. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-6) ## 4. Formalny proces naprawy ### 4.1 Spis środowiska wykonawczego, które faktycznie obsługuje żądania Zaleca się utworzenie krótkiej księgi, w której będą zapisywane co najmniej: - Wprowadź nazwę domeny lub usługę, backend zwrotnego proxy, PHP SAPI. - Gałąź PHP, pełna wersja pakietu lub skrót obrazu, źródło kompilacji. - FPM pool, rzeczywista jednostka serwisowa, kontener lub Pod, liczba replik. - Załadowano rozszerzenia, główną konfigurację i dodatkowe pliki konfiguracyjne. - Czy istnieją inne wersje PHP, stare kopie wdrożeniowe lub portale Origin, do których można uzyskać bezpośredni dostęp? Są to sugestie dotyczące implementacji, tak aby „ulepszony” mógł odpowiadać każdemu rzeczywistemu wpisowi ruchu. Szczególnie sprawdź, czy linie poleceń PHP i Web PHP używają różnych wersji, obraz jest zbudowany, ale stary kontener nadal działa, część puli lub kopia nie została zastąpiona itp. ### 4.2 Wybierz i zainstaluj poprawną aktualizację Potwierdź wersję poprawki zgodnie z sekcją 3, najlepiej korzystając z istniejącego zaufanego źródła pakietów lub kontrolowanego łańcucha kompilacji. Zakres aktualizacji powinien obejmować komponent, który faktycznie obsługuje żądanie, taki jak pakiet FPM, moduł Apache PHP, plik binarny CGI lub kompilacja usługi, w której osadzony jest PHP. Przed aktualizacją zachowaj konfigurację i listę pakietów oraz zweryfikuj uruchomienie i kluczowe usługi w środowisku podobnym do produkcyjnego. W przypadku rozszerzeń samoobsługowych sprawdź zgodność kompilacji i uruchomienia odpowiadającą wersji PHP. Samo wybranie pozornie istotnego zatwierdzenia z innej gałęzi nie gwarantuje, że cały zestaw poprawek został zaimplementowany. ### 4.3 Uruchom ponownie lub przewróć działające instancje Instalowanie pliku i ładowanie nowego kodu do procesu to dwie różne rzeczy. Należy ponownie uruchomić odpowiednią usługę lub zakończyć wymianę ciągłą i potwierdzić, że stary pracownik i stary kontener opuścili kontener. W przypadku mod\_php zrestartuj proces Apache hostujący moduł. Usługi z wbudowanym PHP wymagają wymiany procesu hostingu. W przypadku FPM wyczyszczenie OPcache nie zastępuje aktualizacji środowiska wykonawczego i wycofywania starych pracowników. Korzystając z płynnego przełączania, należy sprawdzić, czy proces starej generacji nadal obsługuje długie połączenia lub zaległe żądania. Rekord akceptacji powinien zawierać rzeczywistą usługę, wersję wdrożenia, czas zakończenia zmiany i wyniki wyjścia starej instancji. ### 4.4 Weryfikacja poprzez prawdziwe żądania Web Zaleca się połączenie następujących dowodów zamiast polegania wyłącznie na poleceniu jednej wersji: | dowody | Co można udowodnić | Sam nie jestem w stanie niczego udowodnić | | ---------------------------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------- | | Menedżer pakietów lub metadane obrazu | Źródła instalacji i pełne kompilacje | Ruch został przełączony na tę instancję | | Stan procesu i wdrożenia | pracownik lub kontener kończy wymianę | Należy do niego poprowadzić wejście zewnętrzne | | Ograniczony dostęp do wyników diagnostycznych za pośrednictwem prawdziwego portalu | Rzeczywista konfiguracja Web SAPI i działająca | Czy backport wydania obejmuje dwa CVE | | Ogłoszenie dostawcy lub pełny zapis poprawek | Ta poprawka błędu jest uwzględniona w tej kompilacji | Wszystkie repliki są wdrożone | `PHP_VERSION`, `PHP_SAPI`, załadowane pliki konfiguracyjne i konfiguracje awaryjne można sprawdzić za pomocą istniejących wewnętrznych funkcji diagnostycznych lub tymczasowych portali diagnostycznych z kontrolą dostępu. Upewnij się, że żądanie nie jest zwracane bezpośrednio przez CDN lub pamięć podręczną strony; po zakończeniu usuń tymczasowy wpis diagnostyczny. `php -v` zwykle wskazuje tylko plik binarny CLI aktualnie wybrany przez powłokę; polecenia takie jak `php-fpm -i` nie są równoważne weryfikacji istniejącego procesu roboczego, który odbiera ruch. Nie udostępniaj przez dłuższy czas całej strony `phpinfo()` w sieci publicznej. ### 4.5 Sprawdzanie regresji biznesowej i usuwanie ustawień awaryjnych Sprawdź normalne logowanie, odczytywanie i zapisywanie sesji, formularze i przesyłanie, importowanie, obsługę błędów i stabilność procesów roboczych w obrębie funkcji, których dotyczy ta zmiana. Sprawdź, czy poziom błędów, opóźnienie odpowiedzi, szczyt pamięci, częstotliwość kończenia procesu i odbudowy są nieprawidłowe. Jeżeli `memory_limit=-1` jest ustawione tymczasowo, ograniczony budżet odpowiadający możliwościom biznesowym zostanie przywrócony po wejściu w życie oficjalnej poprawki; jeśli ustawiono `pm.max_requests=1`, konfiguracja cyklu życia z oceną wydajności zostanie przywrócona po potwierdzeniu naprawy. Limity rozmiaru danych wejściowych i mechanizmy kontroli dostępu do źródła mogą zostać zachowane w zależności od potrzeb biznesowych. Jeśli podczas aktualizacji pojawią się problemy ze zgodnością, priorytetem powinno być zawieszenie portalu, którego dotyczy problem, ograniczenie jego dostępu zewnętrznego lub dostosowanie aplikacji przed wycofaniem. Bezpośrednie zezwolenie nienaprawionemu środowisku wykonawczemu na ponowne działanie w sieci publicznej spowoduje ponowne otwarcie pierwotnego ryzyka. ## 5. Środki łagodzące, gdy natychmiastowa aktualizacja nie jest możliwa Ta sekcja ma na celu krótkoterminowe zmniejszenie narażenia lub poprawę dostępności. Każdy środek obejmuje tylko określoną ścieżkę, a połączenie wielu środków nie jest równoznaczne z całkowitą naprawą. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) ### 5.1 Nadaj priorytet kontroli ruchu przed PHP Jeśli usługa na to pozwala, tymczasowo ogranicz wrażliwe punkty końcowe do zaufanych źródeł lub wymuś kontrolę dostępu przed PHP. W przypadku obciążeń związanych z przesyłaniem ogranicz rozmiar treści żądania, liczbę pól, liczbę części, nagłówki na część i głębokość zagnieżdżenia. Usługi, które nie wymagają wieloczęściowości, mogą ją odrzucić na froncie. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) Ograniczenia te mają obejmować wszystkie wejścia do PHP. Dopiero przechwycenie URL o nazwie „upload” spowoduje pominięcie innych wpisów, które w dalszym ciągu są automatycznie analizowane przez PHP w treści żądania. W przypadkach takich jak transfery fragmentaryczne, brak dostępnej deklarowanej długości itp. limit powinien opierać się na rzeczywistym rozmiarze odczytu; aplikacja powinna również mieć własny budżet wielkości wyjściowej podczas ponownej dekompresji lub rozszerzania zawartości. ### Szablon konfiguracji 5.2 FPM pool Umieść następujące ustawienia w sekcji konfiguracji **FPM pool, która faktycznie obsługuje żądania**, a nie dosłownie w `php.ini`. Wartości 8M i 4M to przykłady, które należy dostosować do obciążenia pracą. Ograniczając całe żądanie POST, zostaw miejsce na pola formularzy i granice wieloczęściowe. [S11](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-12) ```ini ; Temporary mitigation: evaluate capacity before applying. php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 4M php_admin_flag[session.upload_progress.enabled] = off ``` Tylko **PHP 8.5** oraz dodatkowo: ```ini php_admin_flag[fatal_error_backtraces] = off ``` Funkcje i granice każdego z nich są następujące: | Konfiguracja | oczekiwany efekt | Opis ograniczeń, których należy przestrzegać | | ------------------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | `memory_limit=-1` | Usuń przewidywalny warunek wyzwalania górnego limitu pamięci żądania PHP | Nie zapobiega to błędom alokacji; anulowanie pierwotnego budżetu może zwiększyć ryzyko wyczerpania pamięci i przerw w świadczeniu usług. | | Mniejszy `post_max_size` | Zmniejsz rozmiar danych wprowadzanych do procesu analizy | Nienaprawiony parser ma znaną lukę; wzmocnieniu pamięci nie można zapobiec niezależnie | | `upload_max_filesize < post_max_size` | Ogranicz rozmiar pojedynczego pliku i zarezerwuj miejsce na żądanie | Nie ogranicza wszystkich pól, metadanych ani alokacji w aplikacji | | Zamknij postęp przesyłania | Zablokuj potwierdzoną ścieżkę związaną z sesją | Nie obejmuje innych wariantów stanu globalnego | | PHP 8.5 zamyka fatalny ślad wsteczny | Zablokuj potwierdzony status powiązanych producentów | Nie obejmuje innych ścieżek, takich jak session | Granice środka pochodzą z oficjalnego ogłoszenia; składnię puli i semantykę konfiguracji na poziomie zarządzania można znaleźć w instrukcji PHP. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-11) Ustawienia poziomu zarządzania `php_admin_*` nie mogą zostać zastąpione przez aplikacje poprzez `ini_set()`. Należy jeszcze sprawdzić wszystkie konfiguracje przychodzące na poziomie puli, katalogu i frontonu, aby potwierdzić, że wartości w rzeczywistych żądaniach są zgodne z oczekiwaniami. Po modyfikacji odbuduj cały proces roboczy, aby zapobiec dalszemu utrzymywaniu starego stanu istniejących procesów. Jeżeli zdecydujesz się na bezpośrednią modyfikację `php.ini`, składnię należy zmienić na: ```ini memory_limit = -1 post_max_size = 8M upload_max_filesize = 4M session.upload_progress.enabled = Off ``` W przeciwieństwie do `php_admin_value` w puli, samo ustawienie `memory_limit=-1` w `php.ini` nie uniemożliwia aplikacji ponownej jego modyfikacji. Należy sprawdzić strukturę, kod aplikacji i inne konfiguracje, aby sprawdzić, czy zresetowały ograniczoną wartość; gdy wymagane jest wymuszenie, użyj ustawień na poziomie zarządzania odpowiednich dla bieżącego SAPI i sprawdź rzeczywistą wartość efektywną. [S11](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-12) Dodaj `fatal_error_backtraces = Off` tylko dla PHP 8.5. Nie używaj `ini_set()` na poziomie aplikacji jako obejścia wyłączającego postęp przesyłania i nie polegaj na FPM `.user.ini`, aby był on skuteczny przed analizą żądań. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3) ### 5.3 Zarządzaj kosztami usuwania limitów pamięci PHP `memory_limit=-1` to tymczasowe ograniczenie ścieżki dla nienaprawionych środowisk i nie należy go kopiować jako długoterminowej konfiguracji domyślnej. Gdy aplikacja lub żądanie wymknie się spod kontroli, może zająć więcej pamięci hosta. Dlatego przed użyciem należy ocenić liczbę współbieżności, szczytową liczbę pojedynczych procesów roboczych i całkowitą pojemność usługi oraz wdrożyć limity wejściowe frontonu. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) Limity pamięci kontenera lub grupy cgroup mogą zapewniać granice dostępności, ale nie gwarantują, że alokacje nigdy nie zawiodą; cały kontener, główny i cały proces roboczy mogą również zostać zakończone po uruchomieniu limitu. Szczegółowość izolacji i strategie terminacji należy oceniać w połączeniu z wdrażaniem i nie można ich nazwać pełną ochroną w przypadku tych dwóch CVE. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) Nie zastępuj powyższych strategii `RLIMIT_AS`, `RLIMIT_DATA` lub odpowiadającymi im ograniczeniami przestrzeni adresowej procesu; mogą bezpośrednio spowodować awarię podstawowej alokacji na wciąż problematycznej ścieżce OOM. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2) ### 5.4 Nginx Przykład konfiguracji Ma zastosowanie do wdrożenia, w którym Nginx przekazuje żądania do PHP-FPM. Można to ustawić na poziomie konfiguracji właściwej usługi hostingowej: ```nginx client_max_body_size 8m; fastcgi_request_buffering on; ``` `client_max_body_size` ogranicza rozmiar treści żądania; `fastcgi_request_buffering on` pozwala Nginx najpierw przeczytać całą treść żądania, a następnie wysłać ją do zaplecza FastCGI. To, czy wchodzi to w życie w konkretnym `server` lub `location`, należy sprawdzić w powiązaniu z istniejącymi relacjami dziedziczenia i pokrycia. [S13](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-14) **Tylko gdy firma nie potrzebuje wielu części**, możesz dodać regułę odrzucenia do odpowiedniego wejścia usługi: ```nginx if ($http_content_type ~* "multipart/form-data") { return 403; } ``` Jest to prosty szablon ograniczeń wpisu wykorzystujący `if` i `return`, a nie ogólna reguła filtrowania luk w zabezpieczeniach analizatora składni. Przed wdrożeniem sprawdź składnię konfiguracji i normalne żądania oraz sprawdź, czy niestandardowy `error_page` przekierowuje 403 żądania do PHP. Dopasowanie ciągów nie zapewnia pełnych gwarancji dotyczących wszystkich różnic w analizie. [S15](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-15) Ponadto konfiguracje te nie ograniczają automatycznie ilości danych, liczby pól ani liczby obiektów PHP, które aplikacja może zdekompresować; firmy, które muszą przesłać pliki, powinny zastosować dodatkowe ograniczenia, które rozumieją strukturę ich żądań. ### 5.5 Opcjonalne ograniczenie: jedno żądanie na pracownika FPM W przypadku wdrożeń FPM, które pozwalają na zwiększenie kosztów ogólnych, można ocenić konfiguracje krótkoterminowe: ```ini pm.max_requests = 1 ``` I odbuduj istniejącego pracownika. Blokuje opisany łańcuch żądań krzyżowych na poziomie ponownego użycia pracownika, ale zwiększa obciążenie związane z tworzeniem i inicjalizacją procesów; jednocześnie nie może naprawić tego samego żądania OOM i problemów związanych z czyszczeniem CVE-2026-109618. Gdy wartość jest mniejsza, ale większa niż 1, nadal istnieje okno żądania ponownego użycia. [S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-11) ### Limity pokrycia 5.6 WAF i Cloudflare Cloudflare ogłosił ustalenia dotyczące wdrożenia ochrony przed PHP2Shell, w tym plan Free. Korzystając z jej usług należy sprawdzić, czy rzeczywisty ruch przechodzi przez serwer proxy, czy obowiązują zasady ochrony i czy można bezpośrednio ominąć stronę źródłową; w przypadku planów płatnych należy również sprawdzić konfigurację i wyjątki odpowiednich reguł zarządzanych. [S16](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-16) Niektóre z detekcji opisanych przez dostawcę wykorzystują sygnały odpowiedzi, więc wszystkich zabezpieczeń nie można interpretować jako „każdy atak jest blokowany przed osiągnięciem PHP”. WAF może pomóc w zmniejszeniu narażenia i dostarczyć informacji obserwacyjnych, ale nadal konieczne są dalsze aktualizacje PHP. [S16](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-16) ### 5.7 Dlaczego powszechnie stosowane środki są niewystarczające | środków lub orzeczeń | niedociągnięcia | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Zamknij tylko `file_uploads` | Nie można uwzględnić całego przetwarzania wieloczęściowego i zastosować własną ścieżkę OOM | | Ustawienie `enable_post_data_reading=Off` | Zmień zachowanie automatycznego wypełniania POST/FILES; treść żądania może być nadal odczytywana przez aplikację i może zakłócać normalne działanie | | Wyłącz wyświetlanie błędów, zaloguj się lub użyj `@` | Wewnętrzne przetwarzanie diagnostyczne może nadal uzyskać dostęp do stanu zawieszenia | | Zwiększ liczbę pracowników | Nie ustanawiaj mechanizmu czyszczenia stanu bezpiecznego ani nie eliminuj ponownego wykorzystania pojedynczego pracownika | | Skonfiguruj tylko `disable_functions` lub `open_basedir` | Ograniczenia te nie naprawiają uszkodzenia pamięci warstwy silnika C | | Sprawdź wersję lub pojedynczą kopię tylko raz | Nie da się udowodnić, że wszystkie wejścia i działające instancje zostały wymienione | | Nie widać żadnych dzienników wyjątków | Nie może udowodnić, że luka w zabezpieczeniach nie istnieje lub że nie była wcześniej wykorzystywana. | Wśród nich podstawę konfiguracji i mechanizmu podatności PHP można znaleźć w [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-12); oceny dotyczące granic zasięgu, akceptacji i pozwoleń opierają się na sugestiach wdrożeniowych przedstawionych przez te mechanizmy. ## 6. Pomysły na wdrożenie i punkty kontrolne oficjalnej łatki ### 6.1 Użyj kompletnych poprawek dla właściwej gałęzi Reprezentatywne oficjalne zgłoszenie dla PHP 8.5 to: ```text 31c0ea7d7ff1d1fccb6492e52dab544011628065 Avoid state corruption via bailout ``` Zatwierdzenie jawnie wiąże dwa CVE, zarówno w celu dostosowania mechanizmu wyjścia OOM, jak i ustalenia stanu globalnego, do którego można uzyskać dostęp w fazie inicjalizacji. Prześlij stronę z pełną różnicą, patrz [S4](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5). Inne gałęzie powinny używać własnych oficjalnych wersji zabezpieczeń lub pasujących poprawek i nie można zakładać, że zmiany w 8.5 można bezpośrednio zastosować w jakiejkolwiek starszej wersji. ### 6.2 OOM Naprawa: najpierw przywróć stan przetwarzalny, a następnie zakończ żądanie Formalna implementacja wprowadza dwa poziomy miękkiego i twardego przetwarzania OOM: po osiągnięciu miękkiego limitu rejestrowany jest status oczekujący i wykonywane jest kontrolowane wyjście w bezpiecznym miejscu, takim jak VM; interfejs alokacji, w której występuje awaria, pozwala wywołującemu jawnie obsłużyć awarię. W przypadku alokacji, które nie mogą bezpośrednio zwrócić błędu, jeśli spodziewane jest przekroczenie wyższego twardego progu, proces zostanie bezpośrednio zakończony, aby uniknąć dalszego przetwarzania żądań w niebezpiecznym stanie pośrednim. [S2](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) Poniżej znajduje się fragment kodu klucza w pliku różnicowym 8.5 używany do oznaczenia oczekującego OOM: ```c EG(delayed_oom).state = ZEND_OOM_STATE_PENDING; zend_atomic_bool_store_ex(&EG(vm_interrupt), true); ``` Obsługa przerwań VM i inne bezpieczne lokalizacje następnie wywołują `zend_handle_delayed_oom()`. Kontekst wykonania kodu użytkownika wykorzystuje kontrolowaną ścieżkę rozwijania; twarda ścieżka OOM wywołuje `_exit(137)`. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) Z punktu widzenia projektu istotne zmiany to: **apobiega arbitralnemu przechodzeniu przez stos wywołań C, gdy struktura jest w stanie pośrednim, i umieszcza wyjście w lokalizacji**, która może utrzymać ograniczenia stanu. Po uruchomieniu miękkiego limitu do zakończenia procesu może być wymagana dodatkowa pamięć, więc nowego miękkiego progu nie można rozumieć jako bezwzględnego górnego limitu całkowitej pamięci procesu. Nie można tego podsumować w następujący sposób: „PHP usunął wszystkie `zend_bailout()`”. Łatka nadal wykorzystuje odpowiednie mechanizmy w określonych kontekstach; ustalony jest niebezpieczny moment wyjścia i towarzyszące mu zarządzanie stanem. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) ### 6.3 Aktualizuj jednocześnie elementy wywołujące alokację i analizę wieloczęściową Jeśli zmienisz tylko funkcję alokacji na „zwraca NULL w przypadku niepowodzenia”, a pierwotny obiekt wywołujący nadal zakłada, że zawsze zwracany jest prawidłowy wskaźnik, wprowadzisz nowy dostęp do wskaźnika zerowego lub niekompletne czyszczenie. Należy sprawdzić interfejs alokacji powodujący awarię w łatce, a także sprawdzić moduł wywołujący i propagację wyjątków. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) poprawki związane z wieloczęściowością obejmują także przeprowadzanie zbiorczych kontroli w oparciu o rzeczywistą wielkość odczytu, ograniczenie przetwarzania bezużytecznych lub zduplikowanych nagłówków oraz przyjęcie spójnej logiki wyjścia i czyszczenia, gdy OOM jest w toku. Zmiany te zarówno zmniejszają wzmocnienie zasobów, jak i sprawiają, że parser jest zgodny z nowym protokołem OOM. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) W przypadku zespołów, które utrzymują własne oddziały, zaleca się, aby przegląd kodu skupiał się na następujących kwestiach: - Czy stan jest widoczny dla świata zewnętrznego, zanim zostanie w pełni zainicjowany? - Czy po niepowodzeniu alokacji lub wyjątku wywołania zwrotnego własność jest nadal unikalna i jednoznaczna? - Czy uda ci się dotrzeć do ujednoliconego wyjścia sprzątania, jeśli nie uda Ci się w połowie? - Czy funkcja czyszczenia może rozpoznać niezainicjowane lub zwolnione pola? - Czy budżet analizy opiera się na rzeczywistej wielkości przetwarzania, a nie tylko na żądaniach zaufania? - Czy nowa wartość zwracana przez niepowodzenie została obsłużona przez wszystkich wywołujących? Są to pytania przeglądowe podsumowane w oparciu o mechanizm poprawek i nie stanowią wniosków z audytu, który został ukończony dla niedostarczonej bazy kodu. ### 6.4 Poprawka dotycząca żądań krzyżowych: wcześniejsza inicjalizacja, końcowe czyszczenie później Odpowiednio do CVE-2026-109619, łatka reguluje wiele granic cyklu życia jednocześnie. Pliki i operacje wymienione poniżej biorą za przykład oficjalną różnicę PHP 8.5. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) | lokalizacja | zmienić kierunek | Problem rozwiązany | | ------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `Zend/zend_execute_API.c` itp. | Zresetuj status modułu wykonującego, taki jak błędy, wyjątki, procedury obsługi, obiekty itp. | Po zakończeniu żądania nadal istnieją stare odniesienia, do których można uzyskać dostęp w ramach następnego żądania. | | Ścieżka startowa `main/main.c` | Zadzwoń do `php_basic_early_rinit()` zanim SAPI zostanie aktywowany | Kiedy pojawia się wczesny konsument, odpowiedni stan podstawowy nie został jeszcze zainicjowany. | | Zamknij ścieżkę `main/main.c` | Zniszcz HTTP globals i oznacz go jako niezdefiniowany | Zwolniona wartość jest nadal uważana za prawidłowy obiekt | | zanim sterta żądań zostanie ostatecznie zwolniona | Ponownie usuń ostatni komunikat o błędzie | Diagnostyka późnego czyszczenia ponownie wyświetla stan błędu | | `ext/session/session.c` | postęp przesyłania Wczesna ścieżka jest inicjowana globalami pierwszej sesji | Zwykły moduł RINIT uzyskał wcześniej dostęp do starego stanu | | Kod związany z serializacją | Ogranicz analizowanie klas i wywołania zwrotne użytkowników na wczesnym etapie przetwarzania | Wykonaj dodatkowy kod użytkownika, jeśli inicjalizacja nie została zakończona | Na przykład sekwencja startowa obejmuje: ```c zend_activate(); php_basic_early_rinit(); sapi_activate(); ``` Po zniszczeniu HTTP globals dodaj znak awarii statusu: ```c zval_ptr_dtor(&PG(http_globals)[i]); ZVAL_UNDEF(&PG(http_globals)[i]); ``` Te fragmenty ilustrują dwie zasady: **inicjuj przed najwcześniejszym możliwym konsumentem i wykonaj końcowe czyszczenie po ostatniej operacji, która może odtworzyć stan.** Resetowanie wskaźnika tylko podczas normalnego RINIT lub wcześniejszego etapu zamykania może spowodować utratę wcześniejszych lub późniejszych dostępów. [S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) ### 6.5 Dlaczego nie zaleca się wykonywania własnej „naprawy w jednej linii”? Zastąpienie wszystkich `zend_bailout()` przez `_exit()` lub po prostu dodanie sprawdzania wskaźnika zerowego przy określonym wpisie obejmowałoby dużą liczbę różnych kontekstów wykonania. Mogą pominąć inne pola statusu lub zmienić zniszczenie, rozszerzone wywołania zwrotne, hosting procesów i semantykę końcową żądań. W przypadku obsługiwanych wersji pierwszeństwo mają pełne poprawki, które zostały już wydane. Migracja własnych oddziałów powinna rejestrować źródło poprawek, obowiązujące wartości bazowe, obsługę konfliktów i zmiany zachowania, a także wykorzystywać odpowiednie przypadki użycia regresji na wczesnym etapie i weryfikację tego procesu biznesowego. Sugestie tutaj pochodzą z analizy zakresu poprawki w obrębie alokatora, VM, sesji i zmian w cyklu życia żądań. [S4](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-5) ## 7. Backport awaryjny PHP 7.4, 8.0, 8.1 PHP oficjalnie zapewnia minimalny backport kodu źródłowego trzech starych gałęzi w zależności od ważności. Nazwy oddziałów to: ```text PHP-7.4-CVE-2026-109618-109619 PHP-8.0-CVE-2026-109618-109619 PHP-8.1-CVE-2026-109618-109619 ``` Linki do oddziałów można znaleźć w artykule [S7](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-9). Są to dostawy awaryjne dotyczące tej luki i nie stanowią powrotu do regularnego wsparcia wyższego szczebla dla starej gałęzi ani nie zastępują innych aktualizacji zabezpieczeń. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1) ### 7.1 Weźmy jako przykład backport PHP 8.1 Odpowiednie zgłoszenia dla PHP 8.1 to: ```text 1d7dec178a094e6e75b229ce22754045f8c6070a ``` Jego strategia faworyzuje niezawodność: wywołanie `_exit(1)` po wyprowadzeniu diagnostyki w odpowiedniej ścieżce OOM i uwzględnieniu statusu globalnego i innych odpowiednich poprawek; jednocześnie wewnętrznie wyłączając odpowiednie przetwarzanie postępu przesyłania sesji. Aby przesłać odpowiedni kod źródłowy, zobacz [S6](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-6). Jest to różnica w zachowaniu w porównaniu z pełniejszym, opóźnionym projektem OOM w obsługiwanej gałęzi. To, że konfiguracja nadal pokazuje, że postęp przesyłania jest włączony, nie oznacza, że ​​zachowanie przetwarzania wewnętrznego po przeniesieniu danych pozostanie niezmienione. ### 7.2 Cena, którą musisz zaakceptować podczas wdrażania Bezpośrednie wyjście z procesu może spowodować niepowodzenie bieżącego żądania, pominięcie normalnych wywołań zwrotnych zamykania PHP i części zamknięcia aplikacji; jeśli host przyjmuje model wątków, należy również ocenić wpływ zakończenia całego procesu hosta na inną współbieżną pracę. Weryfikacja powinna również obejmować to, czy kierownik procesu może przeprowadzić proces wymiany na czas. Dlatego użytkownicy starszych wersji powinni rozważyć w kolejności: 1. Przeprowadź migrację do obsługiwanej gałęzi PHP i jej poprawionej wersji. 2. Użyj wersji, która wyraźnie obejmuje zarówno aktualizację producenta CVE, jak i LTS. 3. Jeśli rzeczywiście podlega starej wersji kodu źródłowego, skorzystaj z oficjalnego awaryjnego portu zapasowego pasującej wersji, aby sprawdzić kompletność zmian i kompatybilność oraz zorganizować późniejszą migrację. „Minimalny backport” opisuje tutaj wybrany przez urzędnika zakres zgodności i wdrożenia i nie powinien być automatycznie interpretowany jako „znane niekompletne poprawki luk w zabezpieczeniach”. Powinieneś oceniać na podstawie kodu źródłowego odpowiedniej branży i zapowiedzi producenta, a nie usuwać samodzielnie zmian wspierających. [S1](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/pl/insights/php2shell-remediation-guide#source-6) ## 8. Kryteria odbioru i kontrole następcze Zaleca się, aby jako podstawę do zakończenia naprawy wykorzystać następujące wyniki: | Przedmioty akceptacji | Standardy wykonania | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | pokrycie podatności | Ogłoszenie o kompilacji lub dostawcy wyraźnie naprawia CVE-2026-109618 i CVE-2026-109619 | | Zasięg wdrożenia | Wszystkie portale, pule, usługi i repliki korzystają z naprawionego środowiska wykonawczego | | Proces zaczyna obowiązywać | Stary proces roboczy, stary proces hosta i stary kontener wychodzą | | Autentyczna weryfikacja żądania | Potwierdzony SAPI, zbudowany i skonfigurowany z rzeczywistym łączem Web w celu wyeliminowania błędnego przekierowania pamięci podręcznej | | dostępność biznesowa | Kluczowe funkcje takie jak sesja, przesyłanie, importowanie i obsługa błędów powróciły normalnie. | | Zakończenie środków tymczasowych | Nieograniczona pamięć i konfiguracje ekstremalnego recyklingu pracowników zostały przywrócone zgodnie z planem pojemności lub mają wyraźny powód do przechowywania | | Dowód zmiany | Zapisz wersję pakietu lub podsumowanie obrazu, zakres aktualizacji, czas zakończenia i wyniki weryfikacji | Powyższe propozycje są propozycjami wdrożenia. Jeśli chcesz zweryfikować zachowanie OOM, nieprawidłowe wyjście lub niestandardowe poprawki, powinieneś użyć wcześniejszych testów regresji lub kontrolowanego wstrzykiwania błędów w izolowanym środowisku, aby uniknąć wielokrotnego powodowania wyczerpania pamięci w środowisku produkcyjnym jako metody akceptacji. Sprawdź także zdarzenia krytyczne PHP, awarię pracownika, nieprawidłowy restart, poziom błędów żądań i zdarzenia WAF przed i po aktualizacji. Logi mogą jedynie dostarczyć wskazówek dochodzeniowych: wystąpienie OOM nie oznacza, że ​​doszło do wykorzystania, a brak alarmów nie świadczy o tym, że nie doszło do wykorzystania. Aktualizacja naprawia ścieżki podatności, do których można dotrzeć w przyszłości; w przypadku wykrycia nieprawidłowości, takich jak manipulowanie plikami lub wyciek danych uwierzytelniających, należy przeprowadzić oddzielne dochodzenie w sprawie incydentu. ## Dodatek: Cytowane źródła i linki Wszystkie linki źródłowe zebrano poniżej. Porady, poprawki i wytyczne dostawców odzwierciedlają kontrole przeprowadzone na dzień **22 października 2026 r.**; przy kolejnych wdrożeniach należy sprawdzać dostępność aktualizacji dostawców. Do tych haseł odnoszą się numerowane cytaty w tekście. ### S1 — PHP oficjalny biuletyn bezpieczeństwa i wersja naprawcza - Źródło: Projekt PHP, 21 października 2026 r. - Cel: zakres ryzyka, cztery oficjalne wersje napraw, oficjalne środki tymczasowe i instrukcje awaryjnego backportu dla starych oddziałów. - Źródło: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) znajduje się w archiwum biuletynów rocznych ### S2 — CVE-2026-109618 Oficjalny biuletyn techniczny - Źródło: php/php-src GitHub Security Advisory, 21 października 2026 r. - Identyfikacja: GHSA-w8hw-w9fx-j79w. - Cel: Granica pokrycia dla OOM, wzmocnienie wieloczęściowe, różnica SAPI i łagodzenie. - Źródło: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) ### S3 — CVE-2026-109619 Oficjalny biuletyn techniczny - Źródło: php/php-src GitHub Security Advisory, 21 października 2026 r. - Identyfikacja: GHSA-6wmf-4rv5-p3rp. - Cel: stan zawieszenia żądań krzyżowych, producenci i konsumenci, wczesna inicjalizacja, ograniczenie konfiguracji. - Źródło: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) ### S4 — PHP 8.5 oficjalne przesłanie poprawki - Źródło: php/php-src. - Prześlij: `31c0ea7d7ff1d1fccb6492e52dab544011628065`. - Cel: Potwierdzenie formalnego zgłoszenia w celu naprawienia dwóch luk jednocześnie i wyjaśnienie ogólnego kierunku zmian. - Źródło: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065) ### S5 — PHP 8.5 Oficjalnie odrestaurowany i kompletny dyferencjał - Źródło: różnica na podstawie tego samego oficjalnego zgłoszenia. - Cel: Sprawdź konkretną implementację alokatora, VM, HTTP globals, sesję, serializację i cykl życia żądania. - Źródło: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff) ### S6 — PHP 8.1 oficjalne awaryjne przesłanie backportu - Źródło: php/php-src. - Prześlij: `1d7dec178a094e6e75b229ce22754045f8c6070a`. - Cel: Sprawdź szybkie wyjście starych oddziałów i prześlij zmiany w zachowaniu postępu. - Źródło: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a) - Źródło: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff) ### S7 — PHP 7.4 oficjalny oddział awaryjnego backportu - Źródło: gałęzie kodu źródłowego php/php-src, PHP wymienione w oficjalnym biuletynie bezpieczeństwa. - Źródło: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619) ### S8 — PHP 8.0 oficjalny oddział awaryjnego backportu - Źródło: gałęzie kodu źródłowego php/php-src, PHP wymienione w oficjalnym biuletynie bezpieczeństwa. - Źródło: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) ### S9 — PHP 8.1 oficjalny oddział awaryjnego backportu - Źródło: gałęzie kodu źródłowego php/php-src, PHP wymienione w oficjalnym biuletynie bezpieczeństwa. - Źródło: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619) ### S10 — Ubuntu Biuletyn bezpieczeństwa USN-8948-1 - Źródło: Canonical / Ubuntu, 21 października 2026 r. - Cel: Wydanie backportu i kompletnych przykładów wersji pakietu. - Źródło: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1) ### S11 — PHP-FPM Configuration Instrukcja - Źródło: oficjalny dokument PHP. - Cel: semantyka konfiguracji, taka jak `php_admin_value`, `php_admin_flag`, `pm.max_requests` itp. - Źródło: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php) ### S12 — PHP Core INI Instrukcja konfiguracji - Źródło: oficjalny dokument PHP. - Cel: Definicja i zakres treści żądania, przesyłania, pamięci i automatycznej konfiguracji odczytu POST. - Źródło: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php) ### S13 — Nginx żąda limitu rozmiaru treści - Źródło: oficjalny dokument Nginx. - Cel: Znaczenie `client_max_body_size` i dostępne poziomy konfiguracji. - Źródło: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) ### S14 — Bufor żądań Nginx FastCGI - Źródło: oficjalny dokument Nginx. - Cel: Kolejność przetwarzania i funkcja `fastcgi_request_buffering`. - Źródło: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering) ### S15 — Nginx Instrukcje dotyczące stanu i zwrotu - Źródło: oficjalny dokument Nginx. - Cel: Składnia konfiguracyjna `if` i `return`. - Źródło: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if) ### S16 — Cloudflare PHP2Shell Instrukcje dotyczące ochrony - Źródło: oficjalny blog Cloudflare. - Cel: Opis zakresu wdrożenia WAF, układu planu Free i mechanizmu wykrywania. - Źródło: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) ## Konsultacje dotyczące konserwacji zabezpieczeń Potrzebujesz pomocy w aktualizacji systemów PHP? Możemy ocenić narażenie, zaplanować aktualizację i zweryfikować działającą aplikację. [Omów aktualizacje zabezpieczeń]() [Oryginalna strona]() · [Indeks treści]() KeenDigit LLC · Identyfikator zgłoszenia w Wyoming: 2026-002106155 [Sprawdź to u Sekretarza Stanu Wyoming]() © 2026 KeenDigit LLC · Sheridana, Wyoming, USA · Wszelkie prawa zastrzeżone.