Kritische PHP-Sicherheitslücken: Was WordPress-Website-Betreiber wissen müssen
English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know
PHP hat am 21. Oktober 2026 zwei kritische Sicherheitslücken behoben. Ein Update von WordPress oder Plugins behebt diese nicht. Erfahren Sie, wie Sie überprüfen können, ob Ihre Hosting-Umgebung betroffen ist und welche Schritte Sie unternehmen sollten.
Kurz gesagt: Was geschah?
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Korrekturen für zwei kritische Sicherheitslücken in der PHP-Laufzeitumgebung, CVE-2026-109618 und CVE-2026-109619, die beide gemäß CVSS v4.0 mit 9,2 bewertet wurden. Unter bestimmten Bedingungen ermöglichen sie einem nicht authentifizierten Angreifer, Code auf dem Webserver auszuführen. Da es sich um Schwachstellen in PHP selbst handelt und nicht im WordPress-Kern, in Themes oder Plugins, muss die Korrektur durch eine gepatchte PHP-Version erfolgen, die auf dem Server installiert wird.
Empfohlene Vorgehensweise: Bitten Sie Ihren Hosting-Anbieter, zu bestätigen, dass die PHP-Version Ihrer Website gegen beide Sicherheitslücken gepatcht ist. Wenn Sie den Server selbst verwalten, installieren Sie ein gepatchtes PHP-Paket und starten Sie PHP neu.
Die PHP-Projekthinweise bezeichnen diese Sicherheitslücken als Remote Code Execution (RCE) durch Speichermangel (OOM-Beschädigung, CVE-2026-109618) und RCE durch veralteten globalen Zustand (CVE-2026-109619). In beiden Fällen kann eine Anfrage, die zum falschen Zeitpunkt fehlschlägt, interne Daten in einem ungültigen Zustand hinterlassen, die PHP später verwendet.
Ein erfolgreicher Angriff führt Code mit den Berechtigungen des Benutzerkontos aus, unter dem PHP läuft. Je nach Serverkonfiguration kann ein Angreifer dadurch die wp-config.php und die darin enthaltenen Datenbankzugangsdaten lesen, auf die Datenbank zugreifen oder sie ändern sowie Dateien und Inhalte der Website modifizieren. Ein kompromittierter PHP-Worker gewährt dem Angreifer jedoch nicht automatisch Root-Zugriff auf den Server.
Nutzungsstatus (Stand: 21. Oktober 2026)
Die PHP Foundation gab an, dass ihr Sicherheitsteam im vor der Veröffentlichung aufgetauchten Proof-of-Concept-Code (PoC) keine funktionsfähige Sicherheitslücke gefunden habe, die PoC-Entwicklung jedoch beschleunigt worden sei. Am 21. Oktober meldete Cloudflare, das die Schwachstellen als „php2shell“ bezeichnet, Angriffsverkehr beobachtet zu haben, der auf seine Kunden abzielte, und dass Angreifer ihre Schadsoftware modifizierten, um die Schutzmaßnahmen zu umgehen. Beide Quellen berichten von einem bestätigten erfolgreichen Angriff. Der Angriffsverkehr zeigt zwar, dass Angreifer aktiv versuchen, Daten zu kompromittieren, bestätigt aber nicht automatisch einen erfolgreichen Angriff auf eine Website. Wir werden diesen Abschnitt aktualisieren, sobald es Neuigkeiten gibt.
Wer ist potenziell betroffen?
Potenziell ist jede Website betroffen, die mit einer ungepatchten PHP-Version betrieben wird, unabhängig von den verwendeten WordPress-, Theme- und Plugin-Versionen. Die Empfehlung des PHP-Projekts gilt für alle PHP-Installationen, die Webanfragen verarbeiten, einschließlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.
Das PHP-Projekt stuft das Risiko für mod_php als am höchsten ein, da dort eine Sicherheitslücke nachgewiesen wurde, die durch eine nicht authentifizierte Anfrage ausgelöst werden kann, bevor Anwendungscode ausgeführt wird. Dies bedeutet jedoch nicht, dass andere Konfigurationen sicher sind. Jede PHP-Installation, die Webanfragen verarbeitet, benötigt die entsprechende Korrektur.
So überprüfen Sie Ihre PHP-Version und den Patch-Status
Im WordPress-Dashboard finden Sie unter „Werkzeuge“ → „Website-Status“ → „Info“ den Abschnitt „Server“ . Dort werden die PHP-Version und die PHP-SAPI (Server-API) Ihrer Website angezeigt. Die meisten Hosting-Control-Panels zeigen dieselben Informationen an. Wenn Sie WP Cerber verwenden, finden Sie die PHP-Version und die Server-API ebenfalls unter „ WP Cerber“ → „Werkzeuge“ → „Diagnose“ .
Die folgenden Upstream-Releases des PHP-Projekts enthalten die Korrekturen:
| PHP-Zweig | Upstream-Fix-Release |
|---|---|
| 8,5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0 | Keine offizielle Veröffentlichung. Prüfen Sie bei Ihrem Anbieter, ob eine aktualisierte Version verfügbar ist, oder führen Sie ein Upgrade durch. |
| 7.4 | Es gibt keine offizielle Veröffentlichung. Angepasste Versionen sind jedoch verfügbar, beispielsweise Ubuntu 20.04 LTS mit Ubuntu Pro (7.4.3-4ubuntu2.29+esm5) und, auf Systemen, die bereits das Remi-Repository verwenden, Remi 7.4.33-31 (RHEL 8, 9, 10 und kompatibel). Bitte wenden Sie sich an Ihren Systemanbieter oder führen Sie ein Upgrade durch. |
Wichtig: Dies sind Upstream-Versionen, kein universeller Mindestversionstest. Linux-Distributionen und kommerzielle Anbieter von Langzeitunterstützung (LTS) können die Korrekturen in Builds mit einer früheren Versionsnummer integrieren, einschließlich Builds der unterstützten Zweige 8.2, 8.3 und 8.4. Beispielsweise verwendet Ubuntu 24.04 LTS für seine PHP-8.3-Pakete eine Versionsnummer basierend auf 8.3.6 und liefert beide Korrekturen in der Paketversion 8.3.6-0ubuntu0.24.04.13 aus. Die Website-Integritätsprüfung allein kann nicht feststellen, ob ein Build eines Anbieters beide Korrekturen enthält. Überprüfen Sie die Sicherheitshinweise oder das Änderungsprotokoll des Pakets des Anbieters oder wenden Sie sich an Ihren Hosting-Anbieter. Wechseln Sie nicht zu einem PHP-Paket-Repository eines Drittanbieters, nur weil Ihre Versionsnummer niedriger ist als die der Upstream-Version mit der korrigierten Version.
PHP 7.4, 8.0 und 8.1. Gepatchte Versionen dieser Zweige, die auf den Quellcode-Backports des PHP-Projekts basieren, beheben beide Sicherheitslücken mit einer minimalen Schutzmaßnahme für ältere Versionen. Diese ist weniger umfassend als die vollständige Behebung in Version 8.2 und höher. Durch diese Schutzmaßnahme wird ein PHP-Prozess, dem der Speicher ausgeht, sofort beendet. Daher kann eine Website, die ihr Speicherlimit überschreitet, anstelle der kritischen WordPress-Fehlerseite eine allgemeine Serverfehlermeldung anzeigen. Bei solchen Versionen kann die Website-Integrität vor und nach dem Update dieselbe Versionsnummer anzeigen. Überprüfen Sie daher die Behebung mit Ihrem Hosting-Anbieter oder im Änderungsprotokoll des Pakets. Ein Upgrade auf einen unterstützten Zweig wird weiterhin empfohlen.
Der Support für PHP 8.2 endet bald. Die Sicherheitsunterstützung des PHP-Projekts für PHP 8.2 läuft am 31. Dezember 2026 aus. Wenn Sie von PHP 7.4, 8.0 oder 8.1 aktualisieren, wählen Sie PHP 8.3 oder höher, erstellen Sie vorher ein Backup Ihrer Website und prüfen Sie die Kompatibilität Ihres Themes und Ihrer Plugins. Alternativ können Sie Ihren Hosting-Anbieter um eine aktualisierte Version Ihres aktuellen Zweigs bitten.
Warum der Fix auf dem Server angewendet werden muss
Der anfällige Code ist Teil der PHP-Laufzeitumgebung, die WordPress ausführt, und nicht Teil von WordPress selbst.
- Durch ein WordPress-Update werden diese PHP-Sicherheitslücken nicht behoben. Weder die Aktualisierung des WordPress-Kerns, der Themes noch der Plugins ändert die PHP-Laufzeitumgebung.
- Sicherheits-Plugins können die Laufzeitumgebung nicht reparieren. Manche Angriffe können ausgeführt werden, bevor WordPress geladen ist, sodass kein Plugin die Anfrage untersuchen kann. Regeln der Web Application Firewall (WAF) auf Hosting- oder Netzwerkebene können bestimmte Angriffswege einschränken, sind aber kein vollständiger Ersatz für das Einspielen von Sicherheitspatches.
- Änderungen an den Einstellungen innerhalb der Website bieten keine zuverlässige Lösung. Die PHP-Projekt-Empfehlung warnt davor, sich bei der Anwendung der Konfigurationsschutzmaßnahmen auf
ini_set()oder FPM-.user.ini-Dateien zu verlassen. Gleiches gilt für PHP-Einstellungen, die inwp-config.phpoder durch ein Plugin geändert wurden. Selbst die in der Empfehlung beschriebenen serverseitigen Maßnahmen reduzieren lediglich die Anfälligkeit für bestimmte Angriffspfade und gewährleisten keine vollständige Sicherheit der Installation.
Hinweis für WP Cerber-Nutzer: WP Cerber läuft innerhalb von WordPress. Es kann PHP nicht patchen und Anfragen, die eine dieser Sicherheitslücken auslösen, nicht untersuchen, bevor WordPress geladen wird. Aus demselben Grund werden solche Angriffe möglicherweise nicht in den WP Cerber-Protokollen erfasst. Ein Protokoll ohne verdächtige Einträge beweist daher nicht, dass die Website nicht Ziel eines Angriffs war. WP Cerber schützt WordPress weiterhin auf Anwendungsebene, ersetzt aber nicht die Aktualisierung von PHP.
Was ist jetzt zu tun?
Wenn Sie den Server nicht verwalten
Dies gilt für Shared Hosting und Managed Hosting, bei denen Ihr Anbieter für die Wartung der PHP-Laufzeitumgebung verantwortlich ist. Bitten Sie ihn, zu bestätigen, dass die PHP-Version, die Ihre Website ausliefert, Korrekturen für beide Sicherheitslücken enthält. Sie können diese Frage unverändert senden:
Ist die PHP-Version, die meine Website ausliefert, gegen CVE-2026-109618 und CVE-2026-109619 gepatcht? Wurden die relevanten PHP-Prozesse neu gestartet, um die gepatchte Version zu laden?
Wenn Sie einen VPS oder einen dedizierten Server verwalten
- Aktualisieren Sie PHP. Installieren Sie die aktualisierte, gepatchte Version oder ein Paket einer Distribution oder eines Anbieters, dessen Hinweise oder Änderungsprotokoll bestätigen, dass es beide Korrekturen enthält.
- Starten Sie PHP neu. Starten Sie PHP-FPM, Apache oder jeden anderen Dienst, der PHP für Ihre Websites ausführt, neu oder laden Sie ihn neu. Laufende PHP-Worker verwenden weiterhin die alte Binärdatei, bis sie neu gestartet werden.
- Überprüfen Sie dies. Stellen Sie in der Website-Integrität sicher, dass die erwartete PHP-Version nun auf jeder Website ausgeführt wird. Bestätigen Sie anschließend separat in den Herstellerhinweisen oder im Änderungsprotokoll des Pakets, dass das installierte Paket beide Korrekturen enthält. Die Website-Integrität zeigt zwar die laufende Version an, kann aber nicht beweisen, dass ein Backport enthalten ist. Der Befehl
php -vkann eine andere PHP-Installation anzeigen als die, die Ihre Website ausführt. Verlassen Sie sich daher nicht allein darauf.
Unabhängig davon, welcher Fall auf Sie zutrifft, sollten Sie ein aktuelles Backup erstellen, das Sie wiederherstellen können. Falls Sie vermuten, dass Ihre Website vor dem PHP-Patch kompromittiert wurde, beachten Sie, dass ein PHP-Update weder Malware noch Hintertüren entfernt. Wenden Sie sich in diesem Fall zuerst an Ihren Hosting-Anbieter, da der über PHP erlangte Zugriff möglicherweise nicht auf WordPress-Dateien beschränkt ist. Informationen zur Bereinigung Ihrer WordPress-Installation finden Sie in unserem Leitfaden „Was tun, wenn Ihre WordPress-Website gehackt wurde ?“.
Häufig gestellte Fragen
Ist mein Computer oder Browser gefährdet, wenn ich eine betroffene Website besuche?
Nicht direkt. Die Schwachstellen befinden sich im PHP-Code des Webservers, nicht auf den Geräten oder Browsern der Besucher. Eine über diese Schwachstellen kompromittierte Website könnte jedoch so verändert werden, dass sie Schadsoftware ausliefert, wodurch Besucher indirekten Risiken ausgesetzt sind.
Muss ich WordPress neu installieren?
Nein, nicht um diese Sicherheitslücken zu beheben. Sie werden durch ein PHP-Update auf dem Server behoben, und eine Neuinstallation von WordPress ändert PHP nicht. Eine Neuinstallation kann dennoch Teil der Bereinigung einer kompromittierten Website sein.
Kann ich das ohne die Hilfe meines Hosting-Anbieters beheben?
Das hängt davon ab, ob Sie die PHP-Laufzeitumgebung kontrollieren. Auf einem VPS oder dedizierten Server können Sie die gepatchten Pakete selbst installieren. Bei Shared Hosting oder Managed Hosting verwaltet der Hosting-Anbieter PHP. Viele Control Panels ermöglichen es Ihnen, eine Website auf eine andere PHP-Version umzustellen, aber ob diese Version gepatcht ist, hängt weiterhin vom Hosting-Anbieter ab.
Quellen
- PHP-Projekt, Sicherheitshinweis: Kritische Sicherheitslücken zur Ausführung von Remote-Code, jetzt aktualisieren , 21. Oktober 2026.
- PHP-Projekt GHSA-w8hw-w9fx-j79w: RCE durch OOM-Beschädigung (CVE-2026-109618) , 21. Oktober 2026.
- PHP-Projekt, GHSA-6wmf-4rv5-p3rp: RCE durch veralteten globalen Zustand (CVE-2026-109619) , 21. Oktober 2026.
- Die PHP Foundation, Heutige PHP-Sicherheitsversion und wie wir die PHP-Sicherheit stärken , 21. Oktober 2026.
- PHP-Projekt, Unterstützte Versionen .
- php-src Commit 712e60f: Vermeidung von Zustandsbeschädigung durch Bailout , die minimale Abhilfemaßnahme für Versionen am Ende ihres Lebenszyklus.
- Remis RPM-Repository, php74-php Changelog , Eintrag für 7.4.33-31, 21. Oktober 2026.
- Ubuntu, Sicherheitsstatusseiten für CVE-2026-109618 und CVE-2026-109619 , 21. Oktober 2026.
- Cloudflare, Cloudflare implementiert Schutzmaßnahmen gegen php2shell-Schwachstelle , 21. Oktober 2026.