Zaščita PHP v sistemu Windows in IIS

Na kratko: V sistemu Windows z IIS PHP večinoma teče kot php-cgi.exe prek FastCGI, kar je način delovanja, ki ga PHP2Shell izrecno zadeva. Posodobitev PHP v IIS sestoji iz treh korakov: poiščite vse namestitve PHP, jih nadomestite z odpravljeno različico in reciklirajte skupine aplikacij. Upravljanja paketov in backportov kot v Linuxu tu praviloma ni.

Kako PHP teče v IIS

Na strežnikih Windows IIS PHP poveže prek modula FastCGI. Za vsako različico PHP obstaja vnos FastCGI, ki kaže na php-cgi.exe, in dodelitev handlerja, ki datoteke s končnico .php usmeri tja. IIS po potrebi zažene več procesov php-cgi in jih ohranja aktivne za nadaljnje zahteve.

V nasprotju z Linuxom PHP tu večinoma ne prihaja iz upravitelja paketov, temveč kot arhiv ZIP gradenj projekta PHP za Windows, kot del strokovne aplikacije ali prek starejših namestitvenih programov. To pomeni: posodobitve se ne zgodijo samodejno in backportov distributerja ni. Odločilna je številka različice nameščenih datotek.

Kaj PHP2Shell pomeni za strežnike Windows

PHP2Shell obsega CVE-2026-109618 in CVE-2026-109619 v samem PHP, vsaka s CVSS v4.0 9,2. Obe omogočata izvajanje kode brez prijave. Projekt PHP php-cgi izrecno navaja med prizadetimi načini delovanja. Odpravljeni so PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35.

Za PHP 8.1 in starejše uradnih posodobitev ni več. Strežniki Windows s strokovnimi aplikacijami po izkušnjah pogosto tečejo na takih stanjih, ker aplikacija zahteva določeno različico. Tu je poleg vmesnih ukrepov potrebna razjasnitev s proizvajalcem aplikacije. Ozadje tega načina delovanja je na strani php-cgi: staro breme s tveganjem.

Posodobitev PHP v IIS: poiščite namestitve

Spodnji ukazi PowerShell samo berejo. Pokažejo, katere namestitve PHP uporablja IIS in katero različico imajo. Poti so primeri.

# Vnosi FastCGI v IIS: katera php-cgi.exe se uporablja?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Različica vsake najdene namestitve (pot kot primer)
& "C:\PHP\8.3\php.exe" -v

# Delujoči procesi php-cgi s časom zagona
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Dodatno na vseh pogonih poiščite druge datoteke php-cgi.exe, ker strokovne aplikacije včasih prinesejo lastne kopije. Za vsako namestitev zapišite različico, varianto (Thread Safe ali Non Thread Safe) in arhitekturo.

Namestite posodobitev in reciklirajte skupine aplikacij

Odpravljeno različico prenesite iz uradnih gradenj za Windows projekta PHP, ki so povezane s strani php.net, v isti varianti in arhitekturi. Obneslo se je, da novo različico razpakirate v nov imenik, prevzamete obstoječo php.ini in potrebne razširitve ter nato vnos FastCGI preusmerite na novo pot. Tako staro stanje ostane za pot nazaj.

# Reciklirajte skupino aplikacij (ime kot primer)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Druga možnost: znova zaženite vse storitve IIS
iisreset

# Kontrola: ali so vsi procesi php-cgi zagnani po posodobitvi?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Vsak proces php-cgi mora imeti čas zagona po posodobitvi in kazati na novo pot. Nato preizkusite spletne strani. Stari imenik PHP odstranite, ko novo stanje stabilno teče, da se ne bi pomotoma znova vključil.

Vmesni ukrepi v php.ini

Če namestitve ni mogoče takoj posodobiti, php.net priporoča vmesne ukrepe brez popolne zaščite. V IIS vrednosti nastavite v osrednji php.ini posamezne namestitve. Datoteke .user.ini in ini_set() po navedbah php.net ne zadoščajo.

; php.ini prizadete namestitve
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

S funkcijo nalaganja datotek php.net navaja post_max_size = 32M. Pri PHP 8.5 se doda fatal_error_backtraces=0. Da spletne strani vrednosti ne spreminjajo prek lastnih datotek .user.ini, lahko user_ini.filename v osrednji php.ini pustite prazen; prej preverite, ali se aplikacije nanj zanašajo. Nato reciklirajte skupine. BSI priporoča, da spletne strežnike začasno odklopite z omrežja, če posodobitev ni takoj mogoča. Dodatne nastavitve pojasnjuje stran Varna konfiguracija php.ini.

Po posodobitvi

Popravek ne odstrani škodljive programske opreme, ki je bila vnesena prej. Zapisnike IIS hranite od 20. 10. 2026 naprej, spletne imenike preverite glede novih skriptnih datotek ter načrtovana opravila in lokalne uporabniške račune preglejte glede neznanega. Če strežnik teče v domeni, sodi zraven tudi pogled na prijave.

Dodatno bodite pozorni na pravice identitet skupin aplikacij. Če skupina teče z računom, ki ima pravice pisanja na celoten spletni imenik ali celo skrbniške pravice, lahko napadalec po uspešnem vdoru stori bistveno več škode. Smiselna je lastna, omejena identiteta za vsako skupino s pravicami pisanja samo tam, kjer jih aplikacija res potrebuje, na primer v imeniku za nalaganje ali predpomnilnik. V teh imenikih IIS ne sme izvajati datotek PHP; to je mogoče urediti prek dodelitev handlerjev posameznega imenika. Preverite tudi, ali v spletnem imeniku ležijo stare preskusne in namestitvene datoteke, kot so izpisi phpinfo, in jih odstranite.

Kako PHP SOS konkretno pomaga?

• Poiščemo vse namestitve PHP na vaših strežnikih Windows, tudi kopije v strokovnih aplikacijah.
• Prek storitve popravljanja PHP zamenjamo PHP, reciklirimo skupine in dokumentiramo različico ter čase procesov.
• Pri starih različicah z vami in proizvajalcem aplikacije razjasnimo pot do migracije na podprto različico PHP.
• Strežnike preverimo glede sledi napada in zavarujemo zapisnike.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• php.net: podprte različice
• BSI (nemški zvezni urad za informacijsko varnost)