Zabezpieczenie PHP w Windows i IIS

Krótko: W Windows z IIS PHP działa zwykle jako php-cgi.exe przez FastCGI, czyli w trybie pracy wprost dotkniętym przez PHP2Shell. Aktualizacja PHP w IIS składa się z trzech kroków: znaleźć wszystkie instalacje PHP, zastąpić je wersją z usuniętą luką i zrecyklować pule aplikacji. Menedżera pakietów i backportów jak w Linuksie tu zazwyczaj nie ma.

Jak PHP działa w IIS

Na serwerach Windows IIS łączy PHP przez moduł FastCGI. Dla każdej wersji PHP istnieje wpis FastCGI wskazujący na php-cgi.exe oraz przypisanie handlera, które kieruje tam pliki z rozszerzeniem .php. IIS w razie potrzeby uruchamia kilka procesów php-cgi i utrzymuje je aktywne dla kolejnych żądań.

Inaczej niż w Linuksie PHP zwykle nie pochodzi tu z menedżera pakietów, lecz z archiwum ZIP z kompilacjami Windows projektu PHP, jako część aplikacji branżowej albo ze starszych instalatorów. Oznacza to: aktualizacje nie przebiegają automatycznie i nie ma backportów dystrybutora. Rozstrzyga numer wersji zainstalowanych plików.

Co PHP2Shell oznacza dla serwerów Windows

PHP2Shell obejmuje CVE-2026-109618 i CVE-2026-109619 w samym PHP, każdą z oceną CVSS v4.0 9.2. Obie umożliwiają wykonanie kodu bez logowania. Projekt PHP wprost wymienia php-cgi wśród dotkniętych trybów pracy. Usunięte są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji. Serwery Windows z aplikacjami branżowymi działają z doświadczenia często na takich wersjach, ponieważ aplikacja wymaga określonej wersji. Tu oprócz środków przejściowych potrzebne jest uzgodnienie z producentem aplikacji. Tło dotyczące tego trybu pracy podaje artykuł php-cgi: stare obciążenie z ryzykiem.

Aktualizacja PHP w IIS: znalezienie instalacji

Poniższe polecenia PowerShell tylko odczytują. Pokazują, jakich instalacji PHP używa IIS i jaką mają wersję. Ścieżki to przykłady.

# Wpisy FastCGI w IIS: jakiego php-cgi.exe się używa?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Wersja każdej znalezionej instalacji (ścieżka jako przykład)
& "C:\PHP\8.3\php.exe" -v

# Działające procesy php-cgi z czasem startu
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Proszę dodatkowo przeszukać wszystkie dyski w poszukiwaniu innych php-cgi.exe, bo aplikacje branżowe czasem przynoszą własne kopie. Dla każdej instalacji proszę zanotować wersję, wariant (Thread Safe lub Non Thread Safe) i architekturę.

Instalacja aktualizacji i recykling pul aplikacji

Proszę pobrać wersję z usuniętą luką z oficjalnych kompilacji Windows projektu PHP, linkowanych z php.net, w tym samym wariancie i tej samej architekturze. Sprawdziło się rozpakowanie nowej wersji do nowego folderu, przejęcie istniejącego php.ini i potrzebnych rozszerzeń, a następnie przełączenie wpisu FastCGI na nową ścieżkę. W ten sposób stary stan zostaje na wypadek powrotu.

# Recykling puli aplikacji (nazwa jako przykład)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Alternatywnie zrestartować wszystkie usługi IIS
iisreset

# Kontrola: czy wszystkie procesy php-cgi wystartowały po aktualizacji?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Każdy proces php-cgi musi mieć czas startu późniejszy niż aktualizacja i wskazywać na nową ścieżkę. Potem proszę przetestować strony. Stary folder PHP proszę usunąć, gdy nowy stan będzie działał stabilnie, aby nie został przypadkowo ponownie włączony.

Środki przejściowe w php.ini

Jeśli instalacji nie można zaktualizować od razu, php.net zaleca środki przejściowe bez pełnej ochrony. W IIS wartości ustawia się w centralnym php.ini danej instalacji. Pliki .user.ini i ini_set() według php.net nie wystarczają.

; php.ini dotkniętej instalacji
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Przy funkcji uploadu php.net podaje post_max_size = 32M. W PHP 8.5 dochodzi fatal_error_backtraces=0. Aby strony nie zmieniały wartości przez własne pliki .user.ini, można w centralnym php.ini ustawić user_ini.filename na pusty; proszę wcześniej sprawdzić, czy aplikacje na tym nie polegają. Potem zrecyklować pule. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca czasowe odłączenie serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu. Dalsze ustawienia wyjaśnia artykuł Bezpieczna konfiguracja php.ini.

Po aktualizacji

Poprawka nie usuwa szkodliwego oprogramowania wprowadzonego wcześniej. Proszę zachować logi IIS od 20.10.2026, sprawdzić katalogi WWW pod kątem nowych plików skryptów oraz skontrolować zadania harmonogramu i lokalne konta użytkowników pod kątem nieznanych. Jeśli serwer działa w domenie, należy też spojrzeć na logowania.

Proszę zwrócić uwagę także na uprawnienia tożsamości pul aplikacji. Jeśli pula działa z kontem, które ma prawa zapisu do całego katalogu WWW albo nawet uprawnienia administracyjne, atakujący po udanym włamaniu może zdziałać znacznie więcej. Sensowna jest osobna, ograniczona tożsamość dla każdej puli z prawami zapisu tylko tam, gdzie aplikacja naprawdę ich potrzebuje, na przykład w folderze uploadu lub cache. W tych folderach IIS nie powinien wykonywać plików PHP; można to uregulować przez przypisania handlerów danego folderu. Proszę sprawdzić także, czy w katalogu WWW nie leżą stare pliki testowe i instalacyjne, takie jak wyniki phpinfo, i je usunąć.

Jak konkretnie pomaga PHP SOS?

• Znajdujemy wszystkie instalacje PHP na Państwa serwerach Windows, także kopie w aplikacjach branżowych.
• Przez usługę aktualizacji PHP wymieniamy PHP, recyklujemy pule i dokumentujemy wersję oraz czasy procesów.
• Przy starych wersjach ustalamy z Państwem i producentem aplikacji drogę do migracji na obsługiwaną wersję PHP.
• Sprawdzamy serwery pod kątem śladów ataku i zabezpieczamy logi.

Częste pytania

Źródła

• php.net: komunikaty bezpieczeństwa
• PHP 8 ChangeLog
• php.net: obsługiwane wersje
• BSI