Das PHP-Projekt hat am 21. Oktober 2026 dringende Sicherheitsupdates veröffentlicht. Sie beheben CVE-2026–109618 und CVE-2026–109619, die jeweils mit 9,2 von 10 nach CVSS v4.0 bewertet sind. Bei der ersten Lücke geht es um Codeausführung durch eine Beschädigung infolge von Speichermangel. Die zweite betrifft veraltete Zustände von Worker-Prozessen.

Die Fehler liegen in PHP und nicht in WordPress Core, einem Plugin oder einem Theme. Eine Aktualisierung von WordPress ändert den PHP-Dienst nicht. Gelingt ein Angriff ohne Anmeldung, kann der Angreifer mit den Rechten der Website auf Dateien, Zugangsdaten und Daten zugreifen. Damit sind unter anderem Datendiebstahl, manipulierte Dateien und dauerhafte Backdoors möglich.

PHP hat Remote Code Execution für beide Schwachstellen bestätigt. Für CVE-2026–109618 wurde außerdem ein Angriffsweg bestätigt, der vor dem Start von WordPress ausgeführt werden kann. CrowdStrike berichtet, dass ein privater Exploit zuverlässig auf Intel-, AMD- und Arm-Systemen sowie gegen frisch gestartete PHP-Worker funktionierte. Wordfence hat diesen nicht veröffentlichten Exploit nicht selbst geprüft. Ein Angriff muss an einen konkreten Server angepasst werden können, doch ein ungepatchtes System ist deshalb nicht sicher. Im Internet kursieren bereits Proofs of Concept, darunter unvollständige oder fehlerhafte Beispiele.

Das Wordfence Threat Intelligence Team begann wenige Stunden nach Veröffentlichung der Updates mit Tests. In einem speziell konfigurierten Apache-Labor mit PHP 8.5.11 führte ein Proof of Concept für CVE-2026–109619 über HTTP zur Erstellung einer temporären Textdatei. Das belegte dort die Codeausführung. Ein normal optimierter Build von PHP 8.5.11 stürzte beim gleichen Test ab, PHP 8.5.12 blieb funktionsfähig. Bei CVE-2026–109618 schlug die Anfrage unter PHP 8.5.11 fehl, während PHP 8.5.12 sie normal verarbeitete. Weitere Tests mit WordPress 7.1.3 und einem betroffenen Ubuntu-Paket mit PHP 8.5.4 lösten in einigen Umgebungen Fehler oder Neustarts aus. Eine unabhängige Codeausführung für diese CVE gelang Wordfence nicht. Die Untersuchungen laufen weiter, da sich das Verhalten je nach Server unterscheiden kann.

Die ersten korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Linux-Distributionen und Anbieter mit Langzeitpflege können die Korrekturen in Pakete mit älteren Versionsnummern zurückportieren. Deshalb müssen die vollständige Paketrevision und der Sicherheitshinweis des Anbieters geprüft werden. PHP 8.1 und ältere Zweige werden vom PHP-Projekt nicht mehr veröffentlicht. Nutzer dieser Versionen sollten eine ausdrückliche Bestätigung ihres Anbieters einholen oder auf einen unterstützten Zweig wechseln.

Bei Managed Hosting sollte der Anbieter bestätigen, dass beide CVEs im PHP-Dienst der Website behoben sind und PHP neu gestartet wurde. Betreiber eigener Server müssen PHP aktualisieren und Apache, PHP-FPM oder einen anderen PHP-Dienst neu starten. Container müssen aus einem aktualisierten Image neu gebaut und ausgerollt werden. Agenturen und Hoster sollten auch Produktions-, Test- und Origin-Umgebungen sowie alte Container prüfen.

Die verwendete PHP-Version steht in WordPress unter Tools > Site Health > Info > Server. Die Ausgabe von `php -v` auf der Kommandozeile kann zu einer anderen PHP-Installation gehören. Nach dem Update sollten Betreiber die tatsächlich verwendete Version und die vollständige Paketrevision kontrollieren. Backups sowie Webserver-, PHP-, Firewall- und Systemprotokolle sollten mindestens für die 48 Stunden vor dem 21. Oktober bis zum Patch und Neustart aufbewahrt werden. Bei verspäteten Updates sind die Protokolle auf ungewöhnliche Aktivitäten zu prüfen. Unauffällige Logs schließen eine Ausnutzung nicht aus.

Die vorläufigen Empfehlungen von PHP können bei fehlender sofortiger Patchmöglichkeit einzelne Angriffswege erschweren. Sie sind unvollständig, können normale Funktionen beeinträchtigen und ersetzen das Update nicht. Die Wordfence Firewall schützt die Anwendungsschicht von WordPress. Die beschriebenen Fehler betreffen jedoch PHP auf Serverebene, und manche Angriffe beginnen vor dem Laden von WordPress. Deshalb sind aktuelle Schutzmaßnahmen für PHP, Webserver, Betriebssystem und Netzwerkgrenze erforderlich.