Security researchers at Imperva have demonstrated a proof-of-concept exploit they call Node2Shell, showing that crafted Brotli-compressed data can make an application running on an official Node.js build execute attacker-supplied code. According to the report, the demonstration worked on the official Node.js 24.22.0 image for Linux arm64 and did not require a custom build or debugger.

The issue is identified as CVE-2026-111497. Based on the source report, the exploit path involves the Brotli decoder bundled with Node.js. While the researchers demonstrated code execution in a controlled proof of concept, businesses should distinguish between a published security demonstration and confirmed real-world exploitation.

What happened

Imperva researchers said they were able to achieve remote code execution by supplying specially crafted Brotli data to an application using an official Node.js build. The report states that the proof of concept targeted Node.js 24.22.0 on Linux arm64.

Brotli is a compression format commonly used in web delivery and application data handling. If an application processes Brotli-compressed input from untrusted or insufficiently validated sources, a flaw in the underlying decoder could create a route to code execution.

The source also says Node.js disclosed the flaw. However, businesses should rely on official Node.js security advisories and release notes to confirm affected versions, remediation guidance and patch availability before making operational decisions.

Why it matters for European businesses

Node.js is widely used in European business environments for websites, e-commerce platforms, APIs, server-side rendering, headless commerce setups and internal automation tools. A code-execution vulnerability in an official runtime can have consequences well beyond development teams.

• Website and e-commerce risk: If internet-facing services process attacker-controlled compressed data, successful exploitation could potentially lead to server compromise, service disruption or data exposure.
• Supply chain and platform exposure: Businesses using SaaS products, agencies, hosting providers or platform vendors built on Node.js may be indirectly affected even if they do not manage Node.js themselves.
• Operational impact: Vulnerabilities in widely deployed runtimes can trigger emergency patch cycles, temporary feature restrictions and additional monitoring requirements.
• Compliance implications: For companies handling customer, employee or payment-related data, a compromise involving application servers may create incident-response and regulatory obligations depending on the facts of the case.

Who may be affected

The report is most relevant to organisations that run or depend on Node.js in production, especially where applications may accept compressed data from users, integrations or upstream services.

• Businesses operating Node.js-based websites, APIs or web applications
• E-commerce companies using Node.js in storefronts, middleware or checkout-related services
• IT and DevOps teams managing containers based on official Node.js images
• Digital agencies building and hosting client projects on Node.js frameworks
• Software vendors and internal development teams using Node.js for automation or backend services

The source specifically references an official Linux arm64 build. That does not automatically mean exposure is limited to that environment, nor does it confirm that all Node.js deployments are affected in the same way. Companies should verify impact against vendor documentation.

What companies should consider

• Check official advisories: Review Node.js security announcements, CVE details and release notes to confirm affected versions and the status of any fix or mitigation.
• Inventory Node.js usage: Identify where Node.js runs across websites, APIs, internal tools, containers and third-party services.
• Review Brotli handling: Assess whether applications accept or process Brotli-compressed input from untrusted sources, directly or through proxies, uploads, APIs or integrations.
• Prioritise patching: If your environment matches affected builds, plan updates quickly through standard change-management and emergency patching processes where appropriate.
• Add monitoring: Increase logging and detection around unusual requests, crashes or suspicious behaviour in services that handle compressed payloads.
• Engage suppliers: Ask hosting providers, software vendors and development partners whether their platforms rely on affected Node.js versions and what remediation steps they have taken.
• Prepare contingency controls: Where immediate patching is not possible, consider temporary restrictions on high-risk input paths if supported by your architecture and vendor guidance.

For European SMEs, the practical takeaway is straightforward: even low-level runtime flaws can become a business issue when they affect public-facing sites, customer data flows or critical digital services. The priority is to verify exposure, follow official remediation guidance and make sure third-party providers are doing the same.