Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

PHP unter Windows und IIS absichern

Unter IIS läuft PHP meist als php-cgi.exe über FastCGI. So finden Sie alle Installationen, tauschen PHP sicher aus, recyceln die Anwendungspools und prüfen das Ergebnis.

Stand 5 Min. LesezeitServer & Hosting

Kurz gesagt: Unter Windows mit IIS läuft PHP meist als php-cgi.exe über FastCGI, einer Betriebsart, die von PHP2Shell ausdrücklich betroffen ist. Ein PHP IIS Update besteht aus drei Schritten: alle PHP-Installationen finden, sie durch eine behobene Version ersetzen und die Anwendungspools recyceln. Paketverwaltung und Backports wie unter Linux gibt es hier in der Regel nicht.

Wie PHP unter IIS läuft

Auf Windows-Servern bindet IIS PHP über das FastCGI-Modul an. Für jede PHP-Version gibt es einen FastCGI-Eintrag, der auf eine php-cgi.exe zeigt, und eine Handler-Zuordnung, die Dateien mit der Endung .php dorthin leitet. IIS startet bei Bedarf mehrere php-cgi-Prozesse und hält sie für weitere Anfragen aktiv.

Anders als unter Linux kommt PHP hier meist nicht aus einer Paketverwaltung, sondern als ZIP-Archiv der Windows-Builds des PHP-Projekts, als Teil einer Fachanwendung oder über ältere Installer. Das bedeutet: Updates passieren nicht automatisch, und es gibt keine Backports eines Distributors. Maßgeblich ist die Versionsnummer der installierten Dateien.

Was PHP2Shell für Windows-Server bedeutet

PHP2Shell umfasst CVE-2026-109618 und CVE-2026-109619 in PHP selbst, jeweils mit CVSS v4.0 9.2. Beide erlauben Codeausführung ohne Anmeldung. Das PHP-Projekt nennt php-cgi ausdrücklich unter den betroffenen Betriebsarten. Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr. Windows-Server mit Fachanwendungen laufen erfahrungsgemäß oft auf solchen Ständen, weil die Anwendung eine bestimmte Version verlangt. Hier ist neben den Übergangsmaßnahmen eine Klärung mit dem Hersteller der Anwendung nötig. Hintergrund zu dieser Betriebsart steht unter php-cgi: Altlast mit Risiko.

PHP IIS Update: Installationen finden

Die folgenden PowerShell-Befehle lesen nur. Sie zeigen, welche PHP-Installationen IIS nutzt und welche Version sie haben. Pfade sind Beispiele.

# FastCGI-Einträge in IIS: welche php-cgi.exe wird genutzt?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Version jeder gefundenen Installation (Pfad als Beispiel)
& "C:\PHP\8.3\php.exe" -v

# Laufende php-cgi-Prozesse mit Startzeit
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Suchen Sie zusätzlich auf allen Laufwerken nach weiteren php-cgi.exe, denn Fachanwendungen bringen manchmal eigene Kopien mit. Notieren Sie je Installation Version, Variante (Thread Safe oder Non Thread Safe) und Architektur.

Update einspielen und Anwendungspools recyceln

Laden Sie die behobene Version von den offiziellen Windows-Builds des PHP-Projekts, die von php.net aus verlinkt sind, in derselben Variante und Architektur. Bewährt hat sich, die neue Version in einen neuen Ordner zu entpacken, die bestehende php.ini und die benötigten Erweiterungen zu übernehmen und dann den FastCGI-Eintrag auf den neuen Pfad umzustellen. So bleibt der alte Stand für einen Rückweg erhalten.

# Anwendungspool recyceln (Name als Beispiel)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Alternativ alle IIS-Dienste neu starten
iisreset

# Kontrolle: alle php-cgi-Prozesse nach dem Update gestartet?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Jeder php-cgi-Prozess muss eine Startzeit nach dem Update haben und auf den neuen Pfad zeigen. Testen Sie danach die Websites. Entfernen Sie den alten PHP-Ordner, sobald der neue Stand stabil läuft, damit er nicht versehentlich wieder eingebunden wird.

Wichtig

