--- title: "Node2Shell und ein schlechter Tag für das Internet: Wo das JavaScript-Risiko einer Microsoft 365-Erweiterung liegt" description: "Node2Shell, eine Lücke zur Remotecodeausführung in Node.js, wurde am 21. Oktober behoben. Was das für Microsoft 365-Erweiterungen bedeutet und wo Virto steht." url: https://www.virtosoftware.com/de/news/node2shell-javascript-risk-microsoft-365-add-ons/ language: de-DE last_modified: 2026-10-23T00:00:00+02:00 translations: en: https://www.virtosoftware.com/news/node2shell-javascript-risk-microsoft-365-add-ons/index.md --- # Node2Shell und ein schlechter Tag für das Internet: Wo das JavaScript-Risiko einer Microsoft 365-Erweiterung liegt [von Sergi Sinyugin](https://www.virtosoftware.com/de/author/svirtosoftware-com/) Veröffentlicht: 23. Oktober 2026 Zuletzt aktualisiert: 23. Oktober 2026 Lesezeit: 5 Min. [Neuigkeiten](https://www.virtosoftware.com/de/news/) *Node2Shell war ein Serverproblem. Bei einer Microsoft 365-Erweiterung liegt das größere JavaScript-Risiko woanders.* --- Am 21. Oktober 2026 hatte das Internet, wie TechCrunch schrieb, einen sehr schlechten Tag für die Cybersicherheit. Node.js veröffentlichte Korrekturen für zehn Schwachstellen, vier davon mit hohem Schweregrad, und PHP und GitLab meldeten innerhalb weniger Stunden ebenfalls schwere Lücken. Die Node.js-Lücke, die Schlagzeilen machte, ist CVE-2026-111497 mit dem Spitznamen Node2Shell: ein Schreibzugriff außerhalb der Puffergrenzen im Brotli-Decoder, der mit Node.js ausgeliefert wird. Laut dem Sicherheitshinweis des Projekts ermöglicht sie Remotecodeausführung. Einfach gesagt: Wer einem verwundbaren Prozess die passenden Daten zuspielt, kann unter Umständen eigenen Code auf diesem Server ausführen. Im Folgenden: was Node2Shell braucht, um zu funktionieren, wo JavaScript tatsächlich läuft, wenn Sie eine Erweiterung für SharePoint, Teams oder Microsoft 365 installieren, wo VirtoSoftware steht – und drei Fragen, die Sie diese Woche jedem Anbieter stellen sollten, auch uns. ## Was Node2Shell braucht, um zu funktionieren Node2Shell steckt in Node.js selbst, nicht in einer einzelnen Anwendung. Ein Server ist angreifbar, wenn ein Node.js-Prozess Brotli-Daten entpackt, die ein Angreifer kontrolliert. Das geschieht vor allem auf zwei Wegen: - **Eingehende Anfragen.** Express 5 und body-parser 2 entpacken Anfrageinhalte, die mit `Content-Encoding: br` gesendet werden – jeder Client kann so etwas schicken. Ein reiner Node.js-HTTP-Server dekodiert eingehende Brotli-Inhalte nicht von sich aus. - **Ausgehende Aufrufe.** Node.js entpackt Brotli-Antworten automatisch, wenn es eine URL abruft. Ein bösartiger oder kompromittierter Server, den Sie aufrufen, kann so den Decoder erreichen. Typische Fälle sind Webhooks und von Benutzern angegebene URLs. Die Lösung ist ein Update auf Node.js 22.23.4, 24.22.1 oder 26.12.1. Node.js 20 und älter haben das Ende ihres Supports erreicht und erhalten keine Korrektur, und der Sicherheitshinweis nennt keine Übergangslösung. Bis zum 22. Oktober war keine Ausnutzung in freier Wildbahn bekannt, und der erste öffentliche Machbarkeitsnachweis funktionierte nur gegen einen absichtlich geschwächten Build. Forscher, die auf einem normalen Build Code ausführen konnten, berichteten, dass es nicht bei jedem Versuch gelang. Das ist ein Grund, in Ruhe zu patchen – kein Grund zu warten. Wenn Sie eigene Node.js-Dienste betreiben, ist das Ihre Aufgabenliste. Wenn Sie Software kaufen, die in Microsoft 365 läuft, ist eine andere Frage nützlicher: Wo läuft der Code Ihres Anbieters, und was läuft dort? ## Drei Orte, an denen eine Erweiterung lebt ![Drei Karten: der Browser, der erbt, was der Build ausliefert; die Server des Anbieters, wo Node2Shell Node.js trifft; und der Build des Anbieters, wo npm-Würmer treffen](https://www.virtosoftware.com/images/uploads/2026/10/node2shell-three-places-de.webp) *Abb. 1. Die drei Orte, an denen der Code einer Erweiterung für SharePoint, Teams oder Microsoft 365 läuft* 1. **Die Browser Ihrer Benutzer.** Der Kalender, das Board oder das Formular, das Sie in SharePoint oder Teams sehen, ist JavaScript, das im Browser läuft – mit den Berechtigungen des angemeldeten Benutzers und den Berechtigungen, die Ihr Administrator der App erteilt hat. 2. **Die Server des Anbieters**, wenn die App ein Back-End hat: der Dienst, der mit Microsoft Graph spricht, eine Erinnerung sendet oder Einstellungen speichert. 3. **Die Build-Rechner des Anbieters**, auf denen dieses JavaScript aus Hunderten Open-Source-Paketen zusammengesetzt wird, bevor es zu Ihnen kommt. Node2Shell ist ein Problem des zweiten Ortes. Die npm-Lieferkettenangriffe dieses Jahres sind ein Problem des dritten. Und der erste Ort erbt, was im dritten passiert. ## Unsere Server: .NET auf Microsoft Azure Für unsere eigenen Produkte ist die Antwort kurz. Virto Calendar App, Virto Shared Calendar, Virto Forms Designer App und Virto Polls haben Back-Ends, die in .NET geschrieben sind und auf Microsoft Azure laufen. Node.js läuft dort nicht. In diesen Projekten kommt es nur im Build vor, wo es den Code zusammensetzt, der in Ihrem Browser läuft. Unsere On-Premises-Webparts laufen in Ihrer eigenen SharePoint-Server-Farm, ebenfalls auf .NET, und bringen auch kein Node.js auf Ihre Server. Für diese Apps gibt es also keinen Virto-Server, den Node2Shell erreichen könnte. Damit ist JavaScript für uns nicht risikofrei. Das Risiko verlagert sich nur in den Build. ## Unser Build: Hier liegt das eigentliche JavaScript-Risiko npm hatte ein schweres Jahr. Vertrauenswürdige Pakete wurden eines nach dem anderen gekapert, und im August verbreitete sich ein Wurm namens Shai-Hulud über mehr als vierhundert Pakete, darunter beliebte Caching-Bibliotheken. Eine infizierte Version sammelte CI-Tokens, Cloud-Zugangsdaten und andere Geheimnisse von dem Rechner, der sie installierte, und der Wurm verbreitete sich auf weitere Pakete. Ein Anbieter, der JavaScript in die Browser seiner Kunden ausliefert, ist genau das Ziel solcher Angriffe: ein Build-Rechner, der Hunderte Pakete installiert und die Schlüssel besitzt, um Code in fremde Mandanten auszuliefern. Was zwischen einem gekaperten Paket und einem Build steht, ist unspektakulär: ein Lockfile. Die Frontend-Projekte der vier oben genannten Apps legen die genaue Version jedes installierten Pakets fest. Eine neue Version – ob bösartig oder nicht – kommt erst in einen Build, wenn sich jemand für ein Update entscheidet. Nach den Sicherheitshinweisen vom August haben wir unsere Lockfiles geprüft. Mehrere der dort genannten Bibliotheken sind in unserem Abhängigkeitsbaum enthalten, aber auf Versionen festgelegt, die älter sind als die gekaperten. Keines unserer Lockfiles enthielt eine gekaperte Version. ## Von jemand anderem getestet als von uns Ein Anbieter, der seine eigenen Hausaufgaben benotet, reicht nicht – und es ist berechtigt zu fragen, wer sonst geprüft hat. Das NATO Cyber Security Centre hat sieben unserer Komponenten für SharePoint Server penetrationsgetestet: Kanban Board im März 2024, die meisten anderen im Frühjahr 2026. Alle Befunde sind behoben. Die eine in Kanban Board gefundene Schwachstelle, CVE-2024-34400, wurde innerhalb von sieben Arbeitstagen behoben. [Welche Komponenten und Versionen getestet wurden](https://www.virtosoftware.com/de/news/nato-ncsc-penetration-tests-virto-sharepoint-components/). ## Drei Fragen an Ihre Anbieter diese Woche 1. **Was läuft auf Ihren Servern, und mit welchen Laufzeitversionen?** Wenn die Antwort Node.js enthält, fragen Sie, ob schon 22.23.4, 24.22.1 oder 26.12.1 im Einsatz ist. Enthält sie Node.js 20 oder älter, fragen Sie nach dem Datum des Updates. 2. **Wie halten Sie ein gekapertes Paket aus Ihrem Build heraus?** Eine gute Antwort nennt Lockfiles, eine Prüfung bei jedem Build und eine Frist für Patches – nicht nur „wir verwenden nur bekannte Bibliotheken“. 3. **Wer außer Ihnen hat das Produkt getestet, und wie schnell haben Sie behoben, was gefunden wurde?** Ein Penetrationstest ist eine Momentaufnahme. Die Zeit bis zur Behebung zeigt, wie sich ein Anbieter verhält, wenn etwas gefunden wird. Dieselben drei Fragen können Sie uns stellen – dieser Artikel ist unsere Antwort. Alles Weitere, was Sicherheitsprüfer brauchen, von der Frage, wo Ihre Daten liegen, bis zu den Zertifizierungen, die wir haben und die wir nicht haben, finden Sie auf unserer Seite [Sicherheit und Compliance](https://www.virtosoftware.com/de/security-compliance/). --- [**Sicherheit und Compliance: wo Ihre Daten liegen und was wir vorweisen →**](https://www.virtosoftware.com/de/security-compliance/) [Sergi Sinyugin](https://www.virtosoftware.com/de/author/svirtosoftware-com/)