Node2Shell: Das Image-Tag ist kein Inventar.
Themenstand: 02.11.2026 · Für den Blog aufbereitet am 06.11.2026. Auf Basis vorhandener Postingtexte neu ausgearbeitet.
Eine saubere Paketliste sagt wenig über den Decoder in der laufenden Runtime. Warum Patchen im Container erst beim Nachmessen endet.
Die Runtime gehört mit auf die Liste.
Die Abhängigkeitsprüfung im Repository sieht unauffällig aus. Im ausgelieferten Image läuft trotzdem ein anderes Node.js-Binary als erwartet. Für eine Untersuchung sind das zwei getrennte Ebenen: Anwendungspakete und die Laufzeitumgebung, die sie ausführt. Node2Shell macht diesen Unterschied sehr konkret.
Unter diesem Namen wird CVE-2026-111497 diskutiert: ein Schreibzugriff außerhalb des vorgesehenen Speichers im Brotli-Decoder. Brotli komprimiert Daten; der Decoder entpackt sie. Präparierte Eingaben können Prozessspeicher beschädigen. Je nach Situation sind Abstürze, offengelegte Speicherinhalte oder Codeausführung möglich. Nicht jede Fehlermeldung bedeutet bereits einen erfolgreichen Angriff.
Der Weg hinein kann vor dem eigenen Code liegen.
Betroffenheit setzt voraus, dass angreiferkontrollierte Brotli-Daten tatsächlich von einer verwundbaren Komponente entpackt werden. Das kann über explizite Aufrufe von node:zlib geschehen. Forschung beschreibt außerdem automatisch entpackte Antworten der eingebauten fetch-Funktion und komprimierte Request-Bodies in Express 5 mit body-parser 2.
Der Unterschied zwischen eingehenden und ausgehenden Daten ist wichtig. Eine Proxy-Regel für eingehende Content-Encoding: br-Anfragen deckt nicht automatisch einen böswilligen Server ab, von dem die Anwendung selbst eine komprimierte Antwort abholt. Der eingebaute Node-HTTP-Server entpackt eingehende Bodies zudem nicht grundsätzlich von allein.
Version prüfen, Herkunft berücksichtigen.
Die upstream veröffentlichten Node.js-Fixes liegen in 22.23.4, 24.22.1 und 26.12.1. Das ist der Stand des referenzierten Sicherheitsreleases vom 21. Oktober 2026, keine Empfehlung, spätere Sicherheitsupdates auszulassen. Für die eigene Installation gehören Releasezweig und Bezugsquelle zur Bewertung.
Distributionspakete können System-Brotli statt einer eingebetteten Bibliothek verwenden und Sicherheitsfixes zurückportieren. Dann reicht ein Vergleich der sichtbaren Node-Version mit einer upstream Tabelle nicht aus. Das Hersteller-Advisory des Betriebssystems gehört daneben. Für Bun oder andere Produkte ist deren jeweilige Herstellerbewertung maßgeblich.
Der Rebuild ist erst nach dem Rollout fertig.
Zuerst würde ich das tatsächlich gestartete Binary mit node --version im relevanten Image beziehungsweise Container prüfen und das verwendete Image-Digest festhalten. Danach den unterstützten Patchpfad wählen, Basis-Image und Build aktualisieren und die Version nach dem Rollout erneut im laufenden System messen.
Bei Docker haben --pull und --no-cache unterschiedliche Aufgaben. --pull prüft auf ein neueres Basis-Image. --no-cache führt Buildschritte neu aus, zieht aber für sich allein kein neues Basis-Image. Ein auf eine alte Version oder ein altes Digest festgeschriebenes FROM wird durch keinen der beiden Schalter automatisch auf eine andere Version geändert.
Abstürze, Decoderfehler und auffällige Requests wären für mich Untersuchungsansätze. Für die Aussage „ausgenutzt“ brauche ich zusätzliche zusammenpassende Belege. Die Erkenntnis von Maurizio Schmidt: Erst messen, was wirklich läuft. Dann ändern. Danach wieder messen.