Kritische Schwachstellen in PHP und Node.js, die Korrekturen vom 21. Oktober

Am 21. Oktober 2026 wurden zwei getrennte Sicherheitsbulletins veröffentlicht: eines für PHP, das andere für Node.js. Beide betreffen Schwachstellen, die einem Angreifer die Ausführung von Code aus der Ferne ermöglichen können, also die Möglichkeit, Befehle auf einem System auszuführen, ohne Zugangsdaten zu benötigen.

Für PHP wurden zwei Lücken gemeldet, CVE-2026-109618 und CVE-2026-109619. Die erste betrifft die Speicherverwaltung, wenn die Systemressourcen erschöpft sind: Bestimmte Daten der Anfrage können nur teilweise initialisiert bleiben und bei der Bereinigung trotzdem als gültig behandelt werden. Das Problem wurde in Konfigurationen mit Apache und mod_php nachgewiesen und kann auftreten, bevor die Anwendung die Zugangsdaten des Nutzers prüft. Auch PHP-FPM wird als gefährdet eingeschätzt, auch wenn für diese Variante noch kein vollständiger Nachweis des Angriffs vorliegt. Die zweite Lücke betrifft interne Daten, die ein PHP-Prozess nach der Freigabe des Speichers einer vorherigen Anfrage behalten kann: Eine nachfolgende Anfrage kann am Ende auf diese nicht mehr gültigen Verweise zugreifen.

Für Node.js meldet das Bulletin CVE-2026-111497, eine als hoch eingestufte Schwachstelle im Decoder des Kompressionsformats Brotli, das auch im Datenverkehr von Webseiten verwendet wird. Auch in diesem Fall kann die Schwachstelle zur Ausführung von Code aus der Ferne führen, wobei das konkrete Risiko davon abhängt, wie die Anwendung die empfangenen komprimierten Daten verarbeitet. Dasselbe Node.js-Update behebt zudem Probleme im Zusammenhang mit DNS und der Prüfung von TLS-Zertifikaten.

Die Korrekturen sind in den neuesten von den beiden Projekten veröffentlichten Versionen enthalten, doch die richtige Version zu bestimmen ist nicht immer einfach. Eine Linux-Distribution kann die Korrektur bereits angewendet haben, obwohl die Versionsnummer alt erscheint: Für PHP 8.3 unter Ubuntu 24.04 entspricht die Korrektur beispielsweise dem Paket 8.3.6-0ubuntu0.24.04.13, nicht einem auf den ersten Blick erkennbaren Versionssprung.

Wer PHP-Server betreibt, kann auf ein freies Werkzeug zurückgreifen: php2shell-audit, veröffentlicht auf GitHub. Es listet die auf einem Rechner vorhandenen PHP-Installationen auf, liest deren genaue Version und das Paket der Distribution, aus dem sie stammen, und vergleicht sie mit den korrigierten Versionen, wobei es die von den Distributionen übernommenen Korrekturen berücksichtigt. Es kann zudem in den Logs nach Spuren eines Angriffsversuchs suchen. Der Scanner versucht nicht, die Lücken auszunutzen: Bei entfernten Websites liest er nur die Kopfzeilen der Antwort, und er darf nur auf eigenen oder ausdrücklich freigegebenen Systemen eingesetzt werden.

Denselben Abgleich wendet die Sicherheitszählung des Schweizer öffentlichen Sektors passiv auf die öffentliche Verwaltung an: Das Projekt von Webcracy prüft täglich rund 2200 Gemeinden, Kantone und Bundesämter und liest dabei nur öffentliche Daten. Unter anderem zeigt es, wie viele der Stellen, die ihre PHP-Version offenlegen, bereits eine korrigierte Version einsetzen. Eine fehlende Kopfzeile allein beweist allerdings nicht, dass eine Website sicher ist.

Die Überprüfung hinter dem Update

Webcracy, ein Softwareunternehmen aus Locarno, das Websites und Anwendungen für Tessiner Firmen betreut, schilderte, wie es das Update für seine Kundinnen und Kunden durchführte. Der erste Schritt bestand darin herauszufinden, welche Versionen von PHP und Node.js die Anfragen tatsächlich bedienten: Auf demselben Server können das PHP des Systems, jenes in einem Container und jenes einer separaten Anwendung nebeneinander bestehen, und wer nur eines korrigiert, lässt die anderen unverändert. Auch ein Node.js, das ein Prozessmanager wie PM2 bereits in den Speicher geladen hat, läuft weiter, bis es neu gestartet wird, unabhängig davon, welche Version inzwischen installiert ist.

Vor dem Eingriff wurden die vorherigen Versionen der Container sowie Kopien der Datenbanken aufbewahrt, um im Problemfall zurückkehren zu können. Die Änderungen wurden auf isolierten Kopien der Umgebungen geprüft, mit den automatisierten Tests der Anwendungen und manuellen Kontrollen der Funktionen, auf die es im Alltag ankommt: Anmeldungen, Datenbanken, Dokumente. Die Umstellung im Betrieb erfolgte ohne Unterbrechungen: Die Überwachung der Endpunkte erhielt weiterhin korrekte Antworten.

Der Fall zeigt, warum eine durch ein VPN geschützte oder nur auf CMS-Ebene aktualisierte Website nicht automatisch sicher ist: Die Korrektur betrifft die Laufzeitumgebung PHP oder Node.js, die die Anwendung ausführt, nicht nur die darüber liegende Software. Eine Anwendung kann zudem weiterhin eine alte Version der Laufzeitumgebung innerhalb eines Docker-Images verwenden, selbst nachdem das Betriebssystem aktualisiert wurde.