PHP-Lücke: Warum dein WordPress-Update nicht reicht

Du hast WordPress brav aktualisiert. 7.1.4 ist drauf, 22 Lücken geschlossen, Haken dran. Und trotzdem kann dein Server offen stehen. Denn die gefährlichste Lücke dieses Herbstes sitzt gar nicht in WordPress, sondern eine Ebene tiefer: in PHP selbst. Dagegen hilft kein Plugin, kein Theme-Update und kein Core-Release.

Was in WordPress 7.1.4 steckt

Am 28. Oktober 2026 ist WordPress 7.1.4 erschienen, ein Security-Release mit 22 behobenen Schwachstellen. Der größte Teil davon sind gespeicherte Cross-Site-Scripting-Lücken, die einen angemeldeten Benutzer mit Redakteurs- oder Autorenrechten voraussetzen. Dazu kommen eine Rechteverwechslung bei eigenen Kommentar-Moderator-Rollen, ein Informationsleck, bei dem unveröffentlichte Customizer-Änderungen für nicht angemeldete Besucher sichtbar waren, und eine Race Condition, die während eines Core-Updates zur Ausführung von fremdem Code führen kann.

Das ist Pflichtprogramm und in wenigen Minuten erledigt. Wer automatische Hintergrund-Updates laufen hat, hat es vermutlich schon hinter sich. Und wenn du nicht weißt, ob bei euch überhaupt jemand solche Updates einspielt, ist das die größere Baustelle. Dazu haben wir schon ausführlich geschrieben: Wer patcht eigentlich deine Website?

Die Lücke, die kein WordPress-Update schließt

Eine Woche vor dem WordPress-Release, am 21. Oktober 2026, hat das PHP-Projekt zwei kritische Fehler im PHP-Interpreter selbst gepatcht. Sie laufen unter den Kennungen CVE-2026-109618 und CVE-2026-109619, haben zusammen den Namen PHP2Shell bekommen und sind mit 9,2 von 10 Punkten bewertet.

Technisch sind es zwei Speicherfehler. Beim ersten kann PHP halb initialisierte Daten als gültig behandeln, wenn dem Server im falschen Moment der Speicher ausgeht. Beim zweiten überleben Daten aus einer Anfrage die Freigabe ihres Speichers und werden von der nächsten Anfrage weiterverwendet. In Kombination lässt sich damit fremder Code auf dem Server ausführen, ohne Account und ohne Passwort. Es reicht, dass die Seite erreichbar ist.

Betroffen ist jede PHP-Installation, die Webanfragen bedient. Also deine WordPress-Seite, aber genauso ein TYPO3, ein Shopware oder das alte Kundenportal, von dem niemand mehr genau weiß, wer es gebaut hat.

Und das ist keine Theorie: Die US-Behörde CISA hat beide Lücken am 26. Oktober 2026 in ihren Katalog der aktiv ausgenutzten Schwachstellen aufgenommen. WordPress selbst hat erklärt, dass dafür kein eigenes Update nötig oder geplant ist. Das ist technisch korrekt und für dich die unangenehme Nachricht: Auf der WordPress-Ebene gibt es hier nichts zu drücken.

Reparieren kann das nur dein Hoster

Gepatcht sind die PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und alles davor gibt es vom PHP-Projekt keinen offiziellen Fix mehr, weil diese Versionen aus der Pflege gelaufen sind. Manche Linux-Distributionen und LTS-Anbieter liefern Backports nach, darauf verlassen sollte man sich aber nicht, ohne nachgefragt zu haben.

Jetzt der Teil, der weh tut. Laut den Statistiken von WordPress.org liefen Ende Oktober 2026 rund 35,8 Prozent aller WordPress-Installationen auf PHP 8.1 oder älter. Etwa jede dritte Seite kann also nicht einfach ein Update einspielen, sondern muss die PHP-Version wechseln.

