PHP CVE-2026-109618 & CVE-2026-109619: Was jetzt zählt

Am 20. Oktober 2026 hat das PHP-Sicherheitsteam eine Vorabankündigung veröffentlicht: Für Mittwoch, den 21. Oktober 2026, 14:00 UTC, also 16:00 Uhr deutscher Zeit, ist ein Sicherheitsrelease geplant. Er adressiert zwei kritische Schwachstellen; PHP bewertet beide mit CVSS v4.0 9.2 1 . Das ist der Grund, warum der Fall gerade Betreiber von Web-Servern erreicht, nicht nur Sicherheitsteams.

Die konkrete Aufgabe für die nächsten Stunden ist überschaubar und lässt sich in drei Schritten zusammenfassen: erstens herausfinden, wo überhaupt PHP läuft, zweitens den Patch-Kanal festlegen und drittens dort, wo kein sofortiges Update möglich ist, die exponierte Anwendung vom öffentlichen Netz trennen. Was man dagegen noch nicht kann, ist patchen: Die gefixten Versionen erscheinen erst mit dem Release, zusammen mit den betroffenen Versionen 1 . Dieser Artikel trennt, was bestätigt ist, was noch offen bleibt und welche Schritte sich bereits jetzt erledigen lassen.

Kurzantwort
#

PHP kündigt zwei kritische Sicherheitslücken an (CVSS 9.2). Faktenstand, Risiko und eine konkrete Update-Checkliste vor der Freigabe am 21.10., 16:00 Uhr.

Der Stand der Fakten
#

Verlässlich und offiziell ist bislang nur wenig, aber dieses Wenige ist eindeutig. PHP hat am 20. Oktober 2026 eine Vorabankündigung unter dem Titel „Upcoming Critical PHP Security Release" veröffentlicht 1 . Darin nennt das Team zwei kritische Schwachstellen, beide mit CVSS v4.0 9.2 bewertet, und einen festen Termin: 21. Oktober 2026, 14:00 UTC. Wörtlich hält PHP fest, dass vollständige Details, betroffene Versionen und gefixte Versionen erst mit dem Release veröffentlicht werden 1 .

Eine zweite offizielle Aussage stammt von CERT-EU. Das europäische CERT hat die Security Advisory 2026-018 mit dem Titel „Critical Vulnerabilities in PHP" veröffentlicht (Release Date 20. Oktober 2026, 20:33 UTC; History: „21/10/2026 — v1.0 – Initial publication") 4 . Darin steht, dass am 20. Oktober 2026 eine Ankündigung des PHP-Projekts über einen bevorstehenden Sicherheitsrelease erfolgte, der zwei Schwachstellen adressiert, die zu Remote Code Execution führen können. CERT-EU betont ausdrücklich, dass zum Zeitpunkt der Veröffentlichung keine technischen Details öffentlich waren 4 . Im Abschnitt „Affected Products" übernimmt CERT-EU die Einschätzung, dass die Lücken „alle PHP-Versionen ab PHP 5" betreffen könnten, und verweist dafür auf einen Post von @GossiTheDog auf cyberplace.social 4 .

Die dritte offizielle Spur sind die CVE-Einträge selbst. CVE-2026-109618 und CVE-2026-109619 sind bei der CVE-Datenbank weiterhin als „RESERVED" geführt 2 , 3 . Ein reservierter Eintrag bedeutet, dass die Nummer vergeben ist, aber Beschreibung, betroffene Produkte und Referenzen noch nicht veröffentlicht wurden. Wer jetzt in der CVE-Datenbank nach technischen Details sucht, findet nichts, weil es dort noch nichts zu finden gibt.

Zu einem weiteren Punkt gibt es belastbare Berichte, aber keine offizielle Bestätigung: Ars Technica berichtet über ein kursierendes Demonstrationsvideo zu einem Werkzeug namens „PHP2Shell". Der Bericht stützt sich ausdrücklich auf ein nicht verifiziertes Leak; die Originalquelle war nicht auffindbar 9 . Das Video ist deshalb kein unabhängig prüfbarer Nachweis für reproduzierbaren Exploitcode und belegt keine aktive Ausnutzung. Es liefert aber einen weiteren Grund, die vom PHP-Projekt angekündigte Veröffentlichung nicht abzuwarten, sondern die Patch-Vorbereitung jetzt abzuschließen.

