PHP-Sicherheitslücke 2026: Was CVE-2026-109618 und CVE-2026-109619 für deine Website bedeuten

In diesem Artikel

1. Was ist passiert?
2. Welche Versionen sind betroffen?
3. Für wen ist das relevant?
4. Wie prüfe ich meine Website?
5. Was muss ich jetzt tun?
6. Häufige Fragen

Was ist bei PHP passiert?

PHP verarbeitet jede Webanfrage in mehreren Schritten: Es liest Eingaben, baut interne Datenstrukturen auf, führt Anwendungscode aus und räumt danach wieder auf. Die beiden Schwachstellen liegen in Fehlerfällen rund um diese internen Zustände. Sie sind deshalb nicht auf ein bestimmtes CMS, ein Plugin oder ein einzelnes Formular beschränkt. Eine WordPress-Seite kann betroffen sein, aber ebenso eine individuell entwickelte PHP-Anwendung.

CVE-2026-109618: beschädigter Zustand nach Speichermangel

Wenn PHP während der Vorbereitung einer Anfrage wegen Speichermangels abbricht, können interne Daten teilweise initialisiert zurückbleiben. Beim anschließenden Aufräumen behandelt PHP diese Daten unter Umständen so, als seien sie gültig. Das PHP-Sicherheitsadvisory beschreibt Wege, wie speziell gestaltete Anfragen einen solchen Zustand auslösen können. Besonders relevant ist laut PHP Apache mit mod_php; dort wurde ein Angriffspfad gezeigt, der schon vor der Ausführung des Anwendungscodes ansetzt.

CVE-2026-109619: veralteter globaler Zustand im Worker

Bei der zweiten Lücke kann ein PHP-Worker nach einer Anfrage einen Verweis auf bereits freigegebenen Speicher behalten. Eine spätere Anfrage an denselben Worker kann diesen veralteten Zustand verwenden, bevor die normale Initialisierung ihn ersetzt. Das ist ein sogenanntes Use-after-free-Problem. Ein erfolgreicher Angriff hängt von konkreten Bedingungen und dem Zusammenspiel mehrerer Schritte ab; daraus folgt nicht, dass jede ungepatchte Seite automatisch kompromittiert ist.

Welche PHP-Versionen sind betroffen?

Das PHP-Projekt hat für die unterstützten Versionszweige am 21. Oktober 2026 korrigierte Releases veröffentlicht. Die folgende Übersicht bezieht sich auf die offiziellen PHP-Releases. Bei Linux-Distributionen oder Hosting-Anbietern kann ein Sicherheitsfix als Backport in einem Paket mit niedrigerer sichtbarer Versionsnummer enthalten sein. Darum zählt im Zweifel die Bestätigung des Paket- oder Hosting-Anbieters.

PHP 8.1 und älter: Diese Zweige erhalten vom PHP-Projekt keine regulären Updates mehr. Manche Distributoren stellen eigene Backports bereit. Wenn du einen solchen Zweig nutzt, frage deinen Anbieter ausdrücklich nach den Fixes für beide CVEs und plane eine Migration auf einen unterstützten Zweig. Ein bloßes „PHP 8.1 läuft noch“ ist kein Sicherheitsnachweis.

Für wen ist die Lücke relevant?

Relevant sind grundsätzlich Websites und Anwendungen, die Webanfragen mit PHP verarbeiten: etwa WordPress, TYPO3, Drupal, Shopware, Laravel oder eigene PHP-Systeme. Laut PHP betrifft die Sicherheitsmeldung Installationen mit PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko ist nicht bei jeder Betriebsart gleich; PHP bewertet mod_php derzeit als besonders kritisch.

• Eigene Website: Prüfe, welcher PHP-Prozess die öffentliche Seite tatsächlich ausliefert – nicht nur die Version deiner lokalen Entwicklungsumgebung.
• Managed Hosting: Frage nach dem konkret eingespielten Sicherheitsupdate und nach dem Zeitpunkt des Worker-Neustarts.
• Mehrere Websites auf einem Server: Erfasse alle PHP-Pools, Container und Subdomains. Ein gepatchtes Hauptsystem sagt nichts über einen alten Nebenauftritt aus.
• Kein PHP im Einsatz: Diese beiden PHP-CVEs betreffen den PHP-Kern nicht, wenn dein Angebot tatsächlich nicht über PHP läuft. Andere Komponenten brauchen natürlich ihre eigenen Updates.

Wie kannst du deine Website prüfen?

Beginne mit einer schnellen Orientierung über die öffentliche Domain. Unser PHP-Sicherheitscheck betrachtet öffentlich sichtbare Hinweise der Startseite, etwa HTTP-Header, HTML-Signale und gegebenenfalls eine offen angezeigte PHP-Version. Er kann eine Version mit den offiziellen Fix-Ständen vergleichen und zeigt, wenn keine verlässliche Einordnung möglich ist.