Neue Dateien im PHP-Ordner reichen nicht, solange alte php-cgi-Prozesse laufen. Erst nach dem Recyceln der Pools oder einem IIS-Neustart ist der Patch wirksam.

Übergangsmaßnahmen in der php.ini

Kann eine Installation nicht sofort aktualisiert werden, empfiehlt php.net Übergangsmaßnahmen ohne vollständigen Schutz. Unter IIS setzen Sie die Werte in der zentralen php.ini der jeweiligen Installation. .user.ini-Dateien und ini_set() genügen laut php.net nicht.

; php.ini der betroffenen Installation
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Mit Upload-Funktion nennt php.net post_max_size = 32M. Auf PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Damit Websites die Werte nicht über eigene .user.ini-Dateien verändern, kann user_ini.filename in der zentralen php.ini leer gesetzt werden; prüfen Sie vorher, ob Anwendungen darauf angewiesen sind. Danach die Pools recyceln. Das BSI empfiehlt, Webserver vorübergehend vom Netz zu nehmen, wenn das Update nicht sofort möglich ist. Weitere Einstellungen erklärt php.ini sicher konfigurieren.

Nach dem Update

Ein Patch entfernt keine Schadsoftware, die vorher eingeschleust wurde. Bewahren Sie die IIS-Protokolle ab dem 20.10.2026 auf, prüfen Sie Web-Verzeichnisse auf neue Skriptdateien und kontrollieren Sie geplante Aufgaben und lokale Benutzerkonten auf Unbekanntes. Läuft der Server in einer Domäne, gehört auch ein Blick auf Anmeldungen dazu.

Achten Sie zusätzlich auf die Rechte der Anwendungspool-Identitäten. Läuft ein Pool mit einem Konto, das Schreibrechte auf das gesamte Web-Verzeichnis oder gar administrative Rechte besitzt, kann ein Angreifer nach einem erfolgreichen Einbruch deutlich mehr anrichten. Sinnvoll ist eine eigene, eingeschränkte Identität je Pool mit Schreibrechten nur dort, wo die Anwendung sie tatsächlich braucht, etwa im Upload- oder Cache-Ordner. In diesen Ordnern sollte IIS keine PHP-Dateien ausführen; das lässt sich über die Handler-Zuordnungen des jeweiligen Ordners regeln. Prüfen Sie auch, ob alte Test- und Installationsdateien wie phpinfo-Ausgaben im Web-Verzeichnis liegen, und entfernen Sie sie.

Wie hilft PHP SOS konkret?

  • Wir finden alle PHP-Installationen auf Ihren Windows-Servern, auch Kopien in Fachanwendungen.
  • Über den PHP-Patch-Service tauschen wir PHP aus, recyceln die Pools und dokumentieren Version und Prozesszeiten.
  • Bei alten Versionen klären wir mit Ihnen und dem Anwendungshersteller den Weg zur Migration auf eine unterstützte PHP-Version.
  • Wir prüfen die Server auf Spuren eines Angriffs und sichern die Protokolle.

Häufige Fragen

Welche PHP-Variante brauche ich für IIS?

Für IIS mit FastCGI wird üblicherweise die Non-Thread-Safe-Variante (NTS) verwendet. Achten Sie beim Update darauf, wieder dieselbe Variante und Architektur zu wählen, damit Erweiterungen weiter passen.

Reicht es, den neuen PHP-Ordner zu entpacken?

Nein. IIS hält php-cgi.exe-Prozesse eine Zeit lang aktiv. Recyceln Sie die Anwendungspools oder starten Sie IIS neu und prüfen Sie, dass keine alten Prozesse mehr laufen.

Kann ich mehrere PHP-Versionen auf einem IIS betreiben?

Ja, über mehrere FastCGI-Einträge und Handler-Zuordnungen je Website. Das erhöht aber den Pflegeaufwand. Jede Installation braucht ein eigenes Update und eine eigene Kontrolle.

Ist PHP unter Windows von PHP2Shell betroffen?

Die Lücken liegen in PHP selbst. Unter IIS läuft PHP in der Regel als php-cgi, das das PHP-Projekt ausdrücklich zu den betroffenen Betriebsarten zählt. Behandeln Sie Windows-Server daher genauso dringend wie Linux-Server.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe