PHP und Node.js: die Sicherheitslücken vom Oktober 2026

Am 21. Oktober 2026 haben wir Hunderte von Diensten in Containern, Node.js-Umgebungen und PHP-Anwendungen geprüft und alle exponierten noch am selben Tag aktualisiert. Danach haben wir die tatsächlich laufenden Prozesse kontrolliert, Tausende automatisierter Tests auf isolierten Kopien der Anwendungsumgebungen durchlaufen lassen und die Produktiv-Endpunkte überwacht, bis sie ausschließlich korrekte HTTP-Antworten lieferten. Der anspruchsvolle Teil war, Anwendungen, Datenbanken, Rechnungserstellung und Anpassungen funktionsfähig zu halten, während wir die Runtimes austauschten.

Ausgelöst wurde die Arbeit durch zwei getrennte Ankündigungen, die am selben Tag erschienen: kritische Sicherheitslücken in PHP und Sicherheitsupdates mit hohem Schweregrad für Node.js. Beide betreffen die Software, die Anwendungen ausführt. Für ein Unternehmen heißt das: Das Problem kann unterhalb der Website oder der Unternehmenssoftware liegen, auch wenn sich der für das Projekt geschriebene Code nicht verändert hat.

Dies ist der Stand vom 21. Oktober 2026. Die angegebenen Versionen sind diejenigen, die diese Sicherheitsmeldungen beheben; bei einem späteren Update sind auch die nachfolgenden Sicherheitsreleases zu prüfen.

Update vom 26. Oktober: Angriffsversuche vor der Ankündigung

Amazon Threat Intelligence hat in den MadPot-Sensoren am 17. Oktober einen Ausnutzungsversuch von PHP2Shell festgestellt, vier Tage vor der öffentlichen Bekanntgabe am 21. Oktober. Die am 21. Oktober veröffentlichte Analyse meldet zudem Versuche aus mehreren Infrastrukturen vor dem Ende des Embargos. AWS weist darauf hin, dass die technische Analyse noch läuft und nicht feststellt, ob diese Versuche auf realen Systemen erfolgreich gewesen wären.

Das verändert den Zeitraum, den die Kontrollen abdecken müssen: Für einen exponierten Dienst empfiehlt AWS, spätestens ab dem 17. Oktober Logs, unerwartete Prozessausführungen und Dateiänderungen zu prüfen. Den Patch einzuspielen und nach Spuren einer früheren Kompromittierung zu suchen, sind zwei verschiedene Prüfungen. Ein am 21. Oktober abgeschlossenes Update beweist für sich allein nicht, dass das System in den Tagen davor intakt war.

Die PHP-Sicherheitslücken: CVE-2026-109618 und CVE-2026-109619

Die offizielle PHP-Meldung beschreibt zwei Schwachstellen, die eine Remote-Code-Ausführung ohne Authentifizierung ermöglichen können. RCE bedeutet in der Praxis, dass ein Angreifer über eine aus der Ferne erreichbare Schwachstelle Code auf dem System ausführen kann. Dass eine Website ein Login hat, beseitigt kein Problem, das auftreten kann, bevor die Anwendung die Zugangsdaten prüft.

CVE-2026-109618 betrifft den Umgang mit Speichererschöpfung: Einige interne Daten der Anfrage können nur teilweise initialisiert bleiben und beim Aufräumen dann als gültig behandelt werden. Der auf Apache mit mod_php demonstrierte Fall kann ausgelöst werden, bevor der Anwendungscode läuft. Die offizielle Analyse stuft auch PHP-FPM als anfällig ein, mit anderen Angriffswegen und ohne vollständige Demonstration eines FPM-Exploits für diese konkrete Lücke.

CVE-2026-109619 betrifft dagegen internen Zustand, den ein Prozess behalten kann, nachdem der Speicher der vorherigen Anfrage freigegeben wurde. Eine nachfolgende Anfrage kann auf diese inzwischen ungültigen Referenzen zugreifen. Die Bedingungen hängen vom Verhalten des Workers und von den erreichbaren Operationen ab: Jede Installation als bereits kompromittiert zu bezeichnen, wäre falsch – sie ohne Korrektur als sicher zu betrachten, aber ebenso.

Für alle, die eine Website betreiben, ist die praktische Konsequenz klar: Ein Update des CMS oder seiner Plugins kann nötig sein, aber die Behebung dieser Lücken erfordert auch eine aktualisierte PHP-Runtime. Das Problem kann eine individuell entwickelte Unternehmenssoftware genauso treffen wie eine WordPress-Website.

Welche PHP- und Node.js-Versionen die Korrekturen enthalten

Das sind die Upstream-Releases, die die Projekte für die Sicherheitsmeldungen vom 21. Oktober angeben:

Runtime	Zweig	Korrigiertes Release
PHP	8.2	8.2.35
PHP	8.3	8.3.36
PHP	8.4	8.4.27
PHP	8.5	8.5.12
Node.js	22	22.23.4
Node.js	24	24.22.1
Node.js	26	26.12.1

Die Tabelle fasst die PHP-Releases und die Node.js-Sicherheitsmeldung zusammen. Sie ist keine Empfehlung, bei jeder Anwendung auf die höchste Hauptversion zu springen: Zuerst müssen Kompatibilität, Abhängigkeiten und native Erweiterungen geprüft werden.

Ein Detail verändert zudem die Diagnose: Die Upstream-Versionsnummer reicht nicht aus, um ein Linux-Paket zu beurteilen. Eine Distribution kann die Korrektur einspielen und dabei eine scheinbar alte Basisversion beibehalten. Für PHP 8.3 unter Ubuntu 24.04 zum Beispiel nennen die offiziellen Seiten zu CVE-2026-109618 und CVE-2026-109619 das korrigierte Paket 8.3.6-0ubuntu0.24.04.13. Man muss die vollständige Revision und die Sicherheitsmeldung des Anbieters lesen. Dasselbe Prinzip verlangt Vorsicht bei Zweigen ohne Support: Nötig ist eine vom eigenen Anbieter dokumentierte Korrektur oder eine Migration auf einen gepflegten Zweig.

Dieselbe Grenze gilt für Prüfungen von aussen. Unser Sicherheitszensus öffentliche Hand Schweiz prüft täglich rund 2200 Gemeinden, Kantone und Bundesämter ausschließlich anhand öffentlicher Daten und vergleicht passiv die PHP-Version, die eine Website in ihren Headern angibt, mit dem korrigierten Release. Das ist ein nützlicher Hinweis für den Gesamtüberblick, keine Diagnose: Viele Server zeigen ihre Version nicht an, und ein Paket, in das die Distribution die Korrektur eingespielt hat, kann alt aussehen. Um zu wissen, was wirklich läuft, muss man in den Server hineinschauen.

Node.js, Brotli und das Risiko hinter der Komprimierung

Die Node.js-Sicherheitsmeldung vom Oktober enthält CVE-2026-111497, einen als hoch eingestuften Fehler im Brotli-Decoder, der eine Remote-Code-Ausführung ermöglichen kann. Brotli ist ein Komprimierungsformat, das auch im Webverkehr verwendet wird. Die tatsächliche Exposition hängt davon ab, über welche Wege die Anwendung komprimierte Daten verarbeitet, die ein Angreifer kontrollieren kann; dass Node.js installiert ist, beweist für sich allein nicht, dass ein Exploit erreichbar ist.

Dasselbe Release enthält Korrekturen für DNS, die Prüfung von TLS-Zertifikaten und weitere Komponenten. Deshalb haben wir die betroffenen Runtimes aktualisiert und auch Komprimierung, TLS-Initialisierung und Kryptografie geprüft. Ein Test, der Daten korrekt komprimiert und dekomprimiert, prüft die Kompatibilität der neuen Umgebung; der Nachweis, dass der Patch enthalten ist, ergibt sich dagegen aus der korrigierten Version und der verifizierten Herkunft der Software.

Für Anwendungen, die noch auf Node.js 20 laufen, haben wir eine Migration auf einen gepflegten Zweig vorbereitet. Native Erweiterungen verdienen einen eigenen Test: Ein für eine frühere Runtime kompiliertes SQLite-Modul muss bei einem Wechsel der Hauptversion unter Umständen neu kompiliert werden.

Warum ein Server-Update Docker und PM2 nicht automatisch aktualisiert

In einer realen Infrastruktur können das PHP des Systems, das PHP in einem Apache-Container und das einer PHP-FPM-Anwendung nebeneinander existieren. Korrigiert man eines davon, bleiben die anderen, wie sie sind. Auch die Version, die ein Befehl im Terminal ausgibt, muss mit der des Prozesses verglichen werden, der die Anfragen tatsächlich bedient.

Bei Docker haben wir die tatsächlich aktiven Images geprüft, Ersatz vorbereitet und die Datenvolumes beibehalten. Ein Tag namens latest bescheinigt nicht, dass ein Patch enthalten ist, und ein späterer Rebuild kann die Arbeit zunichtemachen, wenn das Dockerfile oder das Deployment-Verfahren weiterhin eine alte Basis auswählt. Im Rahmen dieses Einsatzes haben wir auch die Pakete des Anbieters geprüft und, wo nötig, Runtimes aus offiziellen Quellen mit kontrollierten Prüfsummen erstellt.

Bei PM2 ersetzt ein Wechsel des Standard-Node der Shell keine ausführbare Datei, die bereits im Speicher geladen ist. Wir haben den Daemon, die Kindprozesse und die Überwachung durch systemd geprüft. Während der Arbeit waren auch Rücksetzungen und Korrekturen am Verfahren nötig: Die Möglichkeit, zu einer funktionierenden Konfiguration zurückzukehren, war Teil der Vorbereitung.

