A serious Node.js vulnerability creates an immediate question for businesses with customer portals, online shops or integrations: has the software running those services actually been updated? A supplier saying that it has updated the project is not enough. Management needs confirmation that the corrected version is running in production.
Node.js is the software that runs JavaScript outside the browser, including on servers. A Norwegian business can depend on it without having its own developers. Ask the agency, software supplier or IT provider responsible for each relevant service to establish whether it uses Node.js and who owns the update.
What happened on 21 October
Node.js published security updates on 21 October 2026. One fix addresses CVE-2026-111497, a flaw in the Brotli decoder that can permit remote code execution. Node.js rates it High. The release also fixes other issues, including TLS certificate hostname checks and DNS handling.
Brotli is a compression format. Vercel's advisory describes exposure when applications decompress attacker-controlled Brotli data, including fetched responses. Code execution uses the process's permissions. Having Node.js installed does not, by itself, establish exposure.
The business consequence depends on what that service can access. A customer-facing application with database access and integration credentials deserves particular attention. Prioritise the assessment and update of exposed services; do not interpret uncertainty about one attack path as a reason to leave the runtime unpatched.
This article does not establish that your systems have been attacked. The vulnerability and the presence of an intrusion are separate questions.
Which Node.js versions contain the fixes?
These are the security releases published on 21 October. Use the listed version or a newer security release in the same supported release line, after checking the current release notes.
| Existing release line | Security release | Status on 23 October 2026 |
|---|---|---|
| Node.js 22.x | 22.23.4 | Long-term support, LTS |
| Node.js 24.x | 24.22.1 | Long-term support, LTS |
| Node.js 26.x | 26.12.1 | Current |
An application on a supported release line does not need an immediate jump to a new major version just to obtain these fixes. Patch its existing line, test it and plan any larger migration separately.
Node.js lists 20.x and 25.x among its end-of-life releases. The project no longer supplies security updates for those lines. Move affected applications to a supported version, or require specific evidence of a maintained commercial patch if that is the arrangement you use. A distributor's backported fix also needs its own security bulletin and package revision as evidence; the upstream version table alone cannot validate it.
Updating npm packages is a different task
An application has both a Node.js runtime and packages installed through npm. Updating a framework or changing package.json does not, by itself, prove that the deployed Node.js executable has changed.
npm documents its audit command as checking the project's configured dependencies against vulnerability information from the registry. A clean npm audit report is therefore not confirmation that this runtime fix has reached production. Continue checking dependencies, but verify Node.js separately.
The technical team can check the executable available in an environment with node --version. For a running service, record process.versions.node through approved internal diagnostics or startup logging, together with the deployment identifier. Node.js documents this property as the version of Node.js in that process. A result from a developer's laptop or the build job does not establish the version serving customers.
Do not publish a diagnostic endpoint just to demonstrate the update. Keep this evidence in the operational record, and cover every active instance or deployment that can receive traffic.
Complete the rollout, not just the installation
The operational recommendation is straightforward:
- Find the affected services and owners. Include production applications, background jobs, containers and build environments. Identify who can change each runtime and where confirmation must come from a supplier.
- Install the corrected runtime and rebuild what contains it. Docker's guidance explains that images are immutable snapshots. Build from a patched base image. The --pull option checks for a newer base image, but cannot turn a deliberately pinned old version or digest into a new one.
- Test and deploy. Check the service's important customer flows, authentication and integrations. Restart or replace affected processes, including background workers, using the normal controlled deployment procedure.
- Verify the deployed result. Record the runtime version, release identifier, time and successful functional checks. Check that older instances no longer receive traffic and that scaling or rollback will not silently restore the vulnerable build.
The aim is a prompt, controlled update. For a small Norwegian AS using an external agency, this may be one coordinated change with a named contact. A company operating several services needs a list of owners and completion evidence for each. The appropriate control is the same: somebody must verify the running service, not merely close the development task.
If a hosting platform manages Node.js
Check the provider's current incident guidance. Vercel's advisory, checked on 23 October, says it manages patches for its 22.x and 24.x runtimes. Its rollout was described as ongoing. Its firewall does not protect responses fetched from other servers. Do not treat firewall protection as proof of patching.
Confirm the provider's completed rollout or the actual runtime version for your service. Follow its instructions for unsupported versions and redeployment. Separately owned backends and containers need their own updates, even when the public website sits behind a managed platform.
The confirmation management should request
Ask the responsible technical owner or supplier for a short answer that identifies the service, the deployed corrected version, when it went live, how it was checked and any remaining exceptions. If they report that a service is unaffected, ask for the technical basis and the scope of that assessment.
Set a deadline for unresolved services according to exposure and business consequence. If there are signs of compromise, activate the incident-response process as well as patching. Preserve relevant evidence and assess the credentials and data the process could access. Installing a fix does not establish that a prior intrusion has been removed.
Management owns the operational follow-through. The board should ask about material unresolved exposure and whether management has the resources to close it; it should not choose runtime versions or run deployments. The broader guide to prioritising security updates explains how to handle postponements. The article on independent controls for AI-assisted software changes addresses verification when AI helps implement a change.
For this vulnerability, the useful closing question is concrete: Which corrected Node.js version is running in each affected production service, and what evidence confirms it?
Sources checked on 23 October 2026. Version and provider information can change. Operational recommendations are the author's analysis. The AI-generated illustration uses server maintenance as a visual metaphor for updating software.