PHP2Shell: skuteczna ochrona i problem witryn bez aktualizacji

Stan na 22 października 2026 r. PHP2Shell dotyczy środowiska wykonawczego stanowiącego podstawę dużej części internetu. Dwie krytyczne podatności w odpowiednich warunkach umożliwiają zdalne wykonanie kodu bez uwierzytelnienia. Aktualizacje bezpieczeństwa są dostępne od 21 października. Najważniejsze pytanie dotyczy obecnie rzeczywistego stanu publicznie dostępnych instalacji. [1] [6]

Nowe informacje: próby ataku przed publikacją

AWS informuje o próbie wykorzystania PHP2Shell z 17 października 2026 r., wykrytej we własnej telemetrii MadPot jeszcze przed publicznym ujawnieniem podatności. W przypadku kolejnych obserwowanych prób skuteczność wobec rzeczywistych systemów pozostawała niepewna. To udokumentowany sygnał ostrzegawczy, a nie globalna liczba przejętych systemów. Analiza potencjalnie dotkniętych instalacji powinna zatem obejmować także okres sprzed publikacji. AWS: własne obserwacje i ograniczenia

Co kryje się pod nazwą PHP2Shell?

Identyfikatory podatności to CVE-2026-109618 oraz CVE-2026-109619. Pierwszy błąd dotyczy nieprawidłowego stanu pamięci po wystąpieniu jej niedoboru. Drugi wynika z pozostawienia wewnętrznych odwołań do już zwolnionej pamięci. Dalsze przetwarzanie takich stanów może prowadzić do naruszenia bezpieczeństwa. Oba problemy występują w samym PHP. [3] [4]

Określenie „wszystkie wersje od PHP 5” oddaje wyjątkowo szeroki zakres problemu, ale nie zastępuje kontroli pakietów. Weryfikacji wymagają stare gałęzie PHP 5 i 7 oraz PHP 8. Dokumentacja cPanel wymienia także starsze pakiety i konkretne poprawione rewizje dostawców. Przejście z PHP 7 na dowolne PHP 8 nie stanowi więc dowodu ochrony. [7]

Szczególnie poważny przypadek dotyczy Apache z mod_php: potwierdzona ścieżka ataku działa jeszcze przed uruchomieniem kodu aplikacji. PHP-FPM również nie stanowi bezpiecznego wyjątku; PHP Foundation informuje o potwierdzonym wykonaniu kodu przez ścieżki zależne od aplikacji. Logowanie do WordPressa nie zapewnia zatem skutecznej ochrony przed błędem niższej warstwy. [2]

Które aktualizacje zapewniają ochronę?

Poprawione oficjalne wydania to 8.2.35, 8.3.36, 8.4.27 i 8.5.12; właściwe jest również późniejsze poprawione wydanie odpowiedniej gałęzi. PHP 8.1 i starsze nie otrzymują już regularnych wydań projektu PHP. Wyjątkowo udostępniono minimalne poprawki kodu źródłowego dla 7.4, 8.0 i 8.1. Dystrybucje oraz dostawcy LTS mogą oferować własne poprawione pakiety. [1]

Stary numer wersji bazowej nie dowodzi automatycznie braku poprawki. Liczy się pełna rewizja pakietu i potwierdzenie usunięcia obu podatności. Z kolei samo oznaczenie „PHP 8” nie potwierdza bezpieczeństwa. [7]

Od aktualizacji pakietu do ochrony usługi

1. Inwentaryzacja: Zakres obejmuje domeny, pule PHP, kontenery, zapomniane instalacje testowe i wbudowane panele administracyjne.
2. Potwierdzenie poprawki: Każde środowisko wymaga udokumentowania źródła pakietu, rewizji i usunięcia obu podatności.
3. Wymiana działających instancji: Procesy PHP muszą załadować poprawiony kod. Własne kontenery wymagają poprawionego obrazu i ponownego wdrożenia. Aktualizacja hosta nie zmienia istniejącego obrazu kontenera. [8]
4. Kontrola obsługi WWW: Wiersz poleceń może korzystać z innej instalacji PHP niż witryna. Weryfikację zamyka przypisanie domeny do faktycznie działającego środowiska i sprawdzenie podstawowych funkcji.