Dazu kommt eine Schicht aus unbestätigten Meldungen, die am 20. Oktober 2026 durchsickerte. Sansec schreibt, die Lücken beträfen alle Web-Server mit PHP 5.4 oder neuer, und erwartet innerhalb von 15 Minuten nach dem Release Massenangriffe 5 . watchTowr (über dessen X-Post, auf den CERT-EU referenziert 4 ) und GossiTheDog (cyberplace.social, ebenfalls CERT-EU-Referenz 4 ) bestätigen, dass es sich um Remote-Code-Execution-Schwachstellen handeln soll, und benennen eine Reichweite ab PHP 5; keine dieser Reichweitenangaben ist bisher vom PHP-Projekt selbst bestätigt worden 5 , 6 . Diese Angaben sind Einschätzungen und Leaks, keine bestätigten Fakten. Sie verdienen Beachtung, weil sie die Dringlichkeit erklären, aber sie ersetzen die offizielle Versionsangabe nicht. Hinweis: Die watchTowr-Blogseite selbst war zum Zeitpunkt dieser Recherche (21.10.2026, vormittags) hinter einem Anti-Bot-Schutz nicht direkt abrufbar; beruht wird auf das, was Sekundärquellen und CERT-EU-Zitate wiedergeben.

Zeitlicher Ablauf
#

Der Fall lässt sich auf eine kurze Abfolge von drei Ereignissen verdichten, die alle belegt sind. Am 20. Oktober 2026 tauchten auf Hacker News und in Social Media unbestätigte Hinweise auf zwei bevorstehende PHP-Schwachstellen auf; Sansec datiert den ersten derartigen Hinweis auf den 20. Oktober, 15:20 UTC 5 . Noch am selben Tag veröffentlichte PHP die offizielle Vorabankündigung mit dem Termin und der Bewertung 9.2 1 . Der dritte Termin steht noch aus: der Release selbst am 21. Oktober 2026, 14:00 UTC 1 .

Zwischen diesen Punkten liegt eine Besonderheit. Üblich ist, dass Hersteller Details und Fix gleichzeitig veröffentlichen. Hier lief die Reihenfolge andersherum: erst das Leck, dann die Bestätigung des Termins, dann, mit Abstand, die technischen Details. Für Betreiber bedeutet das, dass die Zeitspanne bis zum Release die einzige ist, in der sich Vorbereitung ohne den Druck eines bereits öffentlichen Exploits erledigen lässt.

Was noch fehlt
#

Der eigentliche Kern des Falls ist noch unbekannt, und das sollte man so stehen lassen, statt es zu erraten. Nicht bestätigt sind bislang:

die technische Ursache der beiden Schwachstellen,
die exakte Liste betroffener Versionen,
die Versionsnummern der Fixes,
ob eine der Lücken aktiv ausgenutzt wird.

Zu allen vier Punkten gibt es keine offizielle Aussage. Eine am 21.10.2026 vormittags aktualisierte CISA-KEV-Liste (catalogVersion 2026.10.20) enthält die beiden CVE-Nummern nicht 7 . Das ist eine Momentaufnahme, keine Garantie; eine Aufnahme in die KEV-Liste erfolgt typischerweise erst nach bestätigter aktiver Ausnutzung.

Die CVSS-Bewertung 9.2 kommt aus der Ankündigung von PHP selbst 1 . CERT-EU ordnet sie so ein, dass ein Wert dieser Höhe auf unauthentifizierte Remote Code Execution hindeutet 4 . Konkret heißt das in der Praxis: Ein Angreifer, der sich nicht anmelden muss, könnte Code auf dem Server ausführen und den Rechner potenziell übernehmen. Mehr lässt sich aus der Zahl nicht ableiten, und genau deshalb ist die Versionsangabe beim Release der entscheidende Moment.

