PHP-Sicherheitslücke: Hoster und Websites jetzt prüfen

PHP schließt am 21.10.2026 zwei kritische Lücken mit Codeausführung ohne Anmeldung. Was das für WordPress-Websites bedeutet und was Sie prüfen sollten.

Aktuell · Von Kerem Sinecek · Veröffentlicht 22. Oktober 2026 · Aktualisiert 23. Oktober 2026 · 6 Min. Lesezeit

Das PHP-Projekt hat am 21. Oktober 2026 vier Sicherheitsversionen veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei kritische Lücken (CVE-2026-109618 und CVE-2026-109619), über die ein Angreifer ohne Anmeldung Code auf dem Server ausführen könnte. Betroffen ist jede Website, die mit PHP läuft, also auch die meisten WordPress-Seiten. Wer seine Website bei einem Hoster betreibt, sollte klären, ob dort schon aktualisiert wurde.

Update vom 23.10.2026: Viele Betreiber nehmen ihre Website vorübergehend vom Netz, um PHP zu aktualisieren. Google Search Central empfiehlt für diese Zeit den HTTP-Statuscode 503 statt eines Fehlers 404 oder einer Fehlerseite mit Code 200. So bleiben bereits indexierte Seiten nach Angabe von Google in der Suche erhalten. John Mueller von Google bestätigte den Hinweis auf Bluesky. Details stehen im Abschnitt zur Sichtbarkeit in Google.

Was ist passiert?

Das PHP-Projekt kündigte die Sicherheitsversionen am 20. Oktober an und veröffentlichte sie am 21. Oktober um 14:00 UTC. Beide Lücken sind nach dem Bewertungssystem CVSS v4.0 mit 9,2 von 10 eingestuft. Nach Angaben des Projekts können sie unauthentifizierte Codeausführung auf dem Server ermöglichen.

Die erste Lücke entsteht, wenn PHP bei knappem Arbeitsspeicher mitten in der Verarbeitung einer Anfrage unterbrochen wird und beim Aufräumen mit unvollständigen Daten weiterarbeitet. Bei der zweiten bleibt interner Zustand einer Anfrage erhalten, obwohl der zugehörige Speicher schon freigegeben ist, und eine spätere Anfrage am selben Prozess kann ihn verwenden. Das PHP-Projekt hält das Risiko bei Apache mit mod_php für am höchsten; dort sei ein Angriff möglich, bevor Code der Website überhaupt läuft. Betroffen sind laut PHP aber alle Installationen, die Webanfragen bedienen, darunter PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

Die Lücken liegen in PHP selbst, nicht in WordPress, einem Plugin oder einem Theme. WordPress.org schreibt, ein WordPress-Update sei weder nötig noch geplant; die Lösung ist das PHP-Update.

Was bedeutet das für Ihr Unternehmen?

Hat Ihre Website eine PHP-Technik im Hintergrund (typisch sind WordPress, Joomla, Typo3 oder ein Online-Shop auf PHP-Basis), läuft sie auf dem Server eines Hosters oder auf einem eigenen Server mit PHP. Wer dort aktualisiert, ist in der Regel nicht Sie selbst, sondern der Hoster, bei einem eigenen Server die Person, die ihn betreut.

Managed Hosting: Der Anbieter spielt Updates normalerweise selbst ein. Fragen Sie nach, ob die Version vom 21. Oktober installiert ist.
Shared Hosting: Sie können PHP meist nicht selbst patchen. Achten Sie auf Mitteilungen des Anbieters und fragen Sie bei Unklarheit nach.
Eigener Server oder VPS: Die Pakete müssen eingespielt und PHP neu gestartet werden. Das PHP-Projekt weist darauf hin, dass Linux-Distributionen die Korrekturen vorab erhalten haben. Prüfen Sie also das Paket Ihrer Distribution. Das Repository Remi hatte am Veröffentlichungstag nach Angabe des PHP-Projekts noch keine Updates.
PHP 8.1 oder älter: Diese Versionen bekommen vom PHP-Projekt keine Updates mehr. Für PHP 7.4, 8.0 und 8.1 gibt es nach Angabe des Projekts minimale Backports im Quellcode, die Distributionen oder Hoster einsetzen können. Ein Umstieg auf PHP 8.2 oder neuer ist die saubere Lösung. PHP 8.2 selbst erhält nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr.

Websites, die gar kein PHP nutzen, sind von diesen Lücken nicht betroffen.

Was sollten Sie jetzt tun?