W przypadku braku możliwości natychmiastowej aktualizacji ENISA zaleca rozważenie izolacji publicznie dostępnych aplikacji. Statyczna strona techniczna obsługiwana przed PHP może zatrzymać ruch do podatnego środowiska. Wtyczka trybu konserwacji działająca wewnątrz tej samej aplikacji PHP nie zapewnia takiego oddzielenia w sposób niezawodny. [5]

Oficjalne środki konfiguracyjne jedynie tymczasowo ograniczają ekspozycję. Przykładowo session.upload_progress.enabled=0 blokuje określone potwierdzone ścieżki związane z sesją, lecz nie wszystkie warianty. Zmiana limitów pamięci również nie jest uniwersalną naprawą. Nieograniczona pamięć PHP może zwiększyć ryzyko niedostępności; limity poza PHP wymagają odpowiedniego skoordynowania. Żadne z tych działań nie zastępuje aktualizacji. [3] [4]

Skutki braku aktualizacji

Punktem wyjścia jest wykonanie kodu z uprawnieniami procesu WWW, a nie automatyczne uzyskanie uprawnień root. Zależnie od uprawnień i dostępnych sekretów możliwe następstwa obejmują kradzież danych dostępowych do bazy, ujawnienie danych klientów, zmianę treści, instalację złośliwego oprogramowania oraz nadużycie kluczy API. Dostępne usługi wewnętrzne mogą stać się kolejnym celem, jeśli pozwalają na to połączenia sieciowe i uprawnienia. [3]

W sklepie internetowym zmieniona strona płatności może wyrządzić większe szkody niż widoczna awaria. Dochodzą koszty analizy, odtwarzania, przestoju i utraty zaufania. Późniejsza aktualizacja nie usuwa wcześniej zainstalowanej furtki. Konkretne ślady włamania wymagają izolacji, zabezpieczenia dowodów, kontroli danych dostępowych i odtworzenia z zaufanego stanu.

Czy administratorzy rzeczywiście zainstalują poprawki?

Ocena: Szybki początkowy spadek liczby zagrożonych instalacji jest prawdopodobny; pełne zakończenie aktualizacji w ciągu kilku dni wydaje się mało realne. Centralnie utrzymywane platformy mogą poprawić wiele witryn jednocześnie. Własne serwery zależą od odpowiedzialności, dostępności pakietów, zgodności i kontrolowanych restartów. Google Cloud wyraźnie rozróżnia środowiska aktualizowane automatycznie oraz usługi wymagające ponownego wdrożenia. [8]

Najtrudniejsza pozostanie zapewne grupa porzuconych projektów, starych wdrożeń agencyjnych, kontenerów bez procesu utrzymania i aplikacji zależnych od niewspieranych gałęzi. Opóźnienia nie oznaczają automatycznie zaniedbania administratorów. Brak budżetu, niejasny podział odpowiedzialności i niesprawdzone zależności starszych aplikacji mogą organizacyjnie zablokować prostą technicznie poprawkę. Konkretna globalna skuteczność aktualizacji byłaby obecnie spekulacją.

Ile witryn pozostanie zagrożonych?

Według W3Techs z 22 października PHP występuje w 69,3 proc. witryn o rozpoznanym języku programowania po stronie serwera. Wśród rozpoznanych witryn PHP udział PHP 7 wynosi 26,9 proc., a PHP 5 — 7,7 proc., łącznie 34,6 proc. Te liczby opisują popularność i starsze wersje, a nie zmierzoną liczbę instalacji bez poprawki. [9]

Nie wynika z tego wiarygodna bezwzględna liczba nadal zagrożonych witryn. Poprawki dostawców, różnice konfiguracji, ukryte numery wersji oraz wiele witryn na jednym serwerze uniemożliwiają proste przeliczenie. Pojedyncze podstrony, domeny i serwery są ponadto różnymi jednostkami zliczania.

Wyłącznie ilustracja rachunkowa: w grupie miliona faktycznie podatnych instalacji skuteczne ukończenie 95 proc. aktualizacji pozostawiłoby 50 000 bez poprawki. To ani pomiar, ani prognoza. Obliczenie pokazuje jedynie, dlaczego nawet wysoki poziom ukończenia aktualizacji może pozostawić znaczącą grupę zagrożonych systemów. Dla konkretnej witryny potwierdzony stan poprawki ma większą wartość niż globalny procent.

