Ein Windows-PC ist nur dann unmittelbar von den kritischen PHP-Sicherheitslücken betroffen, wenn darauf PHP selbst läuft – etwa über XAMPP, IIS, einen lokalen Entwicklungsserver, Docker Desktop oder eine separat installierte Laufzeitumgebung. Der Besuch einer gewöhnlichen PHP-Webseite installiert kein PHP auf deinem PC. Betreibst du jedoch eine verwundbare PHP-Instanz, bietet nur der Wechsel auf eine vom PHP-Projekt korrigierte Version vollständigen Schutz; Änderungen an der Konfiguration können das Risiko lediglich vorübergehend verringern.
Besondere Dringlichkeit besteht, wenn der PHP-Webserver aus dem Internet oder aus einem nicht vertrauenswürdigen Netzwerk erreichbar ist. Prüfe zuerst, welche PHP-Version tatsächlich ausgeführt wird, woher sie stammt und ob mehrere Installationen parallel vorhanden sind. Sichere danach Konfiguration und Anwendungsdaten, installiere das passende Update und kontrolliere abschließend, ob Webserver, Kommandozeile und Container wirklich die neue Laufzeit verwenden.
Was hinter den als php2shell bezeichneten Schwachstellen steckt
Die beiden unter den Kennungen CVE-2026-109618 und CVE-2026-109619 geführten Fehler betreffen unterschiedliche Bereiche der PHP-Laufzeit. Der erste Fehler liegt in der Speicherverwaltung und kann unter bestimmten Voraussetzungen ausgelöst werden, wenn das mit memory_limit festgelegte Speicherlimit erreicht wird. Präparierte Uploads oder stark verschachtelte Datenstrukturen können dabei einen fehlerhaften Aufräumvorgang provozieren.
Der zweite Fehler betrifft die Behandlung schwerwiegender Skriptfehler. Ein Angreifer benötigt dafür mehrere passend aufeinander abgestimmte HTTP-Anfragen: Eine Anfrage versetzt die Fehlerverwaltung in einen instabilen Zustand, eine weitere versucht diesen Zustand auszunutzen. Nicht jeder PHP-Fehler genügt dafür, und ein Angriff muss unter Umständen sehr viele Anfragen senden. Das ist dennoch kein verlässlicher Schutz, weil sich solche Versuche automatisieren lassen.
Eine erfolgreiche Ausnutzung kann zur Ausführung fremden Codes mit den Rechten des Webserverprozesses führen. Diese Rechte entscheiden über das mögliche Schadensausmaß. Läuft der Dienst mit einem stark eingeschränkten Konto, ist der erste Zugriff begrenzt. Ein unnötig privilegierter Dienst, beschreibbare Anwendungsverzeichnisse oder erreichbare Zugangsdaten erhöhen dagegen das Risiko.
Betroffen sein können mehrere PHP-Anbindungen, darunter Apache mit mod_php, PHP-FPM und LSAPI. Auch ein PHP-Webserver unter Windows ist nicht allein wegen des Betriebssystems geschützt. Alte PHP-Versionen und eingebettete Laufzeiten in Containern, Entwicklungsstapeln oder Geräten müssen getrennt betrachtet werden.
Zuerst klären: Läuft PHP überhaupt auf deinem Windows-PC?
Eine installierte Webbrowser-Anwendung oder der Besuch einer mit PHP erstellten Internetseite bedeutet nicht, dass dein PC PHP ausführt. PHP verarbeitet den Programmcode normalerweise auf dem Server; der Browser erhält nur die daraus erzeugte Antwort. Relevant wird das Problem auf einem Windows-PC vor allem in diesen Situationen:
- Du entwickelst Webseiten lokal und nutzt XAMPP, Wampserver, Laragon oder einen ähnlichen Komplettstapel.
- Du hast PHP separat entpackt und den Ordner in die Windows-Umgebungsvariable
PATHaufgenommen. - IIS, Apache, Nginx oder ein anderes Serverprogramm bindet PHP ein.
- Eine Anwendung bringt eine eigene PHP-Laufzeit mit.
- Docker Desktop startet Container mit einem PHP-Basisimage.
- Eine virtuelle Maschine oder WSL-Distribution betreibt einen eigenen Webserver.
Jede dieser Umgebungen verwaltet PHP anders. Ein Update der Windows-Kommandozeilenversion ersetzt beispielsweise nicht automatisch die PHP-Dateien eines XAMPP-Pakets. Ebenso aktualisiert Windows Update keine manuell entpackte PHP-Laufzeit und kein PHP in einem Docker-Image.
Aktive PHP-Version und Installationspfad ermitteln
Öffne Windows Terminal, PowerShell oder die Eingabeaufforderung und frage zunächst die Version ab. Der Befehl liest nur Informationen aus und verändert das System nicht.
php -vErscheint eine Versionsausgabe, ist mindestens eine PHP-Kommandozeilenversion über den Suchpfad erreichbar. Die Ausgabe php is not recognized beziehungsweise eine entsprechende deutsche Meldung bedeutet lediglich, dass Windows an dieser Stelle kein php.exe findet. Ein Webserver kann trotzdem eine andere, direkt konfigurierte PHP-Datei verwenden.
Mit folgendem PowerShell-Befehl siehst du, welche ausführbaren PHP-Dateien PowerShell über die vorhandenen Suchpfade findet:
Get-Command php -AllFühre ergänzend diesen Befehl aus, um die geladenen Konfigurationsdateien der gefundenen Kommandozeilenversion zu bestimmen:
php --iniDie Zeile Loaded Configuration File nennt die verwendete php.ini. Wird dort kein Pfad angezeigt, arbeitet diese PHP-Instanz möglicherweise ohne geladene Hauptkonfiguration. Das Ergebnis gilt zunächst nur für die Kommandozeile. Ein Webserver kann eine andere Konfiguration und sogar eine andere PHP-Version laden.
Webserver und Kommandozeile getrennt kontrollieren
Bei einem lokalen Entwicklungsstapel sollte dessen Verwaltungsoberfläche die laufenden Komponenten und häufig auch den PHP-Zweig anzeigen. Für IIS prüfst du die FastCGI- beziehungsweise Handler-Zuordnung und den dort hinterlegten Pfad zur php-cgi.exe. Bei Apache ist die Serverkonfiguration maßgeblich, bei PHP-FPM die tatsächlich gestartete FPM-Instanz.
Verlasse dich nicht allein auf eine ältere phpinfo()-Datei im Webverzeichnis. Sie kann zwar die vom Webserver geladene Version und Konfiguration offenlegen, gibt aber zugleich zahlreiche Systemdetails preis. Falls du eine solche Diagnose lokal anlegst, rufe sie nur über eine nicht öffentlich erreichbare Adresse auf und lösche die Datei unmittelbar nach der Prüfung.
Mehrere PHP-Kopien richtig einordnen
Findet Get-Command php -All mehrere Dateien, notiere für jede Installation den Pfad und ihren Zweck. Starte die jeweilige Datei über ihren vollständigen Pfad mit dem Parameter -v, statt nur die zuerst gefundene Version zu prüfen. Entscheidend ist nicht die höchste vorhandene Versionsnummer, sondern die Version, die der erreichbare Webserver wirklich verwendet.
Durchsuche außerdem die Einstellungen deiner Entwicklungswerkzeuge. Composer verwendet normalerweise die PHP-Version, mit der er aufgerufen wird. Eine IDE kann wiederum einen eigenen Interpreterpfad besitzen. Diese Abweichungen erklären, warum die Kommandozeile bereits aktualisiert erscheint, während die Webanwendung noch mit einer älteren Laufzeit startet.
Die richtige Aktualisierungsroute wählen
Der Updateweg hängt von der Herkunft deiner PHP-Installation ab. Sichere vor dem Austausch mindestens die Anwendungsdateien, Datenbanken, Webserverkonfiguration und php.ini. Kopiere die alte Konfiguration nicht ungeprüft über eine neue Standarddatei, weil Erweiterungen und Direktiven zwischen PHP-Zweigen geändert oder entfernt werden können.
- Separat installiertes PHP: Ermittle Architektur, Thread-Safety-Variante und Webserveranbindung. Lade eine korrigierte, unterstützte Ausgabe aus dem offiziellen Downloadbereich des PHP-Projekts und vergleiche die Sicherheitsankündigungen für deinen Versionszweig. Tausche die Laufzeit nach den Hinweisen des Projekts aus, übernimm nur benötigte Einstellungen und starte den Webserver neu.
- XAMPP, Wampserver oder Laragon: Nutze bevorzugt den dokumentierten Updateweg des jeweiligen Pakets. Ein manueller Austausch einzelner DLL- und PHP-Dateien kann an inkompatiblen Apache-Modulen, Erweiterungen oder Laufzeitbibliotheken scheitern. Ist kein Sicherheitsupdate für das Paket verfügbar, sollte der betreffende Webserver bis zur Migration nicht von außen erreichbar sein.
- IIS mit FastCGI: Installiere die passende korrigierte Windows-Ausgabe und aktualisiere die Zuordnung zur richtigen
php-cgi.exe. Kontrolliere danach sowohl die IIS-Konfiguration als auch die vom Webserver gemeldete PHP-Version. - Docker Desktop: Prüfe das im Dockerfile oder in der Compose-Datei angegebene PHP-Image. Ein Neustart des alten Containers reicht nicht, weil dessen Dateisystem weiterhin die verwundbare Laufzeit enthalten kann. Ziehe das korrigierte Image, baue eigene Images neu und ersetze anschließend die laufenden Container.
- WSL oder virtuelle Maschine: Aktualisiere PHP innerhalb des jeweiligen Linux- oder Gastsystems über dessen Paketverwaltung. Ein Update der Windows-Installation hat keinen Einfluss auf die PHP-Pakete im Gast.
PHP 5 und andere nicht mehr unterstützte Hauptzweige sollten nicht nur mit einem einzelnen zurückportierten Patch weiterbetrieben werden. Eine Anwendung auf einen unterstützten PHP-Zweig zu migrieren reduziert die Gefahr, dass die nächste Schwachstelle ohne reguläres Update bleibt. Ob eine Anwendung mit einem neueren Zweig funktioniert, muss in einer getrennten Testumgebung geprüft werden.
Warum eine Konfigurationsänderung das Update nicht ersetzt
Für die beschriebenen Fehler existieren Einstellungen, die einzelne Angriffswege erschweren können. Dazu gehören ein im Verhältnis zu memory_limit begrenztes post_max_size, eine niedrige Grenze für verschachtelte Eingabedaten, das Abschalten des Sitzungs-Uploadfortschritts sowie kürzere Lebenszeiten von PHP-FPM-Prozessen. Auch das Deaktivieren ausführlicher Fehlerausgaben und die Beschränkung des Webserverkontos verringern verwertbare Informationen oder mögliche Folgeschäden.
Solche Eingriffe können Uploads, Formulare, Frameworks oder die Leistung der Anwendung beeinträchtigen. Werte dürfen daher nicht blind in eine fremde php.ini übernommen werden. Prüfe zuerst, welche Direktiven die Anwendung benötigt, ändere jeweils nur einen abgegrenzten Bereich und teste Anmeldung, Datei-Upload, Formularverarbeitung, Hintergrundaufgaben und Fehlerprotokollierung.
expose_php=0 verbirgt außerdem nur einen Teil der sichtbaren PHP-Kennung. Die Laufzeit wird dadurch weder aktualisiert noch gegen eine direkte Ausnutzung immun. Eine Web Application Firewall kann bekannte Anfragemuster blockieren, deckt aber unbekannte Varianten oder interne Angriffe nicht zuverlässig ab. Beide Maßnahmen sind Ergänzungen, keine Reparatur der betroffenen Speicher- und Fehlerverwaltung.
Windows-Firewall und Dienstkonto als zweite Schutzschicht
Ein Entwicklungsserver sollte gewöhnlich nur über die lokale Adresse erreichbar sein. Prüfe, ob Apache, Nginx, IIS Express, der eingebaute PHP-Server oder ein Container an alle Netzwerkschnittstellen gebunden wurde. Eine Bindung an 0.0.0.0 kann den Dienst je nach Firewallregel auch anderen Geräten zugänglich machen; 127.0.0.1 beschränkt IPv4-Verbindungen auf den lokalen Rechner.
Kontrolliere in der Windows Defender Firewall mit erweiterter Sicherheit eingehende Regeln für den Webserver und die zugehörigen Ports. Entferne keine Regel auf Verdacht. Prüfe zuerst Programm, Profil, lokale Ports und erlaubte Remoteadressen. Muss ein Testserver im Heim- oder Firmennetz erreichbar sein, begrenze die Freigabe auf das benötigte Netzwerkprofil und möglichst auf festgelegte Gegenstellen.
Der Webserverprozess sollte nicht unter einem Administratorkonto laufen. Er benötigt nur Leserechte auf unveränderliche Programmdateien und gezielte Schreibrechte auf Upload-, Cache- oder Protokollverzeichnisse. Zugangsdaten gehören nicht in öffentlich erreichbare Dateien. Ein eingeschränktes Dienstkonto verhindert die Sicherheitslücke nicht, kann aber begrenzen, welche Dateien und Systembereiche nach einer Codeausführung erreichbar sind.
Nach dem Update prüfen, ob wirklich die neue Version läuft
Eine abgeschlossene Installation ist noch keine Erfolgskontrolle. Starte den betroffenen Webserver oder Container neu und prüfe danach alle tatsächlich genutzten Laufzeiten.
php -vmuss in der Kommandozeile die erwartete korrigierte Version anzeigen.- Die Webserverdiagnose muss denselben sicheren Stand oder den vorgesehenen separaten PHP-Zweig melden.
php --inimuss auf die beabsichtigte Konfiguration verweisen.- Webserver- und PHP-Protokolle dürfen keine Ladefehler für Erweiterungen oder Konfigurationsdirektiven enthalten.
- Anmeldung, Formularverarbeitung, Uploads, Datenbankzugriff und geplante Aufgaben müssen weiterhin funktionieren.
- Alte Container oder zuvor gestartete Serverprozesse dürfen nicht parallel weiterlaufen.
Vergleiche die angezeigte Versionsnummer mit der Sicherheitsrubrik und den Veröffentlichungsinformationen des PHP-Projekts. Nur dort lässt sich für den verwendeten Versionszweig verlässlich feststellen, ab welcher Ausgabe die beiden CVE-Kennungen behoben sind. Eine lediglich höhere Nummer aus einem anderen, ebenfalls ungepatchten Zweig ist keine ausreichende Bestätigung.
Wenn kein Update sofort installiert werden kann
Ist eine Anwendung noch nicht mit einer korrigierten PHP-Version kompatibel, sollte die verwundbare Instanz nicht unverändert erreichbar bleiben. Schalte eine unnötige Portweiterleitung am Router aus, begrenze den Zugriff per Firewall oder nimm den Dienst vorübergehend vom Netz. Bei internen Anwendungen kann ein Zugriff ausschließlich über ein abgesichertes Verwaltungsnetz oder VPN die Angriffsfläche reduzieren, beseitigt den Fehler aber nicht.
Erstelle für die Migration eine getrennte Kopie der Anwendung, aktualisiere dort zuerst PHP und untersuche Fehlermeldungen, Erweiterungen sowie Abhängigkeiten. Falls ein Komplettpaket keine geeignete Aktualisierung anbietet, ist der Wechsel auf eine gepflegte Ausgabe des Pakets oder auf eine sauber dokumentierte Einzelinstallation sicherer als das Vermischen beliebiger Binärdateien.
Ein Abbruch ist sinnvoll, wenn du den verwendeten PHP-Pfad nicht eindeutig bestimmen kannst, die Anwendung geschäftskritisch ist oder ein Update Datenbankmigrationen und nicht dokumentierte Erweiterungen berührt. In diesem Fall sollte die Instanz zunächst isoliert und anschließend durch den zuständigen Administrator oder Anwendungsanbieter aktualisiert werden.
Häufige Fragen zu PHP-Sicherheitslücken unter Windows
Kann Microsoft Defender eine Ausnutzung der PHP-Fehler verhindern?
Microsoft Defender kann bekannte Schadprogramme, verdächtige Dateien oder bestimmte Folgeaktivitäten erkennen. Er repariert jedoch keinen Fehler innerhalb der PHP-Laufzeit und kann eine speicherbasierte Codeausführung nicht verlässlich verhindern. Echtzeitschutz und aktuelle Signaturen bleiben sinnvoll, ersetzen aber weder das PHP-Update noch eine eingeschränkte Netzwerkerreichbarkeit.
Muss PHP entfernt werden, wenn es nur für Composer installiert ist?
Eine nur lokal über die Kommandozeile genutzte PHP-Installation besitzt eine kleinere Angriffsfläche als ein erreichbarer Webserver. Sie sollte trotzdem aktualisiert werden, besonders wenn Composer-Skripte oder fremde Projekte damit ausgeführt werden. Eine Deinstallation ist nur sinnvoll, wenn keine Anwendung und kein Entwicklungswerkzeug diese Laufzeit mehr benötigt.
Was ist bei PHP in einer NAS- oder Router-Oberfläche zu tun?
Bei eingebettetem PHP kannst du die Laufzeit normalerweise nicht sicher selbst austauschen. Prüfe die Sicherheits- und Firmware-Rubrik des Geräteherstellers anhand der genauen Modell- und Versionsangabe. Bis ein korrigiertes Update verfügbar ist, sollte die Verwaltungsoberfläche nicht aus dem Internet erreichbar sein; Fernzugriff wird besser über einen abgesicherten Zugang zum eigenen Netzwerk hergestellt.