Ein Detail aus der Ankündigung verdient besondere Aufmerksamkeit: PHP behält sich ausdrücklich vor, früher zu veröffentlichen, wenn Details zu einer der Schwachstellen öffentlich werden oder Belege für aktive Ausnutzung auftauchen 1 . Wer also davon ausgeht, bis 16:00 Uhr sei ohnehin nichts zu tun, liegt falsch. Die Situation kann sich vorziehen.

Risiko einordnen
#

Remote Code Execution ist besonders folgenreich, weil sie nicht bei einem einzelnen Datenzugriff stehen bleibt. Wer Code auf einem Server ausführen kann, kann in der Regel auch Daten lesen, Persistenz herstellen und von dort weitere Systeme im Netz erreichen. CERT-EU formuliert deshalb nicht die Empfehlung, abzuwarten, sondern die Aufforderung, sich auf sofortiges Patchen vorzubereiten und notfalls zu isolieren 4 .

Für wen das konkret relevant ist, hängt an der noch offenen Versionsliste. Sansec weist darauf hin, dass die Leaks auf eine Reichweite ab PHP 5.4 hindeuten und damit auch weit verbreitete Shop-Systeme treffen würden, darunter Magento-, Shopware- und WooCommerce-Instanzen 5 . Sollte sich diese Reichweite bestätigen, beträfe der Fall nicht einzelne Spezialsysteme, sondern einen großen Teil der serverseitigen Web-Landschaft. Das ist eine Bedingung, keine Tatsache: Entscheidend bleibt, welche Versionen PHP am 21. Oktober offiziell als betroffen nennt 1 .

Was jetzt zu tun ist
#

Die Vorbereitung lässt sich ohne die fehlenden Versionsdetails vollständig erledigen. Es geht darum, am Release-Tag nicht erst mit der Bestandsaufnahme anzufangen.

Schritt 1: Inventar erstellen. Auf jedem Host, der PHP ausführt, die Version ermitteln:

php -v

Auf Debian- oder Ubuntu-Systemen listet der Paketmanager die installierten PHP-Pakete:

dpkg -l | grep -E '^ii.*php'

Auf RHEL, Rocky oder Alma Linux entsprechend:

rpm -qa | grep -i php

Bei Containern zählt das Basis-Image: Ein Image wie php:8.2-apache trägt die Version im Namen, aber nur das tatsächlich gebaute Image zählt. Hier hilft docker images oder ein Blick in die Build-Datei. Entscheidend ist am Ende eine Liste: Welcher Host, welche PHP-Version, welche Anwendung, wie exponiert.

Schritt 2: Exposition feststellen. Für jede PHP-Anwendung gehört die Frage dazu, ob sie aus dem Internet erreichbar ist. Dafür reicht ein Blick in die Konfiguration des Reverse Proxy oder Load Balancers: Welche virtuellen Hosts lauschen auf öffentlichen Ports 80 und 443, und welche davon leiten Anfragen an PHP weiter. Eine interne Anwendung ohne öffentlichen Eintrittspunkt ist vom RCE-Risiko über das Netz deutlich weniger betroffen, auch wenn sie nicht schutzlos ist.

Schritt 3: Patch-Kanal festlegen. Es gibt drei typische Wege, und jeder hat einen anderen Ablauf. Wer PHP über die Distribution bezieht (apt, dnf), wartet auf das Paket der Distribution und spielt es über den üblichen Update-Weg ein. Wer offizielle PHP-Builds nutzt, lädt nach dem Release die neue Version von php.net. Wer Container einsetzt, baut die Images mit der gefixten Basis neu und rollt sie aus. Der Kanal sollte vor dem Release feststehen, nicht erst beim Release.

Schritt 4: Rückweg vorbereiten. Ein Sicherheitspatch auf einem produktiven Server verdient einen Snapshot oder zumindest ein Backup der Konfiguration und der Datenbank, bevor er eingespielt wird. Das kostet wenig und macht das Update umkehrbar, falls eine Anwendung nach dem Versionssprung nicht mehr startet.

