Zwei kritische Schwachstellen wurden behoben
Das PHP-Projekt veröffentlichte am 21. Oktober 2026 die Sicherheitsversionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie beheben CVE-2026-109618 und CVE-2026-109619, die laut PHP-Team unauthentifizierte Remote-Code-Ausführung ermöglichen können. Einfach gesagt könnte eine Netzwerkanfrage einen Server dazu bringen, Code auszuführen, ohne dass zuvor ein gültiges Konto erforderlich ist. Das Projekt stuft die Schwachstellen als kritisch ein und empfiehlt ein Update.
Der Hinweis beschreibt unterschiedliche interne Fehlerbedingungen. Wir veröffentlichen keine Ausnutzungsdetails. Entscheidend für Betreiber ist, dass die PHP-Runtime Anfragen verarbeitet, bevor Schutzmaßnahmen der Anwendung zwingend greifen. Eine Plugin-Firewall oder das Ausblenden von Fehlermeldungen ersetzt keine korrigierte Runtime. PHP erklärt, dass es keine vollständigen Abhilfemaßnahmen gibt und ein Update die sichere Wahl ist.
Die Runtime prüfen, die Anfragen bearbeitet
Eine WordPress-, WooCommerce- oder individuelle Website ist nicht allein deshalb automatisch verwundbar, weil sie PHP nutzt. Entscheidend sind PHP-Build, Server-Schnittstelle, Konfiguration, Hersteller-Patches und der Status des Hostings. PHP nennt Webinstallationen mit PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed und stuft mod_php als höchste Risikokonfiguration ein. Linux-Distributionen und LTS-Anbieter können Fixes zurückportieren und eigene Paketversionen verwenden.
Ermitteln Sie die PHP-Version, die tatsächlich die Produktionswebsite bedient, nicht nur die Kommandozeilenversion auf einem Entwicklerrechner. Managed-WordPress-Hoster zeigen sie häufig im Panel oder über den Support an. Kunden von Shared Hosting können erfragen, welches Paket aktiv ist und ob der Dienst neu gestartet wurde. Ein zurückportierter Fix kann vorhanden sein, ohne dass sich die Upstream-Versionsnummer ändert.
Gezielt aktualisieren und testen
Erstellen Sie bei selbst verwalteten Umgebungen ein aktuelles Backup und prüfen Sie die Wiederherstellung. Installieren Sie das korrigierte Paket möglichst zuerst in einer Staging-Umgebung und testen Sie wichtige Abläufe: Anmeldung, Formulare, geplante Aufgaben, Medien, Checkout, Integrationen und Verwaltung. Prüfen Sie auch Protokolle und Hintergrundprozesse. Bei individuellen Erweiterungen oder älteren Abhängigkeiten sollte die Kompatibilität vor der Produktionsumstellung getestet werden.
Ein Hoster kann das Update zentral einspielen; Betreiber sollten dennoch bestätigen, dass die Produktions-Runtime abgedeckt und die Website danach funktionsfähig ist. Schieben Sie einen Sicherheitsfix nicht lange wegen eines Redesigns oder einer Migration auf. Wenn Kompatibilität die Aktualisierung blockiert, verlangen Sie vom Hoster oder Entwickler einen konkreten, terminierten Abhilfeplan. Eine Änderung auf Anwendungsebene neutralisiert nicht zwingend eine Runtime-Schwachstelle.
Auch die Zeit nach dem Patch einplanen
Laut PHP-Projekt endet der Support für PHP 8.2 am 31. Dezember 2026. Version 8.2.35 behebt den aktuellen Hinweis, verlängert aber nicht die Wartungsdauer des Zweigs. Teams mit PHP 8.2 sollten Kompatibilität prüfen und vor dem Ende der Sicherheitsupdates auf einen unterstützten Zweig wechseln. PHP 8.1 und ältere Versionen erhalten keine Fixes mehr vom Projekt; einzelne LTS- oder Hosting-Anbieter können Backports anbieten, was zu prüfen ist.
Führen Sie eine einfache Liste der Websites, PHP-Versionen, Verantwortlichen und Updatewege. So lässt sich die nächste Sicherheitsmeldung schneller bearbeiten. Jetzt gilt: Produktions-Runtime und Patch-Status beim Betreiber bestätigen und anschließend die Website testen. Die Warnung beweist keinen Einbruch; die Verwendung von WordPress allein beweist weder Gefährdung noch Sicherheit.
Quellen und weiterführende Informationen
Einen sachlichen Fehler melden oder eine Quelle vorschlagen? Redaktion kontaktieren.
