PHP-Sicherheitslücken: Warum ein WordPress-Update nicht reicht

Eine Website kann bei WordPress, Plugins und Themes auf dem neuesten Stand sein – und trotzdem auf einer verwundbaren PHP-Version laufen. Genau das macht die Warnung vom 21. Oktober 2026 so relevant: Das PHP-Projekt hat zwei kritische Fehler im Unterbau vieler Websites geschlossen. Unter geeigneten Bedingungen kann ein Angreifer darüber ohne Anmeldung Code auf einem Server ausführen. Hier steht, welche Versionen betroffen sind, warum WordPress allein das Problem nicht lösen kann und was Betreiber jetzt konkret prüfen sollten.

Kernpunkte

• Zwei Schwachstellen im PHP-Kern heißen CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 nach CVSS v4.0 als kritisch bewertet.
• Seit dem 21. Oktober stehen korrigierte Versionen bereit: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Bei Distributionspaketen kann ein zurückportierter Fix eine andere Versionsnummer tragen.
• Ein WordPress-, Plugin- oder Theme-Update ersetzt das PHP-Update nicht. Für diese beiden Fehler plant WordPress selbst kein eigenes Update.
• Die höchste Dringlichkeit gilt öffentlich erreichbaren PHP-Systemen. Die Demonstration eines Angriffs ist kein Beleg dafür, dass jede verwundbare Website bereits angegriffen wurde.

Zwei Fehler im Maschinenraum, nicht im Blogbeitrag

PHP verarbeitet auf vielen Websites die Anfragen hinter Formularen, Logins und Seitenaufrufen. Die beiden neuen Fehler sitzen in internen Abläufen dieser Laufzeitumgebung. Sie betreffen nicht bloß eine bestimmte WordPress-Erweiterung und auch nicht nur schlecht geschriebene Anwendungen. Das PHP-Sicherheitsteam nennt ausdrücklich PHP-FPM, Apache mit `mod_php`, `php-cgi`, FrankenPHP und LiteSpeed als Umgebungen, die Webanfragen mit PHP bearbeiten.

Bei CVE-2026-109618 kann eine Speicherknappheit PHP in einem ungünstigen Moment unterbrechen. Interne Daten sind dann noch nicht fertig eingerichtet, werden beim Aufräumen aber unter Umständen wie gültige Daten behandelt. Die technische Meldung des PHP-Projekts beschreibt bestätigte Wege bis zur Ausführung fremden Codes. Das ist mehr als ein bloßer Absturz, aber auch kein universeller Knopf, mit dem jeder PHP-Server sofort übernommen wäre: Konfiguration und Angriffsweg spielen eine Rolle.

CVE-2026-109619 betrifft alten internen Zustand, der über eine Anfrage hinaus bestehen bleibt, obwohl der zugehörige Speicher schon freigegeben wurde. Ein späterer Aufruf im selben PHP-Prozess kann ihn zu früh wieder benutzen. Die zweite technische Meldung nennt bestätigte Szenarien mit Codeausführung und Speicherzugriff. Für Laien reicht das Bild: Die Anwendung sieht einen neuen Besucher, der PHP-Prozess kann aber gefährliche Reste einer früheren Anfrage mit sich tragen.

Die PHP Foundation erklärt, dass für Apache mit `mod_php` ein Angriff ohne Anmeldung bereits vor dem Start von Anwendungscode demonstriert wurde. Auch für PHP-FPM sind Ausnutzungswege bestätigt, dort allerdings über passende Abläufe in der Anwendung. Die Einstufung „kritisch“ ist also begründet, ohne dass jede Installation identisch angreifbar wäre.

Warum ein aktuelles WordPress noch kein Entwarnungssignal ist

WordPress läuft auf PHP. Im Dashboard können WordPress-Kern, Plugins und Themes frisch aktualisiert sein, während der Webserver weiterhin eine ältere PHP-Version ausführt. Die WordPress-Sicherheitsmeldung sagt ausdrücklich: Diese Fehler liegen nicht in WordPress; ein WordPress-Update ist dafür weder nötig noch geplant. Wer nur auf den grünen Update-Status im Dashboard schaut, prüft die falsche Schicht.

Die laufende PHP-Version lässt sich in WordPress unter Werkzeuge → Website-Zustand → Bericht → Server nachsehen. Viele Hoster zeigen sie zusätzlich im Hosting-Panel. Entscheidend ist die tatsächlich für die Website aktive Laufzeit – nicht die Version, die auf dem eigenen Laptop oder in einer lokalen Kommandozeile installiert ist. Bei gemanagtem Hosting sollte der Anbieter bestätigen, welche PHP-Version oder welcher zurückportierte Sicherheitspatch produktiv aktiv ist. Eine Versionsangabe ohne Patchstand kann bei Distributionspaketen missverständlich sein.

Das Prinzip ist größer als dieser Vorfall: Sicherheitsarbeit endet nicht beim sichtbaren Produkt. Der Wissenschaftswelle-Beitrag Wenn KI Bugs fixt, wird Wartung zur Vertrauensfrage beschreibt, warum ein Patch erst nach Prüfung und produktiver Übernahme zählt. Und Open Source: Warum unbezahlter Code das Rückgrat der digitalen Welt geworden ist zeigt, wie Wartung und Verantwortlichkeit hinter verbreiteten Bausteinen zusammenhängen. Bei PHP wird diese meist unsichtbare Abhängigkeit plötzlich sehr konkret.

Welche Versionen und Betreiber müssen reagieren?