Schritt 5: Benachrichtigung einrichten. Wer mehrere Server betreibt, sollte am 21. Oktober ab 14:00 UTC die Ankündigungsseite von php.net beobachten oder einen entsprechenden Feed abonniert haben 1 . Dort stehen die betroffenen und die gefixten Versionen zuerst. Ergänzend empfiehlt sich der Blick in die CISA-KEV-Liste und die einschlägigen CVE-Records ab dem Release-Zeitpunkt 7 , 2 , 3 .

Beim Release
#

Sobald die Ankündigung um 14:00 UTC da ist, ändert sich die Reihenfolge: zuerst die offizielle Versionsangabe lesen, dann handeln.

Der erste Blick gilt den betroffenen Versionen. Erst wenn feststeht, dass die eigene Version betroffen ist, ist das Update ein Muss. Die gefixten Versionen stehen in derselben Meldung 1 . Danach gilt die übliche Reihenfolge: Paketquelle aktualisieren, Update einspielen, Dienst neu starten und die neue Version verifizieren:

php -v

Ein Neustart von PHP-FPM oder des Webservers ist nötig, damit die neue Binärdatei tatsächlich geladen wird. Ein laufender Prozess behält sonst die alte, verwundbare Version im Speicher. Nach dem Update gehört der Funktionstest der Anwendung dazu, nicht nur der Versionscheck: Eine Anwendung, die nach dem Patch nicht mehr antwortet, ist das kleinere Übel gegenüber einer ungepatchten, aber beides ist ein Ausfall, den man bemerken sollte.

Für Systeme, auf denen das Update nicht sofort möglich ist, nennt CERT-EU eine klare Alternative: exponierte Anwendungen bis zum Einspielen des Fixes vom öffentlichen Netz trennen 4 . Das ist keine Empfehlung am Rand, sondern der zentrale Handlungsauftrag der Advisory für genau den Fall, dass sofortiges Patchen nicht geht.

Die Support-Falle: PHP 8.1 und älter
#

Hier liegt ein Entscheidungspunkt, den viele Betreiber unterschätzen. Offizielle Sicherheitsfixes erhalten nur noch die unterstützten PHP-Zweige. Sansec fasst es so zusammen: PHP unterstützt nur noch Version 8.2 und neuer, und Systeme auf PHP 8.1 oder älter bekommen keinen offiziellen Fix 5 . Die offizielle Supported-Versions-Seite bestätigt diesen Rahmen: Aktuell als unterstützt geführt werden die Zweige 8.2, 8.3, 8.4 und 8.5, die alle vier in der Sicherheitsfixes-only-Phase stehen; 8.6 steckt mit Stand 8. Oktober 2026 als RC3 in der Testphase, RC4 ist für den 22. Oktober 2026 geplant 1 , 8 .

Für Betreiber auf PHP 8.1 oder älter bedeutet das: Es gibt keinen Patch, auf den man einfach wartet. Die Optionen sind dann, die Anwendung auf eine unterstützte Version zu heben, beim Distributor einen Backport zu erfragen oder die Anwendung bis zur Migration zu isolieren 5 . Das ist ein anderer Aufwand als ein Paket-Update, und genau deshalb gehört die Versionsprüfung vor den Release-Tag, nicht dahinter.

Die Entscheidung zwischen diesen Optionen hängt an zwei Fragen: Wie schnell lässt sich die Anwendung gegen eine unterstützte PHP-Version testen, und wie groß ist der Schaden, wenn der Dienst vorübergehend nicht erreichbar ist. Wer eine Migration nicht innerhalb weniger Tage schafft, für den ist die Isolation der realistische Weg, auch wenn sie einen sichtbaren Ausfall bedeutet.

Isolieren, wenn kein Patch möglich ist
#

Die Isolations-Empfehlung von CERT-EU 4 lässt sich technisch auf mehreren Ebenen umsetzen, und die Wahl hängt von der eigenen Infrastruktur ab.

Die einfachste Variante ist ein Wartungsmodus auf der Anwendungsebene: Der Reverse Proxy oder Load Balancer beantwortet Anfragen mit einer statischen Wartungsseite, während der eigentliche PHP-Dienst nicht mehr erreichbar ist. Das schützt nur, wenn wirklich kein PHP-Code mehr antwortet; eine Wartungsseite, hinter der PHP weiterläuft, schützt nichts.