Linux w praktyce: inwentaryzacja faktycznie używanego środowiska

Poniższe przykłady dotyczą systemów Debian/Ubuntu z APT i już skonfigurowanymi zaufanymi repozytoriami. Odpowiednia gałąź PHP musi być wcześniej zainstalowana. Systemy RPM, panele hostingowe i własne kontenery wymagają procedury właściwego dostawcy. Dodanie przypadkowego zewnętrznego repozytorium nie jest wiarygodną strategią naprawy.

Przed zmianą potrzebne są kopia umożliwiająca odtworzenie, przypisanie domen do pul PHP i krótki plan testów funkcjonalnych. Instalacja pakietów może sama restartować usługi, dlatego okno serwisowe rozpoczyna się przed poleceniem instalacji. Inwentaryzacja pokazuje CLI i usługi, ale jeszcze nie potwierdza sposobu obsługi witryny:

cat /etc/os-release
command -v php
php -v
php --ini
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
systemctl list-units --type=service --all | grep -E 'php.*fpm|apache2|nginx'
ps -eo pid,lstart,comm | grep -E 'php|apache2'

Domena może korzystać z PHP 8.4 przez FPM, podczas gdy polecenie php wskazuje na 8.5. Dodatkowe kopie mogą istnieć w kontenerach, katalogach hostingu i zapomnianych usługach testowych. Potwierdzenie dla każdej instalacji wymaga źródła pakietu, pełnej rewizji, usługi lub kontenera oraz przypisanych witryn.

Aktualizacja PHP 8.4 przez APT

Procedura aktualizuje wyłącznie już zainstalowane pakiety gałęzi 8.4, w tym rozszerzenia i ewentualny moduł Apache. Symulacja nie zmienia pakietów. Kandydat musi zawierać PHP 8.4.27 albo potwierdzoną przez dostawcę poprawkę obu CVE. Dla Debiana 13 jako poprawioną udokumentowano rewizję 8.4.27-1~deb13u1. Dokumentacja APT · Debian: CVE-2026-109618 · Debian: CVE-2026-109619

set -euo pipefail
branch=8.4
sudo apt-get update
mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
    "php${branch}-*" "libapache2-mod-php${branch}" 2>/dev/null |
  awk '$1 == "ii" { print $2 }'
)
test "${#php_packages[@]}" -gt 0
apt-cache policy "${php_packages[@]}"
sudo apt-get -s install --only-upgrade "${php_packages[@]}"

Instalacja następuje dopiero po sprawdzeniu planu. Nieoczekiwane usuwanie pakietów, zmiana gałęzi lub nadal podatny kandydat wymagają przerwania procedury. Kolejny blok należy do tej samej sesji Bash i zakłada istniejącą usługę FPM:

sudo apt-get install --only-upgrade "${php_packages[@]}"
sudo /usr/sbin/php-fpm8.4 -t
sudo systemctl restart php8.4-fpm
systemctl is-active php8.4-fpm
/usr/bin/php8.4 -v
/usr/sbin/php-fpm8.4 -v

Aktualizacja PHP 8.5 przez APT

Dla istniejącej instalacji 8.5 obowiązuje analogiczny przebieg z poprawionym kandydatem od 8.5.12 albo potwierdzoną poprawką dostawcy. Standardowe repozytorium Debiana 13 nie udostępnia PHP 8.5 tylko dlatego, że istnieje nowsza gałąź PHP. Brak odpowiedniego kandydata z już zatwierdzonego źródła kończy procedurę przed instalacją.

set -euo pipefail
branch=8.5
sudo apt-get update
mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
    "php${branch}-*" "libapache2-mod-php${branch}" 2>/dev/null |
  awk '$1 == "ii" { print $2 }'
)
test "${#php_packages[@]}" -gt 0
apt-cache policy "${php_packages[@]}"
sudo apt-get -s install --only-upgrade "${php_packages[@]}"

Kontynuacja również wymaga sprawdzonego planu, tej samej sesji Bash i istniejącej usługi FPM.

