Worum es geht
Die beiden Lücken stecken in PHP selbst, also eine Ebene unter WordPress und seinen Plugins. Das PHP-Projekt beschreibt sie so:
- CVE-2026-109618: Geht PHP bei einer Anfrage der Speicher aus, kann es mitten in der Vorbereitung unterbrochen werden. Das anschließende Aufräumen behandelt die halb fertigen Daten dann als gültig.
- CVE-2026-109619: Interne Daten einer Anfrage können liegen bleiben, nachdem ihr Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Prozess kann sie dann benutzen.
Bestätigte Folge ist in beiden Fällen, dass ein Angreifer ohne Anmeldung eigenen Code mit den Rechten des Webservers ausführen kann. Beide Lücken sind mit 9,2 von 10 Punkten bewertet (CVSS 4.0). In Berichten heißen sie „PHP2Shell“, in Anlehnung an die Log4j-Lücke „Log4Shell“ von 2021.
Geschlossen werden sie deshalb auf dem Server, mit einer neuen PHP-Fassung, ganz gleich, wie aktuell WordPress und die Plugins sind.
Wer betroffen ist
Betroffen ist laut PHP-Projekt jede PHP-Installation, die Anfragen aus dem Netz beantwortet, in welcher Betriebsart auch immer. Am höchsten schätzt es das Risiko bei Apache mit mod_php ein: Dort hat es einen Angriff gezeigt, der greift, bevor überhaupt Code der Website läuft. Das BSI hält alle bekannten Fassungen bis mindestens PHP 5 für verwundbar.
Abgesichert sind diese Fassungen, erschienen am 21. Oktober 2026:
| Zweig | Abgesichert ab |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 und älter bekommen vom PHP-Projekt keine Updates mehr. Wegen der Schwere der Lücken hat es für 7.4, 8.0 und 8.1 trotzdem kleine Korrekturen als Quelltext veröffentlicht, und manche Linux-Distributionen und Anbieter mit Langzeitpflege liefern die Behebung für ihre Pakete nach.
So findest du heraus, welche Fassung läuft
Bei WordPress steht sie im Verwaltungsbereich unter Werkzeuge → Website-Zustand, auf dem zweiten Reiter im Abschnitt Server. Bei einem gemieteten Webhosting zeigt sie auch das Kundenmenü des Hosters, meist bei den PHP-Einstellungen.
Steht dort eine kleinere Nummer als in der Tabelle, kann die Seite trotzdem abgesichert sein. Linux-Distributionen und Hoster haben die Korrekturen vorab bekommen, und wer sie in seine bestehende Fassung einbaut, behält dabei oft die alte Nummer. Sicher sagen kann es dann der Hoster.
Was zu tun ist
Bei gemietetem Webhosting spielt der Hoster das Update ein. Im Kundenmenü kannst du meist nur zwischen den Fassungen wählen, die er anbietet. Ist eine abgesicherte darunter, stell auf sie um. Wenn nicht, frag beim Hoster nach, ob deine Fassung die Korrekturen für CVE-2026-109618 und CVE-2026-109619 enthält. Mit den beiden Nummern bekommst du eine genaue Antwort.
Auf einem eigenen Server aktualisierst du heute, über die Pakete deiner Distribution oder auf eine der Fassungen aus der Tabelle. Prüf danach, ob alle PHP-Prozesse neu gestartet sind, sonst läuft die alte Fassung weiter.
Bei einem Baukasten wie Wix, Jimdo, Squarespace oder Shopify betreibt der Anbieter den Server, und das Update ist seine Sache.
Wenn eine Agentur deine Seite betreut, schick ihr diese Meldung. Die Nummern in der Tabelle reichen als Auftrag.
Das PHP-Projekt nennt außerdem Einstellungen, die einzelne Angriffswege verbauen, und schreibt selbst dazu, dass erst das Update eine Installation sicher macht. Auf geteiltem Webhosting setzt die meisten davon ohnehin der Hoster.
Warum das eilt
Das BSI rechnet damit, dass die Lücken „innerhalb weniger Stunden“ nach Erscheinen der Updates in großem Stil ausgenutzt werden. Angreifer können die Updates mit KI-Werkzeugen schnell auswerten und daraus Angriffe bauen, sagt BSI-Vizepräsident Thomas Caspers, und weiter: „Es besteht also unverzüglicher Handlungsbedarf!“
Automatische Scanner fragen nicht, wie groß ein Betrieb ist. Eine übernommene Seite kostet zweimal: die Seite selbst und den Ruf bei Google, das solche Seiten mit einer Warnung versieht oder aus den Ergebnissen nimmt.