Die robustere Variante ist die Trennung auf Netzebene. Eine Firewall-Regel oder ein eigenes Netzsegment stellt sicher, dass die betroffene Anwendung von außen nicht mehr angesprochen werden kann. Für kleinere Umgebungen reicht ein dediziertes Gateway oder ein Segment, das nur noch interne Verbindungen zulässt. Für größere Umgebungen ist das ohnehin die sauberste Lösung, weil sie unabhängig von der Anwendung greift und auch dann hält, wenn die Applikation selbst kompromittiert ist.

In beiden Fällen gilt dieselbe Prüfung: Nach dem Isolieren muss ein Test von außen zeigen, dass der Dienst tatsächlich nicht mehr erreichbar ist. Eine Regel, die nur auf dem Papier existiert, ist keine Isolation. Der Test gehört nicht in das interne Netz, sondern auf eine Verbindung, die den Weg eines echten Besuchers nimmt, etwa über ein Mobilfunknetz oder einen zweiten Anschluss.

Aktive Ausnutzung erkennen
#

Sobald die Details öffentlich sind, ändert sich das Bedrohungsbild: Aus einer theoretischen Lücke wird ein realer Angriffsweg. Sansec erwartet bereits innerhalb von 15 Minuten nach dem Release erste Angriffswellen 5 . Deshalb gehört in die Tage nach dem Release auch ein kurzer Blick auf Anzeichen, die auf einen erfolgreichen Angriff hindeuten.

Drei Indikatoren sind ohne Spezialwerkzeug prüfbar. Erstens ungewöhnliche Dateien im Webverzeichnis oder in Verzeichnissen, in denen PHP schreiben darf: Eine hochgeladene Datei mit auffälligem Namen ist ein klassisches Anzeichen. Zweitens unerwartete Prozesse oder ausgehende Verbindungen des Web-Servers, der normalerweise keine Verbindungen nach außen aufbaut. Drittens auffällige Muster in den Zugriffsprotokollen, etwa wiederholte Anfragen an einzelne URLs mit ungewöhnlichen Parametern. Keiner dieser Indikatoren beweist für sich einen Angriff, aber zusammen rechtfertigen sie eine genauere Prüfung.

Diese Prüfung ersetzt das Patchen nicht. Sie hilft, einen bereits erfolgten Angriff zu bemerken, was nach einem kritischen RCE-Fall ein eigenständiges Ziel ist: Wer nur patcht und nicht prüft, lässt eine möglicherweise bereits gesetzte Hintertür stehen.

Admin-Zugänge absichern
#

Ein Punkt, der bei einem RCE-Fall leicht untergeht: Wer die Server patcht, meldet sich selbst mit administrativen Rechten an. Genau diese Zugänge sind das Ziel, sobald ein Angreifer auf einem kompromittierten System nach Wegen sucht, sich auszubreiten.

Deshalb gehört vor dem Release-Tag auch der Blick auf die eigenen Admin-Zugänge. SSH-Logins mit Passwort sind der schwächste Punkt. Die Reihenfolge der Verbesserung ist klar: Passwortanmeldung deaktivieren, Login nur per Schlüssel erlauben und den Schlüssel selbst mit einer zweiten, hardwaregestützten Stufe schützen. FIDO2-Sicherheitsschlüssel eignen sich dafür, weil der private Schlüssel das Gerät nicht verlässt und ein gestohlenes Passwort allein nicht mehr reicht. OpenSSH unterstützt solche Hardware-Schlüssel direkt; der zugehörige Schlüsseltyp wird beim Erzeugen des Keys gewählt, und der Server akzeptiert ihn wie jeden anderen öffentlichen Schlüssel.

Das hilft nicht gegen die PHP-Schwachstelle selbst, aber es verkleinert den Schaden, falls ein Server in den kommenden Tagen doch betroffen sein sollte. Der konkrete Nutzen liegt im Übrigen auch im Normalbetrieb: Der Patch muss auf vielen Servern eingespielt werden, und wer dabei über unsichere Zugänge geht, eröffnet Angreifern genau in dem Moment eine Tür, in dem alle hinschauen.

