Das PHP-Projekt hat zwei Schwachstellen bekannt gegeben, die beide unauthentifizierte Remote Code Execution ermöglichen – ein Angreifer kann also ohne Zugangsdaten Code auf dem Server ausführen. Beide sind mit CVSS 9.2 als kritisch eingestuft, dem zweithöchsten Wert, den diese Skala kennt.

CVE-2026-109618 betrifft die Behandlung von Speichermangel: PHP kann mitten in der Vorbereitung eines Requests abbrechen und hinterlässt dabei halb initialisierte interne Daten, die anschließend als gültig behandelt werden. CVE-2026-109619 betrifft Zustand, der einen Request überlebt: Ein späterer Aufruf im selben Arbeitsprozess kann auf Daten zugreifen, deren Speicher längst freigegeben wurde.

Behoben sind beide in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wer eine dieser Versionen fährt, ist raus.

Diese Lücke hat nichts mit Ihrem Code zu tun. Sie sitzt im Unterbau, der Ihren Code ausführt – und greift, bevor eine einzige Zeile Ihrer Anwendung läuft.

Betroffen ist laut Advisory alles, was Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed. Das höchste Risiko besteht bei mod_php – dort wurde gezeigt, dass eine einzelne unauthentifizierte Anfrage den Angriff auslösen kann, bevor Anwendungscode startet.

Das ist der Punkt, der diese Meldung von den meisten anderen unterscheidet. Ob auf Ihrem Server Contao, WordPress, Shopware oder eine Eigenentwicklung läuft, ist gleichgültig. Ob Ihr Formular Eingaben prüft, ist gleichgültig. Angegriffen wird die Schicht darunter.

Umgekehrt heißt das auch: Es gibt nichts, was Sie an Ihrer Anwendung reparieren könnten. Die einzige vollständige Lösung ist das Update.

Keine davon braucht einen Entwickler. Ihr Hoster kann sie alle beantworten – und wenn er es nicht zügig tut, wissen Sie auch etwas.

• Welche PHP-Version läuft auf jeder Ihrer Seiten? Nicht welche Sie meinen, sondern welche tatsächlich ausgeliefert wird. Und zwar pro Seite, nicht pro Server – auf einem Host laufen oft mehrere Versionen nebeneinander.
• Ist sie schon gepatcht? Maßgeblich sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Eine höhere Hauptnummer allein genügt nicht: 8.4.20 ist neuer als 8.3.36 und trotzdem verwundbar.
• Wer spielt das Update ein, und wann? Bei verwalteten Hostings ist das der Anbieter – fragen Sie nach einem Termin, nicht nach einer Absichtserklärung. Bei eigenen Servern sind Sie es. Linux-Distributionen haben die Patches vorab bekommen, oft liegt das Paket schon bereit.
• Gibt es Systeme, an die gerade niemand denkt? Alte Testumgebungen, eine Subdomain von vor drei Jahren, das Kundenportal eines eingestellten Projekts. Erreichbar ist erreichbar. Das sind erfahrungsgemäß die Systeme, über die ein Angriff läuft – nicht die Hauptseite, die jeder im Blick hat.

Für PHP 8.1, 8.0 und 7.4 gibt es vom Projekt keine regulären Updates mehr. Es existieren minimale Backports genau für diese beiden Lücken, aber das ist eine Notmaßnahme und keine Lösung – bei der nächsten Meldung stehen Sie wieder da, wo Sie heute stehen. Auch der 8.2er-Zweig endet zum 31. Dezember 2026.

Genau hier wird es für Betriebe unserer Größenordnung unangenehm. In einem Haus mit vierzig Leuten gibt es fast immer eine Anwendung, die seit Jahren läuft, die niemand mehr betreut und deren ursprünglicher Dienstleister nicht mehr erreichbar ist. Solange nichts passiert, kostet sie nichts. An einem Tag wie diesem wird sie zum teuersten System im Haus.

Bei uns hat dieser Tag so ausgesehen: Advisory gelesen, alle eigenen Systeme durchgesehen und sämtliche bei uns gehosteten Seiten auf die gepatchten Versionen gebracht. Das ist keine besondere Leistung, sondern der Normalfall – es ist nur die Frage, ob jemand dafür zuständig ist.

Eine Meldung mit CVSS 9.2 verleitet dazu, Grundsätzliches zu beschließen. Davon raten wir ab – zumindest diese Woche.

• Jetzt keine Migration anstoßen, die Sie nicht geplant hatten. Eine PHP-Version zu aktualisieren ist eine Sache von Stunden. Ein System abzulösen dauert Monate. Wer beides vermischt, steht in vier Wochen immer noch auf der verwundbaren Version – nur mit einem laufenden Projekt dazu.
• Nicht den Anbieter wechseln, weil er noch nicht gepatcht hat. Fragen Sie zuerst nach dem Termin. Ein Hoster, der innerhalb von Tagen aktualisiert, arbeitet normal. Einer, der auf eine konkrete Frage keine konkrete Antwort gibt, ist das eigentliche Problem – und das war er schon vor dieser Lücke.
• Sich nicht auf Behelfslösungen verlassen. Das Advisory nennt Konfigurationen, die die Angriffsfläche verkleinern, wenn ein Update kurzfristig unmöglich ist. Es sagt ausdrücklich dazu, dass sie eine Installation nicht sicher machen. Als Brücke für ein Wochenende in Ordnung, als Zustand nicht.

• PHP.net – Sicherheitswarnung vom 21. Oktober 2026
• CVE-2026-109618 – RCE durch OOM-Korruption (GHSA-w8hw-w9fx-j79w)
• CVE-2026-109619 – RCE durch veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp)
• PHP – Downloads und unterstützte Versionen