PHP2Shell: Was Betreiber jetzt prüfen sollten
Das PHP-Projekt hat am 21. Oktober 2026 Sicherheitsupdates gegen CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Die unter PHP2Shell bekannten Schwachstellen können Angreifern ohne Anmeldung die Ausführung von Code ermöglichen. Die korrigierten Upstream-Versionen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Prüfen Sie zeitnah den PHP-Patchstand Ihrer Website mit dem Hoster oder der Serveradministration.
PHP verarbeitet auf dem Server unter anderem die Anfragen einer WordPress-Website. Ein aktuelles WordPress und aktuelle Plugins ersetzen das PHP-Sicherheitsupdate deshalb nicht. Auch andere PHP-Anwendungen müssen geprüft werden. Eine verwundbare Version ist ein Handlungsgrund, aber für sich allein kein Nachweis einer erfolgreichen Kompromittierung.
Offizielle Veröffentlichung: PHP Foundation zum Sicherheitsrelease vom 21. Oktober 2026.
Was die beiden CVEs genau beschreiben
CVE-2026-109618 betrifft Fehler bei der Behandlung von Speichermangel, englisch Out of Memory. Ein Abbruch kann interne Request-Daten in einem nur teilweise initialisierten Zustand hinterlassen. Die anschließende Bereinigung kann diese Daten fälschlich als gültig behandeln und Speicher beschädigen.
CVE-2026-109619 betrifft veralteten globalen Zustand nach einem fatalen Fehler. Interne Verweise können auf bereits freigegebenen Request-Speicher zeigen. Eine spätere Anfrage im selben Worker kann diesen Zustand verwenden, bevor die normale Initialisierung ihn zurücksetzt.
Die PHP Foundation bestätigt für CVE-2026-109618 demonstrierte Codeausführung mit Apache mod_php vor dem Start des Anwendungscodes und über Anwendungspfade auch mit PHP-FPM. Für CVE-2026-109619 nennt sie einen bestätigten Use-after-free und einen Worker-Absturz sowie demonstrierte Codeausführung in einer realen Anwendung mit mod_php. Diese technischen Nachweise belegen keine erfolgreiche Ausnutzung einer bestimmten Website.
Technische Einordnung: Beschreibung beider CVEs durch die PHP Foundation.
Welche PHP-Versionen betroffen und korrigiert sind
Für die unterstützten stabilen PHP-Zweige gelten die folgenden Bereiche ungepatchter Upstream-Releases. Die Grenzen gelten jeweils innerhalb des genannten Zweigs, nicht als pauschaler Vergleich aller PHP-Versionsnummern. Ein Distributions-Backport kann die Lücken bereits bei einer älteren Basisversion schließen.
- PHP 8.2.0 bis einschließlich 8.2.34: korrigiert ab 8.2.35.
- PHP 8.3.0 bis einschließlich 8.3.35: korrigiert ab 8.3.36.
- PHP 8.4.0 bis einschließlich 8.4.26: korrigiert ab 8.4.27.
- PHP 8.5.0 bis einschließlich 8.5.11: korrigiert ab 8.5.12.
Versionsbeleg: PHP-Releaseankündigungen und Sicherheitsmeldung.
Änderungsnachweis: PHP-8-Changelog.
Ältere Zweige und Distributions-Patches richtig einordnen
Die Forschung reicht bis PHP 5.4.0 zurück. Calif nennt dies als frühesten gefundenen betroffenen Pfad; die verfügbaren Angriffspfade unterscheiden sich nach Version und Server-Anbindung. Daraus folgt keine identische Ausnutzbarkeit jeder Altversion. PHP 8.1 und ältere Zweige erhalten keine regulären Updates mehr vom PHP-Projekt. Lassen Sie einen passenden Hersteller-Patch bestätigen oder planen Sie den Wechsel in einen unterstützten Zweig.
Ein konkretes Gegenbeispiel zum reinen Versionsvergleich liefert Ubuntu 24.04 LTS: Das Sicherheitsbulletin USN-8948-1 nennt 8.3.6-0ubuntu0.24.04.13 als korrigierten Paketstand, unter anderem für PHP-FPM und mod_php. Die Basisnummer 8.3.6 liegt unter 8.3.36, enthält hier aber die zurückportierte Korrektur. Maßgeblich sind Distribution, Paketquelle, vollständige Paketversion und die Bestätigung für beide CVEs. Fragen Sie bei Managed Hosting nach diesem Nachweis.
Historischer Umfang: Calif-Forschungsbericht zu versionsabhängigen Angriffspfaden.
Beispiel für Backports: Ubuntu-Sicherheitsbulletin USN-8948-1.
Die tatsächlich verwendete Web-PHP-Version prüfen
Öffnen Sie in WordPress Werkzeuge > Website-Zustand > Bericht > Server und lesen Sie die PHP-Version ab. Je nach Übersetzung heißt der Bereich Informationen. Die WordPress-Dokumentation beschreibt diese Serverinformationen im Site-Health-Bericht. Kontrollieren Sie zusätzlich die PHP-Zuordnung der jeweiligen Domain im Hosting-Panel.
Für die Serveradministration ist php -v ein zusätzlicher Hinweis auf das Kommandozeilen-PHP. Es beweist nicht, welche PHP-FPM-Version, welches Apache-Modul oder welcher Container die Website bedient. Erfassen Sie deshalb Web-PHP und CLI getrennt. Lassen Sie sich vom Hoster die laufende Version und den vollständigen Paketstand des zuständigen Dienstes bestätigen. Eine öffentlich erreichbare phpinfo-Seite ist dafür nicht nötig.
Anleitung: WordPress-Dokumentation zum Site-Health-Bericht.
Weitere Anleitungen finden Sie im devvibe-Magazin.
Patch einspielen und laufende Worker kontrollieren
Installieren Sie das korrigierte Paket über die vorgesehene Paketquelle oder lassen Sie den Hoster aktualisieren. Bei Containern muss ein korrigiertes Image auch tatsächlich ausgerollt werden. Danach müssen die betroffenen Prozesse den neuen Code laden. Ubuntu weist ausdrücklich darauf hin, dass Anwendungen beziehungsweise Dienste nach dem Paketupdate neu gestartet werden müssen.
Prüfen Sie anschließend erneut die Web-PHP-Version und testen Sie Anmeldung, Formulare, Uploads und wichtige Shop-Funktionen. Halten Sie Paketstand, Zeitpunkt und zuständige Person fest. Das ist unsere Empfehlung für einen nachvollziehbaren Betriebsabschluss.
Laut PHP-Projekt ist nur das Update eine vollständige Lösung. Die dort beschriebenen Konfigurationsmaßnahmen reduzieren einzelne Angriffspfade, machen eine ungepatchte Installation aber nicht sicher. Stimmen Sie notwendige Übergangsmaßnahmen mit dem Hoster ab, einschließlich einer vorübergehenden Zugriffsbeschränkung. Ein WordPress-Sicherheitsplugin ersetzt den Server-Patch nicht.
Update und Neustart: Ubuntu-Hinweise zu PHP2Shell.
Grenzen von Übergangsmaßnahmen: Aktuelle Sicherheitsmeldung des PHP-Projekts.
Logs und mögliche Kompromittierungsspuren kontrollieren
Zum Abschluss gehört eine Prüfung der verfügbaren Webserver-, PHP- und Sicherheitslogs. Sichern Sie vorhandene Daten vor einer Bereinigung und ordnen Sie Auffälligkeiten zeitlich ein. Elastic beschreibt ungewöhnliche Kindprozesse eines Webservers, nachgeladene Programme und neu angelegte ausführbare Dateien als relevante Signale nach einer möglichen Codeausführung. Diese Hinweise sind allgemeine Untersuchungspunkte, keine eindeutigen PHP2Shell-Indikatoren.
Unsere ergänzende Empfehlung für WordPress: Kontrollieren Sie unerwartete PHP-Dateien, insbesondere im Upload-Verzeichnis, geänderte Core-Dateien, unbekannte Administratoren, Plugins und geplante Aufgaben. Ein einzelner Fehler oder eine neue Datei beweist keinen Angriff; fehlende Auffälligkeiten schließen ihn bei begrenzter Protokollierung ebenfalls nicht aus.
Bei begründetem Verdacht sollten Hoster und zuständige Sicherheitsverantwortliche die Untersuchung übernehmen. Ein eingespielter Patch entfernt keine zuvor abgelegten Schadprogramme. Dokumentieren Sie offene Befunde und entscheiden Sie über Wiederherstellung und Zugangserneuerung auf Basis der Untersuchung.
Hinweise zur Erkennung: Elastic zu Prozess- und Dateispuren im PHP2Shell-Kontext.
Unterstützung bei Updates und Kontrollen: WordPress-Wartung bei devvibe.