Sådan sikrer I PHP under Windows og IIS

Kort sagt: Under Windows med IIS kører PHP som regel som php-cgi.exe via FastCGI, en driftsform, som PHP2Shell udtrykkeligt berører. En PHP IIS-opdatering består af tre trin: find alle PHP-installationer, udskift dem med en rettet version, og genbrug applikationspoolene. Pakkehåndtering og backports som under Linux findes her som regel ikke.

Hvordan PHP kører under IIS

På Windows-servere tilkobler IIS PHP via FastCGI-modulet. For hver PHP-version findes der en FastCGI-post, der peger på en php-cgi.exe, og en handler-tildeling, som leder filer med endelsen .php derhen. IIS starter efter behov flere php-cgi-processer og holder dem aktive til yderligere forespørgsler.

I modsætning til under Linux kommer PHP her som regel ikke fra en pakkehåndtering, men som ZIP-arkiv med PHP-projektets Windows-builds, som del af en fagapplikation eller via ældre installationsprogrammer. Det betyder: Opdateringer sker ikke automatisk, og der findes ingen backports fra en distributør. Afgørende er versionsnummeret på de installerede filer.

Hvad PHP2Shell betyder for Windows-servere

PHP2Shell omfatter CVE-2026-109618 og CVE-2026-109619 i PHP selv, hver med CVSS v4.0 9,2. Begge tillader kodeudførelse uden login. PHP-projektet nævner udtrykkeligt php-cgi blandt de berørte driftsformer. Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

For PHP 8.1 og ældre findes der ikke længere officielle opdateringer. Windows-servere med fagapplikationer kører erfaringsmæssigt ofte på sådanne versioner, fordi applikationen kræver en bestemt version. Her er der ud over de midlertidige foranstaltninger brug for en afklaring med applikationens producent. Baggrund om denne driftsform står under php-cgi: gammel arv med risiko.

PHP IIS-opdatering: find installationerne

Følgende PowerShell-kommandoer læser kun. De viser, hvilke PHP-installationer IIS bruger, og hvilken version de har. Stier er eksempler.

# FastCGI-poster i IIS: hvilken php-cgi.exe bruges?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Version for hver fundet installation (sti som eksempel)
& "C:\PHP\8.3\php.exe" -v

# Kørende php-cgi-processer med starttidspunkt
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Søg desuden på alle drev efter yderligere php-cgi.exe, for fagapplikationer medbringer nogle gange egne kopier. Notér for hver installation version, variant (Thread Safe eller Non Thread Safe) og arkitektur.

Indspil opdateringen og genbrug applikationspools

Hent den rettede version fra PHP-projektets officielle Windows-builds, der er linket fra php.net, i samme variant og arkitektur. Det har vist sig at fungere at pakke den nye version ud i en ny mappe, overtage den bestående php.ini og de nødvendige udvidelser og derefter omstille FastCGI-posten til den nye sti. Så bevares den gamle status som vej tilbage.

# Genbrug applikationspool (navn som eksempel)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Alternativt genstart alle IIS-tjenester
iisreset

# Kontrol: er alle php-cgi-processer startet efter opdateringen?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Hver php-cgi-proces skal have et starttidspunkt efter opdateringen og pege på den nye sti. Test derefter websites. Fjern den gamle PHP-mappe, så snart den nye status kører stabilt, så den ikke ved en fejl bliver koblet på igen.

Midlertidige foranstaltninger i php.ini

Kan en installation ikke opdateres med det samme, anbefaler php.net midlertidige foranstaltninger uden fuldstændig beskyttelse. Under IIS sætter I værdierne i den centrale php.ini for den pågældende installation. .user.ini-filer og ini_set() er ifølge php.net ikke tilstrækkelige.

; php.ini for den berørte installation
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Med upload-funktion angiver php.net post_max_size = 32M. På PHP 8.5 kommer fatal_error_backtraces=0 til. For at websites ikke ændrer værdierne via egne .user.ini-filer, kan user_ini.filename sættes tom i den centrale php.ini; kontrollér først, om applikationer er afhængige af den. Genbrug derefter poolene. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler at tage webservere midlertidigt af nettet, hvis opdateringen ikke kan gennemføres med det samme. Yderligere indstillinger forklarer Konfigurer php.ini sikkert.

Efter opdateringen

En patch fjerner ikke skadelig software, som blev smuglet ind tidligere. Gem IIS-protokollerne fra og med 20.10.2026, undersøg webmapper for nye scriptfiler, og kontrollér planlagte opgaver og lokale brugerkonti for ukendte poster. Kører serveren i et domæne, hører også et blik på logins med.

Vær desuden opmærksom på rettighederne for applikationspoolenes identiteter. Kører en pool med en konto, der har skriverettigheder til hele webmappen eller endda administrative rettigheder, kan en angriber efter et vellykket indbrud gøre betydeligt mere skade. Fornuftig er en egen, begrænset identitet pr. pool med skriverettigheder kun dér, hvor applikationen faktisk har brug for dem, f.eks. i upload- eller cache-mappen. I disse mapper bør IIS ikke udføre PHP-filer; det kan styres via handler-tildelingerne for den pågældende mappe. Kontrollér også, om gamle test- og installationsfiler som phpinfo-output ligger i webmappen, og fjern dem.

Hvordan hjælper PHP SOS konkret?

• Vi finder alle PHP-installationer på jeres Windows-servere, også kopier i fagapplikationer.
• Via PHP-patch-servicen udskifter vi PHP, genbruger poolene og dokumenterer version og proces-tidspunkter.
• Ved gamle versioner afklarer vi sammen med jer og applikationsproducenten vejen til migrering til en understøttet PHP-version.
• Vi undersøger serverne for spor af et angreb og sikrer protokollerne.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• php.net: Understøttede versioner
• BSI