Und ein PHP-Sprung ist kein Knopf, sondern ein kleines Projekt. Alte Plugins, ein selbstgebautes Theme, ein Snippet, das vor sechs Jahren jemand in die functions.php geschrieben hat: Was auf PHP 7.4 lief, läuft auf 8.3 nicht automatisch weiter. Genau deshalb schieben so viele Betriebe den Wechsel vor sich her, und genau deshalb stehen jetzt so viele Seiten offen.

In fünf Minuten weißt du, wo du stehst

1. PHP-Version ablesen. Im WordPress-Backend unter Werkzeuge, Website-Zustand, Reiter Bericht. Oder im Panel deines Hosters.
2. Vergleichen. 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder höher heißt gepatcht. Dieselbe Reihe mit kleinerer Patch-Nummer heißt offen.
3. Steht da 8.1 oder älter: Hoster fragen, ob er einen Backport eingespielt hat. Wenn nein, ist der Wechsel auf eine gepflegte Version die einzige ehrliche Antwort.
4. Steht da eine gepflegte Reihe mit zu kleiner Patch-Nummer: Hoster fragen, wann er aktualisiert. Managed Hosting zieht das meist von allein nach, nur nicht immer am selben Tag.
5. Logs ansehen. Unerwartete Prozesse, neue Dateien, neue Benutzer, ausgehende Verbindungen vom Webserver. Wer seit dem 21. Oktober ungepatcht im Netz stand, sollte nicht nur patchen, sondern auch nachsehen.

Ein Nebenschauplatz, der dabei leicht untergeht: Eine weitere Lücke, CVE-2026-115560, wird von den Oktober-Updates nicht mitbehoben. Bis dafür ein Fix vorliegt, empfiehlt das PHP-Security-Team, die Einstellung session.upload_progress.enabled auf 0 zu setzen. Betroffen sind nur Anwendungen, die den Serialisierungs-Handler zur Laufzeit umstellen.

Zwei Ebenen, zwei Zuständige

Das ist der eigentliche Punkt dieses Oktobers. Die Sicherheit deiner Website hängt an zwei Ebenen, und für jede ist jemand anderes verantwortlich.

Oben die Anwendung: WordPress-Core, Theme, Plugins. Dafür sorgt dein Team, deine Agentur oder niemand. Unten der Server: PHP-Version, Webserver, Datenbank. Dafür sorgt dein Hoster, entweder von allein oder erst, wenn du fragst.

Ein Beispiel aus dem Alltag. Ein Betrieb mit 20 Mitarbeitern, Website vom Freelancer, Hosting beim günstigsten Anbieter, PHP 7.4, weil ein Update vor Jahren mal etwas zerlegt hat. Das Core-Update auf 7.1.4 lief automatisch durch, im Backend steht ein grünes Häkchen. Die PHP-Lücke bleibt trotzdem offen. Sauber machen heißt hier: Kompatibilität prüfen, zwei alte Plugins ersetzen, auf einer Kopie hochziehen, live schalten. Ein halber Tag Arbeit. Die Alternative, falls jemand schneller ist als du: Bereinigung, Neuaufbau aus einem Backup, Passwörter tauschen, Warnhinweise bei Google wieder loswerden und im Zweifel eine Meldung nach Artikel 33 DSGVO, weil personenbezogene Daten betroffen sein könnten.

Wir würden deinen Hoster ja gern in Schutz nehmen. Aber wenn in seinem Panel PHP 7.4 immer noch als Standard steht, tut er dir keinen Gefallen, sondern spart sich Supportfälle.

Fazit

WordPress 7.1.4 einspielen ist in fünf Minuten erledigt. Danach bleibt die Frage, die dieses Update nicht beantwortet: Auf welcher PHP-Version läuft deine Website, und wer ist dafür zuständig. Wer beides nicht beantworten kann, hat kein Update-Problem, sondern ein Zuständigkeitsproblem. Stand: November 2026, die Patch-Stände ändern sich weiter.

Du weißt nicht, auf welchem Stand deine Website und dein Hosting gerade sind? Wir sehen einmal nach und sagen dir ehrlich, was wir finden: kostenlose Website-Analyse.