sudo apt-get install --only-upgrade "${php_packages[@]}"
sudo /usr/sbin/php-fpm8.5 -t
sudo systemctl restart php8.5-fpm
systemctl is-active php8.5-fpm
/usr/bin/php8.5 -v
/usr/sbin/php-fpm8.5 -v

Apache z mod_php wymaga natomiast zaktualizowanego modułu Apache oraz kontrolowanego restartu po poprawnym teście konfiguracji. W Debianie służy do tego sudo apache2ctl configtest. Aktualizacja PHP w konfiguracji opartej wyłącznie na FPM nie wymaga automatycznie restartu nginx. Oddzielne procesy nadrzędne FPM, stale działające usługi CLI i kontenery wymagają osobnej obsługi. Restart może przerwać aktywne żądania; w środowisku redundantnym wdrożenie powinno następować etapami.

Aktualny pakiet nie potwierdza aktualnego procesu

Linux może utrzymywać proces korzystający ze starego pliku wykonywalnego mimo jego zastąpienia. Nowe wywołanie php -v pokazuje wtedy poprawioną wersję, lecz istniejący proces nadal używa starego kodu. Poniższa kontrola tylko odczytuje informacje i wykrywa procesy PHP korzystające z usuniętego pliku:

sudo bash <<'BASH'
for link in /proc/[0-9]*/exe; do
  target=$(readlink "$link" 2>/dev/null) || continue
  case "$target" in
    *php*"(deleted)"*)
      pid=${link#/proc/}
      pid=${pid%/exe}
      printf 'PID %s: %s\n' "$pid" "$target"
      ;;
  esac
done
BASH

Trafienie wymaga sprawdzenia wersji i usługi, ale nie stanowi dowodu włamania. Pusty wynik również nie potwierdza pełnej ochrony: załadowane moduły Apache, biblioteki i oddzielnie osadzone środowiska wymagają własnej kontroli. Liczą się aktywne procesy, a nie wyłącznie lista pakietów. Testy konkretnej aplikacji powinny objąć logowanie, wysyłanie plików, formularze, kolejki i zadania cykliczne. Publiczne strony phpinfo() nie nadają się do takiej kontroli; lepsza jest chroniona diagnostyka wewnętrzna lub przypisanie aktywnego procesu.

PHP 7.4: poprawka bezpieczeństwa zamiast niezmienionego 7.4.33

PHP 7.4 pozostaje niewspierane. Preferowane rozwiązanie to migracja do wspieranej gałęzi albo zweryfikowana poprawka LTS od dotychczasowego dostawcy. Na nieunikniony okres przejściowy projekt PHP opublikował minimalną poprawkę kodu źródłowego obejmującą oba identyfikatory PHP2Shell. Nie przywraca to ogólnego wsparcia ani nie gwarantuje naprawy innych podatności.

Commit bezpieczeństwa zweryfikowany 22 października to 712e60f9edfd03f0960fc4fc3c2c375f42b90aa2. Poniższa procedura jednoznacznie wiąże źródła z tą rewizją. Ponowne zbudowanie niezmienionego wydania 7.4.33 nie zawiera tej poprawki. PHP: konkretny commit bezpieczeństwa

Przykład tworzy minimalne CLI/FPM w oddzielnym, zgodnym środowisku kompilacji Debian/Ubuntu z dostępnymi Git i certyfikatami CA. Wszystkie bloki działają w tej samej sesji Bash. To nie jest instalacja wykonana ani w pełni zatwierdzona na serwerze produkcyjnym na potrzeby artykułu. Stare źródła PHP nie są zgodne z dowolnymi aktualnymi bibliotekami systemowymi.

set -euo pipefail
workdir=$(mktemp -d "$HOME/php74-php2shell.XXXXXX")
cd "$workdir"
git init php-src
cd php-src
git remote add origin https://github.com/php/php-src.git
commit=712e60f9edfd03f0960fc4fc3c2c375f42b90aa2
git fetch --depth=1 origin "$commit"
git checkout --detach FETCH_HEAD
test "$(git rev-parse HEAD)" = "$commit"
git show -s --format='%H%n%s%n%b' HEAD

Poniżej znajdują się podstawowe narzędzia i oddzielny katalog instalacyjny. --disable-all ogranicza zakres przykładu; wynik nie zawiera automatycznie wszystkich rozszerzeń potrzebnych WordPressowi lub innej aplikacji. Użytkownik i grupa www-data muszą istnieć w środowisku docelowym. PHP: instalacja w Uniksie · PHP: opcje kompilacji FPM

sudo apt-get update
sudo apt-get install --no-install-recommends \
  build-essential autoconf bison re2c pkg-config \
  libxml2-dev libsqlite3-dev

./buildconf --force
prefix=/opt/php74-php2shell-712e60f9
test ! -e "$prefix"
./configure \
  --prefix="$prefix" \
  --with-config-file-path="$prefix/etc" \
  --with-config-file-scan-dir="$prefix/etc/conf.d" \
  --disable-all --enable-cli --enable-fpm --enable-session \
  --with-fpm-user=www-data --with-fpm-group=www-data \
  --without-pear
make -j2
NO_INTERACTION=1 REPORT_EXIT_STATUS=1 make test

Nieudane testy i niewyjaśnione pominięcia istotnych testów wymagają analizy. Instalacja w nowym katalogu następuje dopiero po zaakceptowanym przebiegu testów; nie zastępuje /usr/bin/php ani pakietów dystrybucji:

sudo make install
sudo install -d -m 0755 "$prefix/etc/conf.d"
sudo install -m 0644 php.ini-production "$prefix/etc/php.ini"
"$prefix/bin/php" -n -v
"$prefix/bin/php" --ini
"$prefix/sbin/php-fpm" -v
git rev-parse HEAD

Wynik może nadal zawierać numer wersji 7.4. Dowodem poprawki są zweryfikowany commit źródłowy, protokół kompilacji i faktycznie uruchomiony artefakt. Użycie produkcyjne wymaga jeszcze potrzebnych rozszerzeń i testów, np. sterowników bazy danych, mbstring, XML, cURL lub ZIP. Biblioteki deweloperskie, ABI oraz phpize/php-config muszą odpowiadać dokładnie temu buildowi.

Następnie osobnej kontroli wymagają konfiguracja FPM, konta pul i uprawnienia plików. Dedykowane gniazdo i oddzielna usługa zapobiegają przypadkowemu mieszaniu z dotychczasowym środowiskiem. Dopiero po poprawnym teście nowym php-fpm -t -y /sciezka/do/php-fpm.conf następuje przełączenie obsługi WWW na tę pulę. Poprawne wywołanie CLI nie zmienia żadnej witryny. W przypadku nieudanego wdrożenia powrót nie powinien po cichu przywracać publicznego dostępu do podatnego środowiska; rozwiązaniem przejściowym pozostaje izolacja.

Ślady ataku: korelacja wielu sygnałów

Datadog odtworzył błędy we własnym laboratorium. Skuteczne wykonanie kodu nie musi powodować awarii procesu ani podejrzanego statusu HTTP. HTTP 200 nie jest zatem potwierdzeniem bezpieczeństwa. Podejrzane formularze, błędy pamięci i niespodziewane procesy potomne nabierają znaczenia w powiązaniu czasowym. Pojedynczy błąd braku pamięci nie dowodzi ataku. Datadog Security Labs: własna analiza

Dochodzenie łączy logi serwera WWW i proxy, błędy PHP, zdarzenia procesów oraz nieoczekiwane zmiany plików. Istniejące dowody wymagają zabezpieczenia przed czyszczeniem. Masowe zapisywanie pełnej treści formularzy wprowadzałoby hasła i dane osobowe do logów; lepsze są metadane i kontrolowane zbieranie dowodów. WAF może ograniczać żądania, ale nie naprawia PHP. Zakończenie wymaga dwóch oddzielnych ustaleń: aktywnego poprawionego środowiska oraz zbadania możliwości wcześniejszego włamania.

Rozpoznawanie PHP2Shell w logach: podejrzenie to jeszcze nie dowód

Nie istnieje uniwersalny wpis „wykryto PHP2Shell”. Analiza musi rozróżniać nietypowe żądanie, błąd techniczny i potwierdzone wykonanie obcego kodu. Przydatny ciąg zdarzeń łączy nietypowe żądanie na proxy, błąd lub zdarzenie procesu odpowiedniej puli PHP oraz późniejsze działanie niewynikające z normalnej pracy. Brak wpisów może też oznaczać wyłączone logowanie, rotację albo zbyt krótki okres przechowywania.

Pierwsze zapytania do logów w Linuksie

Poniższe polecenia odczytują istniejące dane. Nazwy usług, ścieżki i przedział czasu muszą odpowiadać instalacji. Podana godzina korzysta z lokalnej strefy systemu; korelacja między systemami wymaga uwzględnienia przesunięć i synchronizacji zegarów. Błędy PHP trafią do dziennika tylko wtedy, gdy usługa rzeczywiście wysyła tam takie komunikaty. systemd: journalctl

sudo journalctl --since '2026-10-17 00:00:00' \
  -u php8.4-fpm -u php8.5-fpm -u apache2 -u nginx \
  --no-pager -o short-iso |
grep -Ei 'Allowed memory size.*exhausted|Out of memory|segfault|SIGSEGV|child .*exited on signal'

Brak wyniku oznacza wyłącznie „brak dopasowania w tych źródłach dla tego wzorca”. Oddzielne pliki błędów FPM, logi kontenerów i protokoły konkretnych hostów wymagają dodatkowych zapytań. Analiza powinna obejmować także pliki po rotacji.

Dla typowych logów dostępu Apache/nginx zapisujących żądanie HTTP poniższe zapytanie zwraca ostatnie sto pasujących wierszy POST z odczytanych plików. To wstępna analiza, nie kompletny skaner; kolejność plików nie gwarantuje sortowania chronologicznego:

sudo zgrep -hE '"POST [^"]+ HTTP/[0-9.]+"' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* |
tail -n 100

Nieistniejące ścieżki albo inny format wymagają dopasowania wyboru plików. Standardowe logi dostępu zwykle nie zawierają całego ciała żądania. Często zapisywana liczba bajtów opisuje zazwyczaj odpowiedź, a nie przesłany plik. Szukanie PHP_SESSION_UPLOAD_PROGRESS w zwykłych logach dostępu może więc niczego nie znaleźć mimo wysłania takiego pola formularza. Brakujących danych ciała żądania nie da się odtworzyć wstecz. Apache: znaczenie i konfiguracja logów

Dodatkowego kontekstu może dostarczyć aktualny obraz relacji między procesami:

ps -eo pid,ppid,lstart,user,comm --forest

Lista pokazuje wyłącznie procesy działające w chwili odczytu. Zakończone polecenia będą widoczne tylko we wcześniej uruchomionym monitorowaniu wykonania, np. w telemetrii audytowej lub EDR. Monitoring włączony dzisiaj nie dostarcza historii wykonania z przeszłości.

Lepsze logowanie bez gromadzenia treści formularzy

Dodatkowy log nginx może zestawić identyfikator żądania, czas, metodę, ścieżkę, status, rozmiar żądania i czas obsługi. Poniższa propozycja formatu należy do kontekstu http. Ułatwia przyszłą analizę; wcześniejsze braki danych pozostają brakami. nginx: log_format i access_log

log_format php2shell escape=json
  '{"time":"$time_iso8601","request_id":"$request_id",'
  '"client":"$remote_addr","method":"$request_method","uri":"$uri",'
  '"status":"$status","request_bytes":"$request_length",'
  '"response_bytes":"$body_bytes_sent","duration":"$request_time",'
  '"upstream_status":"$upstream_status"}';

Następna dyrektywa włącza ten format w wybranym kontekście server. Istniejące logi i dziedziczenie wymagają sprawdzenia, aby nowa dyrektywa nie zastąpiła niezauważenie potrzebnego logowania.

access_log /var/log/nginx/php2shell-access.log php2shell;

Kontrolowane przeładowanie poprzedza poprawny test nginx -t. request_bytes obejmuje całe odebrane żądanie wraz z nagłówkami, a nie sam rozmiar pliku czy wynikowe zużycie pamięci PHP. Format pomija parametry zapytania, ciasteczka, nagłówki autoryzacji i ciało żądania. Adresy IP oraz ścieżki nadal mogą zawierać dane osobowe; konfiguracja wymaga kontroli dostępu, retencji i rotacji. Za proxy adres klienta jest wiarygodny tylko przy poprawnie skonfigurowanym łańcuchu zaufania. OWASP: bezpieczne logowanie

Ochrona przed zakończeniem aktualizacji

Priorytetem jest poprawione środowisko wykonawcze. Dodatkowe zabezpieczenia ograniczają ekspozycję i możliwe skutki, ale nie zastępują poprawki. Dla publicznej aplikacji bez możliwości szybkiej aktualizacji najczytelniejszym rozwiązaniem przejściowym jest izolacja przed PHP: statyczna strona techniczna, VPN lub wcześniejsza kontrola dostępu. Bezpośredni dostęp do serwera źródłowego musi podlegać tym samym ograniczeniom; chroniona ścieżka przez CDN przy otwartym backendzie nie wystarcza.

• Limity żądań: Limity rozmiaru, przesyłania i częstotliwości na reverse proxy powinny odpowiadać rzeczywistym potrzebom. Legalne importy i duże pliki wymagają sprawdzonych reguł. Małe żądanie może wewnętrznie zużyć więcej pamięci, więc limit rozmiaru nie zapewnia pełnej ochrony.
• WAF jako dodatkowa warstwa: Odpowiednie reguły dostawcy wymagają włączenia i kontroli egzekwowania. Tryb obserwacyjny niczego nie blokuje; HTTP 403 potwierdza jedynie odrzucenie danego żądania.
• Ograniczone uprawnienia: Oddzielne konta pul, minimalne prawa plików, ograniczone konta baz danych i dostęp sieciowy zmniejszają możliwe szkody. Przejęta aplikacja nadal może nadużyć wszystkich legalnie dostępnych sekretów.
• Oficjalne środki przejściowe: Wczesne wyłączenie śledzenia postępu przesyłania w sesji blokuje określone ścieżki, lecz nie usuwa obu błędów w całości. Powszechne zniesienie limitu pamięci PHP bez odpowiednich ograniczeń zewnętrznych może spowodować dodatkowe awarie.

Konkretne ślady włamania: oddzielna naprawa i obsługa incydentu

Usunięcie podejrzanego pliku i aktualizacja PHP nie wystarczą do wiarygodnego zamknięcia sprawy. Najpierw potrzebna jest izolacja dotkniętej instancji przed dalszym dostępem. Równolegle zabezpieczenia wymagają odpowiednie logi, znaczniki czasu i dostępne dane procesów. Nieprzemyślane czyszczenie może zniszczyć przydatne dowody.

Kolejne kroki obejmują ocenę dostępnych danych i sąsiednich systemów, wymianę potencjalnie ujawnionych danych dostępowych z zaufanego środowiska oraz w razie potrzeby odbudowę ze zweryfikowanych źródeł. Kopia zapasowa musi poprzedzać możliwe naruszenie zarówno czasowo, jak i pod względem zawartości. Powrót do publicznej obsługi wymaga poprawionego aktywnego środowiska, sprawdzonej aplikacji i dalszej obserwacji. „Poprawka zainstalowana” oraz „incydent zbadany” pozostają oddzielnymi ustaleniami.

Źródła

1. PHP: Security advisory, 21 October 2026
2. PHP Foundation: security release and background
3. PHP: CVE-2026-109618
4. PHP: CVE-2026-109619
5. ENISA: joint statement
6. NHS England: PHP2Shell
7. cPanel: corrected package revisions
8. Google Cloud: runtime updates and redeployment
9. W3Techs: PHP usage, 22 October 2026

Dodatkowe źródła pierwotne i dokumentacja

• PHP: pinned PHP 7.4 security backport
• PHP: Unix installation
• PHP: FPM compilation options
• APT: apt-get options and simulation
• Debian: CVE-2026-109618
• Debian: CVE-2026-109619
• AWS: MadPot observations before disclosure
• Datadog Security Labs: reproduction, detection and remediation

Dalsze analizy i doniesienia

• Brandefense
• SOCRadar
• Abstract Security
• Tanium
• SecurityWeek

Dodatkowo wskazany artykuł Prophet Security był niedostępny podczas analizy i nie został wykorzystany jako dowód.

Dokumentacja analizy logów

• nginx
• Apache HTTP Server
• systemd journalctl
• OWASP Logging Cheat Sheet