Für die unterstützten Zweige nennt PHP vier korrigierte Mindeststände: 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Ältere Zwischenversionen dieser Zweige enthalten den Fix nicht. PHP 8.1 und älter erhalten vom PHP-Projekt keine regulären Updates mehr. Manche Linux-Distributionen und Langzeit-Anbieter liefern eigene zurückportierte Patches; PHP hat zudem minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt. Das ist kein Grund, ungeprüft eine alte Installation als sicher zu erklären: Betreiber brauchen eine nachvollziehbare Bestätigung des konkreten Anbieters oder müssen auf einen unterstützten Zweig wechseln.

Die europäischen Sicherheitsbehörden empfehlen, PHP-Anwendungen zu inventarisieren und öffentlich erreichbare Systeme zu priorisieren. Dazu gehören nicht nur klassische Blogs, sondern auch Shops, Portale und Werkzeuge, die PHP intern verwenden. Wer mehrere Websites betreibt, sollte jede Laufzeit prüfen: Ein aktualisierter Hauptauftritt sagt nichts über ein altes Unterverzeichnis, eine Testinstanz oder einen anderen Hosting-Tarif aus.

Was heute konkret zu tun ist

Der sichere Weg beginnt mit einer Bestandsaufnahme: Welche öffentlich erreichbaren Dienste nutzen PHP, welcher Zweig läuft dort, und wer kann die Serverlaufzeit aktualisieren? Danach gehört der Fix in die produktive Umgebung. Das kann ein Wechsel auf die korrigierte PHP-Version im Hosting-Panel sein oder ein bestätigtes Sicherheitspaket des Betriebssystemanbieters. Anschließend müssen die betroffenen Prozesse tatsächlich mit dem neuen Code laufen; ein eingespieltes Paket ohne wirksamen Neustart kann trügerisch sein. Funktionsprüfungen der Website gehören dazu, denn ein Update soll nicht unbemerkt Formulare oder Shops beschädigen.

Wenn ein sofortiges Update nicht möglich ist, nennen PHP und CERT.at vorübergehende technische Einschränkungen für einzelne Angriffswege. Sie sind kein vollständiger Schutz und gehören in die Hände der zuständigen Administratoren: Falsche Speicher- oder Upload-Grenzen können selbst den Betrieb stören. Die Behörden empfehlen, öffentlich exponierte Anwendungen bei Bedarf vorübergehend vom Netz zu nehmen, bis eine sichere Aktualisierung möglich ist. Eine Web Application Firewall kann Risiko mindern, ersetzt den PHP-Fix aber ebenfalls nicht.

Für private Website-Besucher ist die Lage anders. Der Fehler sitzt auf dem Server; im eigenen Browser lässt sich die PHP-Version einer fremden Website weder zuverlässig erkennen noch reparieren. Wer einen Hosting-Vertrag verwaltet, muss handeln oder den Hoster fragen. Wer eine Website nur liest, muss nicht wegen dieser Meldung sein WordPress-Passwort ändern oder ein dubioses „PHP-Schutztool“ installieren.

Ist schon ein Angriff passiert? Was die Warnung wirklich belegt

Öffentliche technische Demonstrationen zeigen, dass die beiden Fehler unter bestimmten Bedingungen ausnutzbar sind. Das ist nicht dasselbe wie ein bestätigter Angriff auf eine bestimmte Website. CERT.at hält ausdrücklich fest, dass das PHP-Projekt in seiner Meldung keine Angaben zu aktiver Ausnutzung macht. Diese Aussage begrenzt den Stand der offiziellen Meldung; sie beweist umgekehrt nicht, dass es nirgends Angriffsversuche gibt. Wer konkrete Hinweise auf einen Vorfall hat, muss Logs, Prozesse, Dateien und Zugangsdaten im eigenen System untersuchen – die bloße Versionsnummer entscheidet darüber nicht.

Auch die Zahl 9,2 sagt etwas Bestimmtes und etwas gerade nicht. Sie beschreibt die technische Schwere nach einem standardisierten Bewertungssystem. Sie ist keine Schätzung, dass 92 Prozent der Websites kompromittiert seien. Die Sicherheitsmeldung zu CVE-2026-109618 führt hohe Angriffskomplexität und bestimmte Voraussetzungen auf; dennoch sind keine Zugangsdaten und keine Mithilfe eines Nutzers erforderlich, wenn der passende Pfad offen ist. Das rechtfertigt schnelles Patchen, nicht die Behauptung einer bereits vollzogenen Massenübernahme.

Die eigentliche Lehre liegt unter der Oberfläche

Eine Sicherheitsmeldung über PHP klingt für viele Website-Betreiber zunächst wie eine Nachricht für Programmierer. Tatsächlich ist sie eine Betriebsfrage: Wer weiß, welche Laufzeit auf welchem Server aktiv ist, wer sie aktualisieren darf und wie man den Erfolg nachprüft? Genau an dieser Stelle entscheidet sich, ob ein veröffentlichter Fix Schutz wird.

Der unangenehme Teil dieser Geschichte ist nicht, dass „das Internet kaputt“ wäre. Er ist, dass die grüne Update-Anzeige einer Anwendung eine tiefere Schicht nicht abdeckt. Für die beiden PHP-Lücken gibt es jetzt korrigierte Versionen. Die nächste vernünftige Handlung ist deshalb unspektakulär und dringlich zugleich: aktive PHP-Version feststellen, passenden Fix einspielen oder bestätigen lassen und anschließend die produktive Website prüfen.