--- title: "Node2Shell and a bad day for the internet: where JavaScript risk lives in a Microsoft 365 add-on" description: "Node2Shell, a remote code execution flaw in Node.js, was patched 21 October. What it means for Microsoft 365 add-ons, where Virto stands, what to ask vendors." url: https://www.virtosoftware.com/news/node2shell-javascript-risk-microsoft-365-add-ons/ language: en-US last_modified: 2026-10-23T00:00:00+02:00 translations: de: https://www.virtosoftware.com/de/news/node2shell-javascript-risk-microsoft-365-add-ons/index.md --- # Node2Shell and a bad day for the internet: where JavaScript risk lives in a Microsoft 365 add-on [by Sergi Sinyugin](https://www.virtosoftware.com/author/svirtosoftware-com/) Published: Oct 23, 2026 Latest update: Oct 23, 2026 Reading Time: 5 mins [News](https://www.virtosoftware.com/news/) *Node2Shell was a server problem. For a Microsoft 365 add-on, the bigger JavaScript risk sits somewhere else.* --- On 21 October 2026 the internet had what TechCrunch called a very bad cybersecurity day. Node.js shipped fixes for ten vulnerabilities, four of them rated high, and PHP and GitLab disclosed serious flaws within hours of each other. The Node.js bug that made the headlines is CVE-2026-111497, nicknamed Node2Shell: an out-of-bounds write in the Brotli decoder that ships with Node.js. The project’s advisory says it permits remote code execution. In plain words, an attacker who gets the right data to a vulnerable process may be able to run their own code on that server. Below: what Node2Shell needs in order to work, where JavaScript actually runs when you install an add-on for SharePoint, Teams or Microsoft 365, where VirtoSoftware stands, and three questions worth asking every vendor this week, us included. ## What Node2Shell needs in order to work Node2Shell lives in Node.js itself, not in any one application. A server is exposed when a Node.js process unpacks Brotli data that an attacker controls. That happens in two common ways: - **Incoming requests.** Express 5 and body-parser 2 unpack request bodies sent with `Content-Encoding: br`, so any client can send one. A bare Node.js HTTP server does not decode incoming Brotli bodies on its own. - **Outgoing calls.** Node.js unpacks Brotli responses automatically when it fetches a URL, so a malicious or compromised server you call can reach the decoder. Webhooks and user-supplied URLs are the typical case. The fix is an upgrade to Node.js 22.23.4, 24.22.1 or 26.12.1. Node.js 20 and older are past end of life and get no fix, and the advisory offers no workaround. As of 22 October no exploitation in the wild had been reported, and the first public proof of concept worked only against a deliberately weakened build. Researchers who did reach code execution on a normal build said it did not work on every attempt. That is a reason to patch calmly, not a reason to wait. If you run your own Node.js services, that is your to-do list. If you buy software that runs inside Microsoft 365, the more useful question is a different one: where does your vendor’s code run, and what runs there? ## Three places an add-on lives ![Three cards: the browser, which inherits whatever the build ships; the vendor’s servers, where Node2Shell hits Node.js; and the vendor’s build, where npm worms hit](https://www.virtosoftware.com/images/uploads/2026/10/node2shell-three-places.webp) *Fig. 1. The three places the code of a SharePoint, Teams or Microsoft 365 add-on runs* 1. **Your users’ browsers.** The calendar, the board or the form you see in SharePoint or Teams is JavaScript running in the browser, with the permissions of the signed-in user and the permissions your admin granted the app. 2. **The vendor’s servers**, if the app has a back end: the service that talks to Microsoft Graph, sends a reminder or keeps settings. 3. **The vendor’s build machines**, where that JavaScript is assembled from hundreds of open-source packages before it is shipped to you. Node2Shell is a problem of the second place. This year’s npm supply-chain attacks are a problem of the third. And the first place inherits whatever happens in the third. ## Our servers: .NET on Microsoft Azure For our own products the answer is short. Virto Calendar App, Virto Shared Calendar, Virto Forms Designer App and Virto Polls have back ends written in .NET and hosted on Microsoft Azure. Node.js does not run on them. In these projects it only appears in the build, where it assembles the code that runs in your browser. Our on-premises web parts run inside your own SharePoint Server farm, on .NET as well, and they do not bring Node.js onto your servers either. So for these apps there is no Virto server for Node2Shell to reach. That does not make JavaScript risk-free for us. It moves the risk to the build. ## Our build: where the JavaScript risk actually is npm has had a hard year. Trusted packages have been hijacked one after another, and in August a worm calling itself Shai-Hulud spread through more than four hundred of them, popular caching libraries among them. An infected release collected CI tokens, cloud credentials and other secrets from the machine that installed it, and the worm kept spreading to further packages. A vendor that ships JavaScript into customers’ browsers is exactly the kind of target this is aimed at: a build machine that installs hundreds of packages and holds the keys to ship code into other people’s tenants. What stands between a hijacked package and a build is unglamorous: a lockfile. The front-end projects of the four apps above pin the exact version of every package they install, so a new release, malicious or not, reaches a build only when someone decides to update. After the August advisories we checked our lockfiles. Several of the library names on the list are in our dependency tree, but pinned to versions that predate the hijacked releases. None of our lockfiles pinned a hijacked version. ## Tested by someone other than us A vendor grading its own homework is not enough, and it is fair to ask who else has looked. The NATO Cyber Security Centre has penetration-tested seven of our components for SharePoint Server: Kanban Board in March 2024, most of the others in spring 2026. Every finding has been fixed. The one vulnerability found in Kanban Board, CVE-2024-34400, was fixed within seven business days. [Which components and versions were tested](https://www.virtosoftware.com/news/nato-ncsc-penetration-tests-virto-sharepoint-components/). ## Three questions for your vendors this week 1. **What runs on your servers, and on which runtime versions?** If the answer includes Node.js, ask whether it is already on 22.23.4, 24.22.1 or 26.12.1. If it includes Node.js 20 or older, ask for the upgrade date. 2. **How do you keep a hijacked package out of your build?** A good answer names lockfiles, a check on every build and a deadline for patching, not just “we only use popular libraries”. 3. **Who besides you has tested the product, and how fast did you fix what they found?** A penetration test is a snapshot. The time to fix tells you how the vendor behaves when something is found. You can ask us the same three; this article is our answer. The rest of what a security reviewer needs, from where your data is to which certifications we hold and which we do not, is on our [Security & Compliance](https://www.virtosoftware.com/security-compliance/) page. --- [**Security & Compliance: where your data is and what we hold →**](https://www.virtosoftware.com/security-compliance/) [Sergi Sinyugin](https://www.virtosoftware.com/author/svirtosoftware-com/)