PHP- und Node.js-Sicherheitslücken Oktober 2026: Was jetzt zu tun ist

Am 21. Oktober 2026 haben das PHP-Projekt und das Node.js-Projekt am selben Tag Sicherheitsupdates veröffentlicht. Bei PHP geht es um zwei kritische Lücken, die laut Advisory einen Angriff aus dem Internet ohne Anmeldung ermöglichen können. Bei Node.js sind es zehn CVEs, darunter eine mit möglicher Codeausführung.

Wer eine Website, einen Shop oder eine Webanwendung betreibt, muss deshalb nicht in Panik verfallen, sollte aber innert weniger Tage wissen, welche Version auf dem eigenen Server läuft und wer sie aktualisiert. Dieser Beitrag fasst zusammen, was in den offiziellen Advisories steht, was dort ausdrücklich offen bleibt und wie Sie in der Praxis vorgehen.

Die zwei kritischen PHP-Lücken im Überblick

Beide Lücken wurden am 21. Oktober 2026 im php-src-Repository veröffentlicht und mit einem CVSS-v4-Wert von 9.2 als kritisch eingestuft. Behoben sind sie in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Alle älteren Releases dieser Linien gelten als betroffen.

CVE-2026-109618 («RCE via OOM corruption»). PHP springt bei zu wenig Arbeitsspeicher über longjmp() aus dem laufenden Code. Wenn Speicher des Requests zu diesem Zeitpunkt noch nicht vollständig initialisiert ist, bleibt ein ungültiger Zustand zurück, den der Abschluss des Requests auswerten kann. Für Apache mod_php wurde die Codeausführung ohne Anmeldung über HTTP mit den Standardlimits nachgewiesen. Für PHP-FPM hält das Advisory die Lücke aufgrund der Quellcode-Analyse für möglich, aber nicht vollständig demonstriert. Für FrankenPHP und LSAPI gilt dasselbe in abgeschwächter Form.

CVE-2026-109619 («RCE via stale global state»). Hier bleibt Zustand eines früheren Requests im Worker erhalten und zeigt später auf bereits freigegebenen Speicher. Bestätigt ist der Angriffsweg bei mod_php, bei PHP-FPM ist er an Bedingungen geknüpft. Der am besten belegte Fall nutzt die Option fatal_error_backtraces aus PHP 8.5.

Beide Advisories stellen klar, dass Ausführung von Code mit den Rechten des Webserver-Prozesses möglich ist. Das reicht in der Praxis, um Kundendaten auszulesen, Formulare umzuleiten oder Schadcode auf der Seite zu platzieren.

Welche Zwischenmassnahmen es gibt und warum sie nicht reichen

Wer nicht sofort aktualisieren kann, findet in den Advisories eine Liste von Gegenmassnahmen:

• memory_limit=-1 setzen, sodass Anwendungen es nicht überschreiben können
• post_max_size senken sowie die Zahl der Multipart-Teile, Header und Uploads begrenzen
• bei PHP 8.5 fatal_error_backtraces=0 setzen
• session.upload_progress.enabled=0 setzen, falls die Funktion nicht gebraucht wird
• Multipart-Requests am Frontend blocken, wenn sie nicht benötigt werden
• RLIMIT_AS und RLIMIT_DATA vermeiden, da sie den verwundbaren Pfad auslösen können

Das PHP-Projekt schreibt dazu selbst, dass das Update auf eine gepatchte Version der einzige vollständige Schutz ist. Die Massnahmen verschaffen Zeit, mehr nicht. Nach jeder Konfigurationsänderung müssen die PHP-Prozesse neu gestartet werden.

Zehn CVEs bei Node.js: Was davon wichtig ist

Das Node.js-Projekt hat am 21. Oktober 2026 zehn Schwachstellen behoben: vier mit Schweregrad «high», drei «medium» und drei «low». Die gepatchten Versionen sind Node.js 22.23.4, 24.22.1 und 26.12.1.

Die Lücken mit dem höchsten Schweregrad:

• CVE-2026-111497: Schreibzugriff ausserhalb des Speicherbereichs im Brotli-Decoder, der laut Advisory Codeausführung erlauben kann. Betroffen sind die Linien 22, 24 und 26. Wie genau die Lücke ausgelöst wird, nennt die Meldung nicht.
• CVE-2026-105483 und CVE-2026-106069: Die Prüfung des Hostnamens im TLS-Zertifikat lässt sich in bestimmten Fällen umgehen, etwa bei Hostnamen, die als IP-Adresse interpretiert werden. Das betrifft Anwendungen, die per Node.js andere Server über HTTPS ansprechen, zum Beispiel Schnittstellen zu Buchhaltung, Zahlung oder CRM.
• CVE-2026-105482: dns.resolve schneidet Namen mit NUL-Zeichen ab.

