# Säkra PHP under Windows och IIS

> PHP IIS-uppdatering efter PHP2Shell: hitta installationer under Windows, byt ut PHP-mappen, återvinn applikationspooler och sätt tillfälliga värden.

Källa: https://phpsos.de/sv/server/windows-iis-php/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Under Windows med IIS körs PHP oftast som `php-cgi.exe` via FastCGI, ett driftläge som PHP2Shell uttryckligen berör. En PHP IIS-uppdatering består av tre steg: hitta alla PHP-installationer, ersätta dem med en åtgärdad version och återvinna applikationspoolerna. Pakethantering och backports som under Linux finns här i regel inte.

## Hur PHP körs under IIS

På Windows-servrar kopplar IIS in PHP via FastCGI-modulen. För varje PHP-version finns en FastCGI-post som pekar på en `php-cgi.exe`, och en hanterartilldelning som leder filer med ändelsen `.php` dit. IIS startar vid behov flera php-cgi-processer och håller dem aktiva för ytterligare förfrågningar.

Till skillnad från under Linux kommer PHP här oftast inte från en pakethantering utan som ZIP-arkiv med Windows-byggen från PHP-projektet, som en del av en verksamhetsapplikation eller via äldre installationsprogram. Det betyder: uppdateringar sker inte automatiskt, och det finns inga backports från en distributör. Avgörande är versionsnumret på de installerade filerna.

## Vad PHP2Shell betyder för Windows-servrar

PHP2Shell omfattar CVE-2026-109618 och CVE-2026-109619 i PHP självt, vardera med CVSS v4.0 9,2. Båda möjliggör kodkörning utan inloggning. PHP-projektet nämner uttryckligen php-cgi bland de berörda driftlägena. Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35.