Was das Ergebnis bedeutet – und was nicht

• Version sichtbar und veraltet: Das ist ein starkes Signal für Handlungsbedarf. Prüfe trotzdem, ob dein Anbieter einen Sicherheitsfix zurückportiert hat.
• Version sichtbar und aktuell: Ein guter Hinweis für diese beiden CVEs, aber kein allgemeines Sicherheitszertifikat.
• Keine Version sichtbar oder Anfrage blockiert: Aus der öffentlichen Antwort lässt sich kein verlässlicher Patch-Stand ableiten. Ein fehlender Versionshinweis beweist weder Sicherheit noch Betroffenheit.
• Kein PHP-Signal: PHP kann hinter einem Proxy oder Cache verborgen sein. Bestätige die tatsächlich verwendete Technik im Hosting.

Die verbindliche Prüfung erfolgt im Hosting-Panel oder auf dem Server: Welche PHP-Version bedient den Web-Traffic? Welches Paket ist installiert? Gibt es eine dokumentierte Backport-Freigabe? Wurden nach dem Update alle relevanten Worker neu gestartet? Die Ausgabe von php -v auf der Kommandozeile kann von der PHP-Version des Webservers abweichen.

Was du jetzt konkret tun solltest

1. Bestand erfassen. Liste alle öffentlich erreichbaren PHP-Anwendungen, Hosting-Pakete, Server und PHP-Pools auf. Ordne jedem System einen Verantwortlichen zu.
2. Patch-Stand verifizieren. Prüfe die Version des PHP-Prozesses, der Webanfragen verarbeitet. Bei Paket-Builds mit Backports: Lass dir den Fix für CVE-2026-109618 und CVE-2026-109619 vom Anbieter bestätigen.
3. Vor dem Update absichern. Erstelle ein aktuelles Backup und prüfe, ob eine Wiederherstellung möglich ist. Plane einen kurzen Funktionstest für Login, Formulare, Zahlungen und wichtige Integrationen.
4. PHP aktualisieren. Wechsle auf einen korrigierten Release oder ein nachweislich gepatchtes Anbieterpaket. Aktualisiere dabei keine Anwendungskomponenten blind, sondern beachte ihre Kompatibilität.
5. Worker neu starten. Ein Paketupdate allein genügt möglicherweise nicht, wenn alte PHP-FPM- oder Webserver-Prozesse weiterlaufen. Starte die betroffenen Dienste beziehungsweise Container kontrolliert neu.
6. Ergebnis prüfen. Kontrolliere den aktiven Web-PHP-Stand, Fehlermeldungen und Kernfunktionen. Dokumentiere Datum, Paketversion, zuständige Person und den Nachweis des Fixes.

Häufige Fragen zur PHP-Sicherheitslücke

Ist jede WordPress-Seite betroffen?

WordPress läuft auf PHP. Entscheidend ist aber der PHP-Build des Servers, nicht die WordPress-Version allein. Auch ein vollständig aktualisiertes WordPress behebt keine Schwachstelle im ungepatchten PHP-Kern.

Kann der PHP-Check beweisen, dass meine Seite sicher ist?

Nein. Der Check wertet öffentlich sichtbare Signale aus. Versionen können verborgen sein, Header von einem Proxy stammen und Distributoren Fixes zurückportieren. Für eine belastbare Aussage brauchst du Zugriff auf Hosting- oder Serverdaten beziehungsweise eine Bestätigung deines Anbieters.

Ist PHP 8.1 mit Anbieter-Backport automatisch unsicher?

Nicht zwingend. Ein dokumentierter Backport kann die konkrete Lücke schließen, obwohl die sichtbare Versionsnummer älter ist. Weil PHP 8.1 regulär nicht mehr vom PHP-Projekt gepflegt wird, solltest du den Anbieterbeleg prüfen und die Migration planen.

Muss ich nach einem Update noch etwas tun?

Ja: PHP-Worker neu starten, die aktive Web-Version prüfen, zentrale Funktionen testen und Logs beobachten. Bei Hinweisen auf eine bereits erfolgte Kompromittierung reicht ein Update allein nicht aus; dann sind eine separate Incident-Prüfung und gegebenenfalls weitere Schritte nötig.

Fazit: Erst einordnen, dann sauber patchen

Die zwei CVEs sind ernst, weil sie den PHP-Kern betreffen und laut PHP unter bestimmten Bedingungen Codeausführung ohne Anmeldung ermöglichen. Der wichtigste Schritt ist ein bestätigtes Update auf einen korrigierten Build. Ein öffentlicher Scan hilft beim Einstieg, kann den internen Patch-Stand aber nicht vollständig sehen.