Krótko: Kto samodzielnie zarządza serwerem root lub vServerem, po PHP2Shell musi go także samodzielnie zabezpieczyć: doprowadzić pakiety PHP do stanu z usuniętą luką, zrestartować wszystkie procesy PHP i sprawdzić wynik. Operator centrum danych zajmuje się zwykle tylko sprzętem, wirtualizacją i siecią. Potem warto trwale utwardzić serwer.
Państwa odpowiedzialność przy własnym serwerze
W przypadku niezarządzanego serwera root lub vServera wynajmują Państwo moc obliczeniową, a nie opiekę. System operacyjny, serwer WWW, PHP, baza danych, zapora sieciowa, kopie zapasowe i monitoring leżą w Państwa rękach. Dla zarządu i właścicieli oznacza to: jeśli nikt w firmie ani u usługodawcy nie przejął tych zadań wyraźnie, nie wykona ich nikt.
PHP2Shell to uwidacznia. Obie luki, CVE-2026-109618 i CVE-2026-109619, tkwią w samym PHP i umożliwiają wykonanie kodu bez logowania. Projekt PHP opublikował 21.10.2026 wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca natychmiastową aktualizację, a jeśli nie jest to możliwe, czasowe odłączenie serwera WWW od sieci.
Zabezpieczenie vServera: kontrola zasobów i stanu pakietów
Proszę najpierw uzyskać przegląd, jakie wersje PHP są zainstalowane i z jakiego źródła pochodzą. Wiele serwerów korzysta obok pakietów dystrybucji z dodatkowych repozytoriów. Poniższe polecenia tylko odczytują. Nazwy pakietów to przykłady.
# Debian/Ubuntu: zainstalowane pakiety PHP i ich pochodzenie
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Jakie pliki binarne PHP w ogóle istnieją?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Sam numer wersji nie wystarcza. Dystrybucje często dostarczają poprawki bezpieczeństwa jako backport, a wyświetlany numer pozostaje wtedy starszy. Rozstrzyga dziennik zmian pakietu.
# Debian/Ubuntu (nazwa pakietu jako przykład)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# Rodzina RHEL (nazwa pakietu jako przykład)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Szczegółową instrukcję podaje artykuł Kontrola wersji PHP i stanu poprawek.
Instalacja aktualizacji i odnowienie wszystkich procesów
Proszę zainstalować aktualizacje przez menedżer pakietów, a potem zrestartować każdą usługę, która ładuje PHP. Zależnie od architektury jest to PHP-FPM, Apache z mod_php, LiteSpeed lub serwer aplikacji. Nowe pliki na dysku nie wystarczą, dopóki w pamięci działają stare procesy.
# Znajdź usługi z PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Pokaż procesy z czasem startu
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: wykryj programy ze starymi bibliotekami (jeśli zainstalowano)
needrestart -r l
Każdy istotny proces powinien być uruchomiony po aktualizacji. Pomocne jest narzędzie needrestart w systemach Debian, które pokazuje usługi ze starymi bibliotekami. Szczegóły restartu opisuje artykuł Restart PHP-FPM i wszystkich procesów roboczych.
Poprawka nie usuwa szkodliwego oprogramowania wprowadzonego przed aktualizacją. Proszę zachować logi serwera WWW od 20.10.2026 i sprawdzić serwer pod kątem śladów, zanim zostanie uznany za czysty.
Do pierwszego poszukiwania śladów nadaje się kilka kontroli, które niczego nie zmieniają. Proszę szukać plików PHP, które od 17.10.2026 zostały utworzone lub zmienione w katalogach WWW, nieznanych wpisów w crontabach wszystkich użytkowników, nowych użytkowników systemowych i kluczy SSH oraz procesów użytkownika serwera WWW, które utrzymują połączenia wychodzące.
# Pliki PHP zmienione od 17.10.2026 (ścieżka jako przykład)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Połączenia sieciowe z przypisanym procesem
ss -tupn
Żadna z tych kontroli sama nie dowodzi włamania, a pusty wynik nie dowodzi czegoś przeciwnego. Pokazują jednak, czy potrzebne jest głębsze dochodzenie. Proszę pracować na kopiach logów i nie zmieniać podejrzanych plików, dopóki stan nie zostanie zabezpieczony. W razie znalezisk bezpieczną drogą jest uporządkowane dochodzenie. W takim przypadku proszę nie wyłączać serwera po prostu ani nie instalować go natychmiast od nowa, bo zaginą ślady ważne dla oceny obowiązków zgłoszeniowych i dla ewentualnego zawiadomienia organów ścigania.
Trwałe utwardzenie serwera
Po doraźnej poprawce następuje podstawowe zabezpieczenie. Nie zapobiega każdej luce, ale ogranicza szkody i skraca czas reakcji następnym razem. Sprawdziły się następujące punkty:
- Dostępy: SSH tylko z kluczem, brak bezpośredniego logowania root, interfejsy administracyjne osiągalne wyłącznie ze znanych sieci.
- Zapora: otwierać tylko porty naprawdę potrzebne, ograniczyć połączenia wychodzące serwera WWW.
- Konfiguracja PHP: wyłączyć niebezpieczne funkcje,
open_basedirdla każdej strony, osobne pule i użytkownicy dla każdej aplikacji. - Prawa do plików: serwer WWW nie może zapisywać kodu programu, katalogi uploadu nie wykonują PHP.
- Aktualizacje: instalować aktualizacje bezpieczeństwa automatycznie, na stałe zaplanować restart i kontrolę.
- Kopie zapasowe: kopie według reguły 3-2-1, co najmniej jedna kopia poza serwerem i chroniona przed zmianą.
- Logi: zbierać logi centralnie i przechowywać wystarczająco długo.
Jak wygląda wiarygodna kopia zapasowa, opisuje artykuł Kopie zapasowe według reguły 3-2-1. Ramą dla firm jest IT-Grundschutz (podstawowa ochrona IT) wydany przez BSI.
Kiedy lepszy jest serwer zarządzany
Własny serwer się opłaca, jeśli ktoś niezawodnie przejmuje jego pielęgnację: śledzi aktualizacje, ocenia sytuacje takie jak PHP2Shell, potrafi reagować w nocy. Jeśli brakuje takich zasobów, sensowny jest albo serwer zarządzany, albo stała umowa serwisowa. W obu przypadkach ważne jest pisemne ustalenie odpowiedzialności. Więcej w artykule Serwer zarządzany: wyjaśnienie odpowiedzialności.
Jak konkretnie pomaga PHP SOS?
- Rejestrujemy wszystkie instalacje PHP, repozytoria pakietów i usługi na Państwa serwerze oraz oceniamy rzeczywisty stan poprawek.
- Instalujemy aktualizacje, restartujemy wszystkie procesy i dokumentujemy wynik.
- Sprawdzamy serwer pod kątem śladów włamania i zabezpieczamy logi do późniejszej analizy.
- W ramach naszego utwardzania serwerów prawidłowo konfigurujemy dostępy, zaporę, pule PHP i uprawnienia.
- Na życzenie przejmujemy bieżącą opiekę w ramach umowy serwisowej bezpieczeństwa.
Częste pytania
Czy moje centrum danych aktualizuje vServer automatycznie?
W przypadku niezarządzanych serwerów root i vServerów zwykle nie. Dostawca zapewnia sprzęt lub wirtualizację i sieć, a system operacyjny oraz wszystkie działające na nim usługi administrują Państwo sami. W razie wątpliwości proszę sprawdzić umowę.
Czy automatyczne aktualizacje bezpieczeństwa wystarczą?
Pomagają, ale nie zastępują kontroli. Automatyczne aktualizacje nie zawsze restartują działające procesy PHP i często nie obejmują pakietów z obcych źródeł. Po każdej aktualizacji bezpieczeństwa proszę sprawdzić stan pakietów i czasy startu procesów.
Jak sprawdzić, czy mój pakiet zawiera backport?
W dzienniku zmian pakietu i w komunikatach bezpieczeństwa Państwa dystrybucji. Jeśli widnieje tam numer CVE, poprawka jest zawarta, nawet gdy numer wersji wydaje się starszy. Jeśli wpisu brak, proszę wyjaśnić stan, zanim uzna się serwer za załatany.
Co zrobić, jeśli dla mojej wersji PHP nie pojawi się poprawka?
PHP 8.1 i starsze nie otrzymują już oficjalnych aktualizacji. Proszę wdrożyć środki przejściowe według php.net, szybko zaplanować przejście na obsługiwaną wersję i w razie potrzeby, zgodnie z zaleceniem BSI, czasowo odłączyć serwer od sieci.