Dazu kommen mittlere und tiefe Schweregrade, unter anderem zu Keep-Alive-Verbindungen, zur Zertifikatsvalidierung bei nicht kanonischen IPv4-Hostnamen, zu Zufallswerten in Startup-Snapshots und zum Permission Model. Das Release aktualisiert ausserdem OpenSSL, SQLite, c-ares und Undici und passt das Zertifikatsbündel wegen einer Zwischenzertifizierungsstelle (eMudhra) an.

Für die Einordnung gilt: Ob eine Lücke Sie trifft, hängt davon ab, was Ihre Anwendung tut. Ein Next.js-Frontend, das nur statische Seiten ausliefert, hat eine andere Angriffsfläche als eine Node.js-API, die Dateien dekomprimiert und externe Dienste anspricht.

Wann Ihre Version gar keinen Fix mehr bekommt

Node.js 20 ist laut der offiziellen Releases-Übersicht am Ende seines Supports. Das Security-Release hält fest, dass Versionen ohne Support von den Lücken ebenfalls betroffen sind, aber keinen Patch erhalten. Wer noch auf Node.js 20 läuft, hat damit keine Option ausser dem Wechsel auf Node.js 22 oder 24, beides Linien mit Long-Term-Support.

Bei PHP nennen die Advisories Fixes nur für die Linien 8.2 bis 8.5. Läuft Ihr Server auf PHP 8.1 oder älter, ist ein Wechsel auf eine unterstützte Linie die einzige Lösung. Dieser Wechsel ist aufwendiger als ein Patch-Update, weil Plugins, Themes und eigener Code mit der neuen Version kompatibel sein müssen.

So gehen Sie in den nächsten Tagen vor

1. Version feststellen. PHP: im Hosting-Panel, per php -v oder in der Systeminfo Ihrer Anwendung. Node.js: node -v auf dem Server bzw. die Angabe im Dockerfile oder in der Build-Konfiguration.
2. Zuständigkeit klären. Bei Shared Hosting aktualisiert meist der Provider die PHP-Version, oft erst nach einigen Tagen. Fragen Sie nach, bis wann. Bei einem eigenen Server (VPS) liegt die Aufgabe bei Ihnen oder Ihrem Dienstleister.
3. Update einspielen und neu starten. Ein installiertes Paket schützt erst, wenn der laufende Prozess neu gestartet wurde. Bei Docker-Setups muss das Image neu gebaut und ausgerollt werden.
4. Kompatibilität testen. Patch-Releases innerhalb derselben Linie sind in der Regel unproblematisch. Prüfen Sie trotzdem Kontaktformular, Login und Checkout nach dem Update.
5. Auffälligkeiten prüfen. Unerwartete Dateien im Webverzeichnis, neue Benutzerkonten oder ungewöhnliche Prozesse sind Hinweise auf eine erfolgte Kompromittierung. Die Advisories nennen keine bestätigten Angriffe in der Praxis, ausschliessen lässt sich das für die Tage nach der Veröffentlichung aber nicht.

Wann sich der Aufwand für Betriebe ohne eigene IT lohnt

Statische Websites ohne Serverlogik sind von solchen Laufzeitlücken kaum betroffen, weil auf dem Server kein PHP- oder Node.js-Code für Besucher ausgeführt wird. Das ist einer der Gründe, warum statische Websites für reine Firmenauftritte oft die wartungsärmere Wahl sind. Für Shops, Kundenportale und Anwendungen mit Login gilt das nicht, dort gehören Laufzeit-Updates zum Betrieb wie die jährliche Revision zur Heizung.

Eine ehrliche Grenze: Wer eine einzelne WordPress-Seite bei einem guten Hosting-Provider betreibt, muss meist nichts tun ausser nachfragen. Der Aufwand lohnt sich erst, sobald mehrere Systeme laufen, eigene Server betrieben werden oder niemand sicher weiss, wer aktualisiert. Allgemeine Massnahmen zur Absicherung fasst der Beitrag Cybersicherheit 2026 zusammen, zum eigenen Server-Betrieb gibt es einen Überblick zu Coolify Self-Hosting.

Wenn Sie nicht sicher sind, welche Versionen bei Ihnen laufen, hilft eine kurze Bestandsaufnahme: Hedinger-Digital prüft im Rahmen der Softwareentwicklung die eingesetzten Laufzeiten, spielt Updates ein und richtet automatische Benachrichtigungen ein. Eine Anfrage geht über die Kontaktseite.