För PHP 8.1 och äldre finns inga officiella uppdateringar längre. Windows-servrar med verksamhetsapplikationer körs erfarenhetsmässigt ofta på sådana versioner, eftersom applikationen kräver en viss version. Här behövs vid sidan av de tillfälliga åtgärderna en avstämning med applikationens tillverkare. Bakgrund till det här driftläget finns under [php-cgi: ett arv med risk](https://phpsos.de/sv/server/php-cgi/).

## PHP IIS-uppdatering: hitta installationerna

Följande PowerShell-kommandon läser bara. De visar vilka PHP-installationer IIS använder och vilken version de har. Sökvägar är exempel.

```powershell
# FastCGI-poster i IIS: vilken php-cgi.exe används?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Version för varje hittad installation (sökväg som exempel)
& "C:\PHP\8.3\php.exe" -v

# Körande php-cgi-processer med starttid
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
```

Sök dessutom på alla enheter efter fler `php-cgi.exe`, eftersom verksamhetsapplikationer ibland har med egna kopior. Anteckna per installation version, variant (Thread Safe eller Non Thread Safe) och arkitektur.

## Installera uppdateringen och återvinn applikationspoolerna

Ladda ned den åtgärdade versionen från PHP-projektets officiella Windows-byggen som länkas från php.net, i samma variant och arkitektur. Det har visat sig fungera att packa upp den nya versionen i en ny mapp, ta över den befintliga php.ini och de tillägg som behövs och sedan ställa om FastCGI-posten till den nya sökvägen. Då finns den gamla versionen kvar för en återgång.

```powershell
# Återvinn applikationspool (namn som exempel)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Alternativt starta om alla IIS-tjänster
iisreset

# Kontroll: har alla php-cgi-processer startats efter uppdateringen?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
```

Varje php-cgi-process måste ha en starttid efter uppdateringen och peka på den nya sökvägen. Testa därefter webbplatserna. Ta bort den gamla PHP-mappen så snart den nya versionen körs stabilt, så att den inte av misstag kopplas in igen.

> **Viktigt:**
> Nya filer i PHP-mappen räcker inte så länge gamla php-cgi-processer körs. Först efter att poolerna har återvunnits eller IIS har startats om är patchen verksam.

## Tillfälliga åtgärder i php.ini

Kan en installation inte uppdateras direkt rekommenderar php.net tillfälliga åtgärder utan fullständigt skydd. Under IIS sätter ni värdena i den centrala php.ini för respektive installation. `.user.ini`-filer och `ini_set()` räcker enligt php.net inte.

```ini
; php.ini för den berörda installationen
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
```

Med uppladdningsfunktion anger php.net `post_max_size = 32M`. På PHP 8.5 tillkommer `fatal_error_backtraces=0`. För att webbplatser inte ska ändra värdena via egna `.user.ini`-filer kan `user_ini.filename` sättas tomt i den centrala php.ini; kontrollera först om applikationer är beroende av den. Återvinn därefter poolerna. BSI (den tyska förbundsmyndigheten för informationssäkerhet) rekommenderar att webbservrar tillfälligt tas offline om uppdateringen inte kan göras direkt. Fler inställningar förklaras under [Konfigurera php.ini säkert](https://phpsos.de/sv/ratgeber/php-ini-sicher-konfigurieren/).

## Efter uppdateringen

En patch tar inte bort skadlig programvara som fördes in tidigare. Spara IIS-loggarna från och med den 20 oktober 2026, kontrollera webbkatalogerna med avseende på nya skriptfiler och granska schemalagda uppgifter och lokala användarkonton med avseende på något okänt. Körs servern i en domän hör även en titt på inloggningar dit.

Var dessutom uppmärksamma på rättigheterna för applikationspoolernas identiteter. Körs en pool med ett konto som har skrivrättigheter till hela webbkatalogen eller till och med administrativa rättigheter kan en angripare efter ett lyckat intrång ställa till med betydligt mer. Meningsfullt är en egen, begränsad identitet per pool med skrivrättigheter bara där applikationen verkligen behöver dem, till exempel i uppladdnings- eller cachemappen. I de mapparna ska IIS inte köra några PHP-filer; det går att reglera via hanterartilldelningarna för respektive mapp. Kontrollera också om gamla test- och installationsfiler som phpinfo-utskrifter ligger i webbkatalogen, och ta bort dem.

## Hur hjälper PHP SOS konkret?

- Vi hittar alla PHP-installationer på era Windows-servrar, även kopior i verksamhetsapplikationer.
- Via [PHP-patchtjänsten](https://phpsos.de/sv/leistungen/php-patch-service/) byter vi ut PHP, återvinner poolerna och dokumenterar version och processtider.
- Vid gamla versioner klarar vi tillsammans med er och applikationens tillverkare ut vägen till [migrering till en PHP-version som stöds](https://phpsos.de/sv/leistungen/php-migration-legacy/).
- Vi kontrollerar servrarna med avseende på spår av ett angrepp och säkrar loggarna.


## Vanliga frågor

**Vilken PHP-variant behöver jag för IIS?**  
För IIS med FastCGI används vanligen varianten Non-Thread-Safe (NTS). Se vid uppdateringen till att välja samma variant och arkitektur igen, så att tilläggen fortfarande passar.

**Räcker det att packa upp den nya PHP-mappen?**  
Nej. IIS håller php-cgi.exe-processer aktiva en tid. Återvinn applikationspoolerna eller starta om IIS och kontrollera att inga gamla processer längre körs.

**Kan jag köra flera PHP-versioner på en IIS?**  
Ja, via flera FastCGI-poster och hanterartilldelningar per webbplats. Det ökar dock underhållsarbetet. Varje installation behöver en egen uppdatering och en egen kontroll.

**Berörs PHP under Windows av PHP2Shell?**  
Sårbarheterna finns i PHP självt. Under IIS körs PHP i regel som php-cgi, som PHP-projektet uttryckligen räknar till de berörda driftlägena. Behandla Windows-servrar lika brådskande som Linux-servrar.

## Källor

- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versioner som stöds](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)