Einordnung
#

Der ungewöhnlichste Teil dieses Falls ist nicht die Bewertung 9.2, sondern die Vorabankündigung. Üblich ist, dass ein Sicherheitsrelease zusammen mit den Details erscheint. Hier kündigt PHP den Termin vorab an, nennt die Schwere, hält aber alle Details zurück 1 . Das ist für Betreiber ein Vorteil: Man hat Zeit, die Bestandsaufnahme zu machen, bevor die Lücke öffentlich wird.

Der Preis dafür ist Unsicherheit. Ohne die betroffenen Versionen lässt sich nicht sagen, ob die eigene Umgebung überhaupt betroffen ist, und ohne Fix gibt es nichts zu installieren. Beides löst sich am 21. Oktober um 14:00 UTC auf 1 . Bis dahin ist die sinnvolle Haltung Vorbereitung statt Panik: Inventar erstellen, Kanal festlegen, Rückweg sichern, und dort, wo kein schnelles Update möglich ist, die Isolation vorbereiten.

Wer die drei Dinge vor 16:00 Uhr deutscher Zeit erledigt hat, ist für beide Ausgänge gerüstet: für den Fall, dass die eigene Version betroffen ist, und für den Fall, dass sie es nicht ist. Mehr lässt sich vor der Freigabe nicht tun, und weniger sollte man nicht tun.

Weiterführende Artikel
#

Passende Produktrecherchen
#

Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:

Yubico – 2 Pack – YubiKey 5 NFC – Sicherheitsschlüssel für Zwei-Faktor-Authentifizierung (2FA), USB-A und NFC – Betreiber, die ihre Server-Admin-Zugänge mit FIDO2-MFA absichern wollen – Hardwaregestützte zweite Stufe für SSH- und Admin-Logins auf den Servern, die beim PHP-Update gepatcht und gewartet werden
Yubico – YubiKey 5C NFC FIPS (140-3) – Sicherheits- und Passkey-Token für MFA, USB-C und NFC – Admins mit USB-C-Arbeitsgeräten oder höherem Zertifizierungsanspruch an den Sicherheitsschlüssel – FIPS-zertifizierte Variante mit USB-C für Notebooks und moderne Server-Ports; gleiche SSH-MFA-Funktion in höherer Zertifizierungsstufe
GL.iNet GL-MT2500A Brume 2 – kabelgebundenes VPN-Sicherheitsgateway, 2,5G WAN – Betreiber kleinerer Server-Umgebungen, die eine kabelgebundene Netzsegmentierung ohne Reiserouter-Funktionen brauchen – Dediziertes Gateway, um exponierte PHP-Anwendungen bis zum Patch auf ein eigenes Netzsegment zu legen (CERT-EU-Isolationsempfehlung)
GL.iNet GL-MT3000 Beryl AX – WLAN-6-Router, 2,5G WAN, VPN, OpenWrt – Betreiber, die ein kleines, stromsparendes Segment-Gateway für die Isolationsphase suchen – Kompaktes Gateway mit OpenWrt, um eine Anwendung testweise in einem abgeschotteten Segment zu betreiben oder per VPN-Wartungszugang zu erreichen
GL.iNet GL-MT6000 (Flint 2) – WiFi-6-Router, 2 x 2,5G-Multi-Gig plus 4 x 1G-Ethernet – Betreiber mit mehreren Servern oder höherem Durchsatz, die ein leistungsfähigeres Segment-Gateway benötigen – Höherwertige Option mit mehreren Multi-Gig-Ports für die Segmentierung größerer Umgebungen oder als VPN-Gateway für das Patch-Management mehrerer Hosts
Starlink-Verfügbarkeit und Konditionen prüfen

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.

Grenzen der Einordnung
#

Die Quellen beschreiben den Stand zum Zeitpunkt der Recherche. Sie ersetzen keine Prüfung im konkreten Einsatz; Konfiguration, Voraussetzungen und lokale Rahmenbedingungen können Ergebnisse verändern. Vor wichtigen Entscheidungen sollten Leserinnen und Leser die genannten Primärquellen erneut prüfen.