PHP-Version herausfinden. In WordPress finden Sie sie unter Werkzeuge, Website-Zustand, Info, Server. Bei anderen Systemen weiß es Ihr Hoster oder Ihre Agentur.
Beim Hoster nachfragen, ob die Sicherheitsversion vom 21. Oktober 2026 oder ein gleichwertiger Patch der Distribution installiert ist. Manche Distributionen beheben die Lücke, ohne die Versionsnummer zu ändern.
Sicherung anlegen (Dateien und Datenbank), bevor eine PHP-Version gewechselt wird, und die Website danach testen.
Auf einem eigenen Server das PHP-Update einspielen und die PHP-Prozesse neu starten.
Wenn ein Update nicht sofort möglich ist: Das PHP-Projekt nennt Maßnahmen, die einzelne Angriffswege schmaler machen, aber ausdrücklich keinen vollständigen Schutz bieten, etwa session.upload_progress.enabled = 0 auf Serverebene. Das ist eine Überbrückung, kein Ersatz für das Update. Wer keine eigene Serverkenntnis hat, lässt das vom Hoster oder einer technischen Fachperson erledigen.

Eine Web Application Firewall, wie sie manche Hoster oder Cloudflare anbieten, kann zusätzlich schützen. Nach den Hinweisen des PHP-Projekts und von WordPress.org ersetzt sie das Update aber nicht.

Was gilt für die Sichtbarkeit in Google, wenn die Website kurz offline ist?

Läuft Ihre Website nicht, während PHP aktualisiert wird, kommt es darauf an, welchen Statuscode Besucher und der Google-Crawler zurückbekommen. Google Search Central rät nach Bericht von Search Engine Journal (21.10.2026) zu 503, also "Dienst vorübergehend nicht verfügbar". Ein pauschales 404 oder eine Fehlerseite, die mit Code 200 ausgeliefert wird, kann dagegen den Eindruck erwecken, die Inhalte seien weg. Laut Google-Dokumentation entfernt der Indexierungsprozess URLs, die dauerhaft einen Serverfehler liefern.

Worauf Sie achten sollten:

Kurz halten: Search Engine Journal verweist auf die Google-Dokumentation zur Crawling-Rate, nach der ein 503 höchstens ein bis zwei Tage ausgeliefert werden sollte. Danach drohe, dass Seiten aus dem Index fallen.
robots.txt erreichbar lassen: Auch die robots.txt sollte nicht mit 503 antworten, sonst wird nach dieser Darstellung das Crawlen insgesamt blockiert.
Nicht aus PHP heraus: Ist PHP selbst gerade das Problem, kann der 503 von außen kommen, etwa über ein CDN oder eine Wartungsseite beim Hoster. Das hat Mueller sinngemäß so formuliert.
Retry-After: Optional kann der Header Retry-After angeben, wann Google es wieder versuchen soll.

Für die meisten Betriebe gilt: Ein Update des Hosters läuft ohne spürbare Ausfallzeit. Klären Sie das vorher, bevor Sie selbst etwas abschalten.

Was ist noch offen?

Die technischen Details waren nach Berichten von Fachmedien schon vor der Veröffentlichung im Umlauf. Ob und in welchem Umfang die Lücken bereits aktiv ausgenutzt werden, ist uns aus den geprüften Primärquellen nicht belegt. Wir haben deshalb dazu keine Aussage getroffen. Ein Hinweis des Bundesamts für Sicherheit in der Informationstechnik (BSI) lag uns bei Redaktionsschluss nicht vor. Der Stand dieses Beitrags ist der 23. Oktober 2026; Hoster und Distributionen liefern ihre Updates in den nächsten Tagen unterschiedlich schnell nach.

Wie unterstützt KSTAQ?

Bei KSTAQ in Dortmund lassen sich solche Fragen im Rahmen der Betreuung klären: Wir prüfen, auf welcher Technik Ihre Website läuft, und begleiten ein nötiges Update. Wenn Ihre Seite ohnehin in die Jahre gekommen ist, kann ein neuer Webauftritt die sinnvollere Lösung sein. Schreiben Sie uns kurz, was Sie einsetzen, dann sagen wir Ihnen, was zu tun ist. Dieser Beitrag ist eine allgemeine Information und keine individuelle IT-Sicherheitsberatung.

Quellen

Weiterlesen

Bereit für eine Website, die für Sie arbeitet?

Erzählen Sie mir von Ihrem Vorhaben. Das Erstgespräch ist kostenlos und unverbindlich.

Projekt anfragen Ablauf ansehen