PHP und Node.js aktualisieren, ohne Anpassungen und Daten zu verlieren

Vor dem Wechsel haben wir die bisherigen Images aufbewahrt und Kopien der Datenbanken und Volumes für die Tests vorbereitet. Auf dem Monitoring-System haben wir Tausende PHP- und MIB-Dateien mit dem ursprünglichen Snapshot verglichen, mit denselben schreibgeschützten Mounts. Beim Rechnungsdienst haben wir im Klon das Login, das Lesen von Kunden und Rechnungen, den Download eines bestehenden PDFs und die Erstellung eines Testdokuments geprüft. In der Produktion haben wir anschließend Dienststatus und HTTP-Antworten erneut kontrolliert.

Die Testsuiten der Unternehmensanwendungen haben Tausende Tests ohne Fehlschlag durchlaufen. Der abschließende kontrollierte Neustart dieser Dienste und die endgültige Umstellung des Rechnungsdienstes erfolgten ohne Unterbrechung: Das Monitoring der Produktiv-Endpunkte erhielt weiterhin korrekte Antworten. Im Lauf der gesamten Arbeit gab es auch Versuche und Rollbacks, die genau dafür vorbereitet waren, die Endnutzer nicht zu beeinträchtigen.

Ein grüner Healthcheck sagt, dass eine bestimmte Prüfung funktioniert. Um zu wissen, ob eine Anwendung benutzbar bleibt, braucht es auch Tests der Funktionen, auf die es ankommt: Logins, Datenbanken, Dokumente, Job-Warteschlangen und Integrationen. Das ist ein konkreter Teil des Hostings in der Schweiz, und er muss organisiert sein, bevor die nächste dringende Sicherheitsmeldung kommt.

Fragen an die Verantwortlichen Ihrer Website

Muss eine durch VPN geschützte Website aktualisiert werden?

Ja. Das VPN schränkt ein, wer einen Dienst über die geschützten Zugänge erreichen kann; die Korrektur beseitigt den Fehler in der Runtime. Es sind Maßnahmen mit unterschiedlichen Funktionen. Ein VPN hilft, die Exposition einzuschätzen und die Reihenfolge der Arbeiten festzulegen, ersetzt aber keinen Patch.

Reicht es, WordPress, Laravel oder das JavaScript-Framework zu aktualisieren?

Bei diesen Sicherheitslücken müssen auch PHP oder Node.js geprüft werden. Fragen Sie Ihren Anbieter, welche Version die Anfragen ausführt, welche Paketrevision die Korrektur enthält und welche Kontrollen nach dem Neustart durchgeführt wurden. Eine Anwendung kann die Runtime in ihrem eigenen Docker-Image weiterverwenden, auch nachdem das Betriebssystem aktualisiert wurde.

Lässt sich nach dem Update 100 % Sicherheit garantieren?

Wir können die installierten Korrekturen, die bestandenen Tests und die durchgeführten Kontrollen dokumentieren. Das bescheinigt nicht die Abwesenheit jeder anderen Schwachstelle oder einer früheren Kompromittierung. Bei unseren Prüfungen haben wir zum Beispiel eine nicht fatale Warnung einer Anwendungsabhängigkeit separat erfasst, die bereits vor dem PHP-Wechsel bestand. Sicherheitspatches, Kompatibilität und bereits bestehende Auffälligkeiten auseinanderzuhalten, hilft, vernünftige Entscheidungen zu treffen.

Diese Prüfung können wir auch für Ihr Unternehmen durchführen

Bei Webcracy können wir prüfen, welche PHP- und Node.js-Versionen Ihre Website oder Unternehmenssoftware ausführen, kontrollieren, ob die Korrekturen vorhanden sind, und die Dienste identifizieren, die zuerst aktualisiert werden müssen. Sie erhalten von uns eine Übersicht darüber, was wir geprüft haben, welche Arbeiten nötig sind und welche Fragen noch offen sind.

Wir können uns auch um die Updates kümmern: Backups vorbereiten, Änderungen auf Kopien der Daten testen und die Funktionen prüfen, die Sie täglich nutzen. Vorher vereinbaren wir Zeitpunkt und Vorgehen; danach dokumentieren wir die Änderungen und die durchgeführten Tests.

Erzählen Sie uns, was Sie einsetzen und wer heute Ihr Hosting betreut: Wir setzen dort an, gern auch gemeinsam mit Ihrem aktuellen Anbieter.

Sprechen wir über Ihre Website oder Unternehmenssoftware

Illustrationsfoto: Taylor Vick auf Unsplash, verwendet gemäß der Unsplash-Lizenz. Das abgebildete Rechenzentrum ist nicht das des beschriebenen Einsatzes.