Am 21. Oktober 2026 veröffentlichte das PHP-Entwicklungsteam Sicherheitsupdates für zwei kritische Schwachstellen in der PHP-Laufzeitumgebung. Beide können unter verwundbaren Bedingungen eine nicht authentifizierte Ausführung von Code aus der Ferne ermöglichen. Für Teams, die PHP-Anwendungen betreiben, besteht die unmittelbare Aufgabe darin, betroffene Installationen zu identifizieren und die passenden Updates einzuspielen.
Daraus ergibt sich auch eine grundsätzliche Erkenntnis für die Softwareentwicklung. Eine Webanwendung ist nicht allein deshalb sicher, weil ihr Framework, ihre Plugins und ihre Anwendungsabhängigkeiten auf dem neuesten Stand sind. Die Laufzeitumgebung, das Container-Image, die Serverkonfiguration und der Deployment-Prozess bleiben während der gesamten Lebensdauer der Anwendung Teil ihrer Sicherheitsgrenze.
Diese Unterscheidung ist für jede Organisation relevant, die eine Laravel-Anwendung, ein CMS, ein Kundenportal oder ein individuell entwickeltes PHP-Backend betreibt.
Was ist im Oktober 2026 passiert?
Die Sicherheitsmitteilung des PHP-Projekts benennt zwei Schwachstellen, die jeweils mit 9,2 nach CVSS v4.0 bewertet wurden:
- CVE-2026-109618 betrifft die Speicherverwaltung bei Speichermangel. In bestimmten Situationen kann eine abgebrochene Anfrage interne Anfragedaten in einem nur teilweise initialisierten Zustand hinterlassen. Beim anschließenden Aufräumen kann dies zu unsicherem Verhalten führen.
- CVE-2026-109619 betrifft veraltete interne Zustandsdaten. Daten einer Anfrage können weiterhin erreichbar bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Dies kann eine nachfolgende Anfrage betreffen, die derselbe Worker verarbeitet.
Die Sicherheitskorrekturen wurden in folgenden PHP-Versionen veröffentlicht:
| PHP-Versionszweig | Korrigierte Upstream-Version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Die Sicherheitsmitteilung betrifft PHP-Installationen, die Webanfragen verarbeiten, darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team stuft mod_php als besonders risikoreiche Konfiguration ein, weil ein demonstrierter Exploit bereits vor der Ausführung von Anwendungscode wirksam werden kann. Das bedeutet jedoch nicht, dass jedes Deployment gleich stark gefährdet ist oder eine Ausnutzung in jeder Umgebung gleich einfach wäre.
PHP 8.1 und ältere Versionen erhalten keine regulären Sicherheitsupdates mehr vom PHP-Projekt. Einige kommerzielle Supportanbieter und Linux-Distributoren stellen möglicherweise zurückportierte Korrekturen bereit. Administratoren sollten deshalb die Sicherheitsmitteilungen ihres Anbieters prüfen und sich nicht allein auf die Versionsnummer verlassen. Zudem nähert sich PHP 8.2 seinem Upstream-Supportende am 31. Dezember 2026. Neben dem unmittelbaren Patch ist daher auch die Planung eines Versionsupgrades wichtig.
Am 23. Oktober veröffentlichte PHP separate Hinweise zur Funktion für den Session-Upload-Fortschritt. Darin wird ein weiterer potenzieller Weg zur Ausführung von Code aus der Ferne beschrieben: CVE-2026-115560. Er setzt eine ungewöhnliche Kombination aus der Konfiguration des Session-Serializers und dem Verhalten der Anwendung zur Laufzeit voraus. Das PHP-Projekt empfiehlt, session.upload_progress.enabled in betroffenen Konfigurationen zu deaktivieren, bis eine reguläre Veröffentlichung das Problem behebt. Dieses Problem ist von den beiden am 21. Oktober behobenen Schwachstellen zu unterscheiden und darf nicht als allgemein ausnutzbar dargestellt werden.
Eine unabhängige Einschätzung aus dem europäischen öffentlichen Sektor bietet die aktualisierte PHP-Sicherheitsmitteilung von CERT-EU.
Warum ein Update von Laravel oder einem CMS nicht ausreicht
Stellen wir uns eine Laravel-Anwendung mit aktuellen Abhängigkeiten, aktueller Authentifizierungs-Middleware und soliden Zugriffskontrollen vor. Sie kann dennoch von einem älteren PHP-FPM-Prozess oder einem Container-Image ausgeführt werden, das vor den Sicherheitsveröffentlichungen erstellt wurde.
In diesem Fall haben der Anwendungscode und die zugrunde liegende Ausführungsumgebung unterschiedliche Sicherheitsstände. Ein Composer-Update aktualisiert PHP-Pakete. Es aktualisiert nicht automatisch den PHP-Interpreter auf dem Server.
Dieselbe Unterscheidung gilt für WordPress, Statamic und individuell entwickelte PHP-Systeme. Ein CMS-, Framework- oder Plugin-Update kann ein Update der PHP-Laufzeitumgebung nicht ersetzen. Umgekehrt entfällt durch das Patchen von PHP nicht die Notwendigkeit, die Anwendung, ihre Abhängigkeiten und ihre Konfiguration zu pflegen.
Deshalb muss Softwaresicherheit als Verantwortung für den gesamten Stack verstanden werden:
Anwendung und Abhängigkeiten → PHP-Laufzeitumgebung → Webserver oder Container → Betriebssystem und Infrastruktur.
Jede Ebene hat eigene Updatemechanismen, Deployment-Schritte und mögliche Fehlerquellen. Ein sicherer Release-Prozess braucht Transparenz über alle diese Ebenen.
Was Teams in der Produktionsumgebung prüfen sollten
Die erste Herausforderung bei einem solchen Vorfall ist häufig nicht die Installation eines Patches. Vielmehr gilt es genau festzustellen, wo die verwundbare Laufzeitumgebung tatsächlich eingesetzt wird.
- Die eingesetzten Laufzeitumgebungen erfassen. Prüfen Sie öffentliche Anwendungen, interne Werkzeuge, API-Dienste, Staging-Umgebungen und weitere Dienste, die PHP nutzen. Nehmen Sie auch Hintergrund-Worker und geplante Aufgaben in das Inventar auf, selbst wenn diese nicht direkt über Webanfragen erreichbar sind. Ermitteln Sie für jede Workload, ob sie PHP-FPM, mod_php, CLI-Worker oder eine andere Integration verwendet.
- Den Anbieter der PHP-Binärdateien ermitteln. Ein Managed-Hosting-Anbieter, eine Linux-Distribution, ein Docker-Basisimage, ein Control Panel und eine aus dem Quellcode erstellte PHP-Installation können jeweils unterschiedliche Updatewege haben. Lesen Sie bei Paketen mit Anbieterunterstützung die konkrete Sicherheitsmitteilung des Anbieters. Ein korrigiertes Distributionspaket kann eine älter wirkende Versionsnummer behalten, weil Sicherheitskorrekturen zurückportiert wurden.
- Bei Bedarf neu bauen und bereitstellen. Eine Änderung am Dockerfile oder das Herunterladen eines neueren Basisimages ersetzt noch keinen Container, der bereits in der Produktion läuft. Bauen und testen Sie das neue Image, stellen Sie es bereit und sorgen Sie dafür, dass die bisherigen verwundbaren Workloads entfernt oder neu gestartet werden. Sind Images über einen Digest festgelegt, aktualisieren Sie diesen gezielt. Gehen Sie nicht davon aus, dass ein veränderlicher Tag die laufende Software automatisch geändert hat.
- Die tatsächlich für Webanfragen verwendete Laufzeitumgebung verifizieren. Eine lokale Ausgabe von
php -vhilft dabei, eine CLI-Installation zu identifizieren. Sie belegt für sich genommen jedoch nicht, welche PHP-Laufzeitumgebung der Webserver verwendet. Prüfen Sie für jeden produktiven Dienst, einschließlich PHP-FPM-Pools und Containern, die tatsächlich eingesetzte Laufzeitversion und den Paket-Build über angemessen abgesicherte betriebliche Prüfungen. Stellen Sie nicht eigens eine öffentlichephpinfo()-Diagnoseseite bereit, nur um die Version zu bestätigen. - Die Anwendung nach dem Deployment prüfen. Führen Sie Anwendungs- und Integrationstests aus, prüfen Sie Fehler und Logs, bestätigen Sie die Funktion von Routen und Hintergrundaufgaben und überwachen Sie den Rollout. Das Ziel ist nicht nur eine erfolgreiche Paketinstallation. Es ist ein gepatchter, funktionierender produktiver Dienst mit nachvollziehbarer Verifikation.
Diese Schritte gehören zum Deployment Engineering. Sie ersetzen weder spezialisierte Penetrationstests noch eine umfassende Sicherheitsbewertung.
Was tun, wenn ein sofortiges Update nicht möglich ist?
Die Position des PHP-Projekts ist eindeutig: Ein Update auf eine korrigierte Version oder die Anwendung der passenden Korrektur des Anbieters behebt die Schwachstellen vom 21. Oktober vollständig. Die veröffentlichten Konfigurationsmaßnahmen verringern die Angriffsfläche für bestimmte Angriffswege, machen eine ungepatchte Installation aber nicht sicher.
Wenn sich ein Patch nicht zeitnah bereitstellen lässt, sollten Teams eine Risikobewertung durchführen und erwägen, den Zugriff auf betroffene, aus dem Internet erreichbare Dienste einzuschränken oder diese zu isolieren, bis eine verifizierte Korrektur angewendet werden kann. Änderungen an Anfragegrenzen, Speichereinstellungen oder der Funktion für den Session-Upload-Fortschritt sollten sich nach der Sicherheitsmitteilung des PHP-Projekts richten und anhand des tatsächlichen Anwendungsverhaltens getestet werden. Sie sind weder universelle Konfigurationsrezepte noch ein Ersatz für Patches.
Ein weiterer betrieblicher Aspekt ist die Zuständigkeit. Es muss klar sein, welche Systeme betroffen sind, wer die Änderung bereitstellen kann, wie sie getestet wird und wie die erfolgreiche Behebung bestätigt wird. Ohne diese Klarheit wird selbst eine öffentlich verfügbare Sicherheitskorrektur unter Umständen nicht eingespielt.
Sicherheit endet nicht mit dem Deployment
Die PHP-Schwachstellen vom Oktober zeigen beispielhaft, warum produktive Software über ihren gesamten Lebenszyklus gepflegt werden muss. Ein System kann zum Start korrekt implementiert sein und später durch einen neu entdeckten Fehler in der Laufzeitumgebung, ein veraltetes Image oder einen vernachlässigten Dienst gefährdet werden.
Für Softwareteams ergeben sich daraus fortlaufende Aufgaben: ein verlässliches Inventar der eingesetzten Komponenten pflegen, die zuständigen Updateanbieter kennen, getestete Patch- und Rollback-Verfahren etablieren, Produktionsumgebungen überwachen und Upgrades planen, bevor Abhängigkeiten ihr Supportende erreichen.
Bei Cognivox Labs verbindet diese Perspektive unsere Arbeit im Backend & API Engineering mit dem Cloud & DevOps Engineering. Die Anwendungslogik und die Umgebung, in der sie ausgeführt wird, sollten als Teile desselben Systems entworfen, bereitgestellt und gepflegt werden. Unser früherer Artikel über Laravel im Jahr 2026 behandelt die Stärken des Frameworks in der Anwendungsentwicklung. Der PHP-Vorfall verdeutlicht, warum die Sicherheit im Betrieb neben diesen Stärken eine wichtige Rolle spielt.
Das Thema ist besonders aktuell, da die it-sa Expo&Congress 2026 diese Woche in Nürnberg stattfindet. Sichere Softwarebereitstellung bedeutet nicht nur, Schwachstellen in neuem Code zu vermeiden. Sie hängt auch davon ab, wie Teams die bereits produktiv eingesetzte Infrastruktur und Software betreuen.
Für Organisationen, die eine bestehende PHP-Anwendung überprüfen oder eine neue planen, ist eine sachliche technische Bestandsaufnahme oft der richtige Ausgangspunkt: Was läuft, wie wird es bereitgestellt, wer pflegt es und was passiert, wenn ein kritisches Update veröffentlicht wird?
