Node.js Patched 10 Security Flaws. Is Your Business at Risk?

The October 21 Node.js security release addressed 10 vulnerabilities, four of them classified as high severity. For businesses running web applications, APIs, or backend services built on Node.js, there's a good reason to review the update.

But one of the most interesting vulnerabilities in the release wasn't really specific to Node.js at all.

CVE-2026-111497 affects Brotli, a widely used compression library originally developed by Google. The same underlying issue can affect software written in other languages, including Python applications and software using affected .NET components.

That's what makes this particular disclosure worth looking at more closely. An organization might have a perfectly good process for updating Node.js and still miss the same vulnerability somewhere else in its environment.

And that's before we get into the other nine vulnerabilities included in the release.

What Was Fixed in the October Node.js Security Update?

The official Node.js security announcement covers issues involving DNS resolution, TLS certificate validation, HTTP behavior, compression, and filesystem permissions.

These aren't all variations of the same bug. They affect different components and have different conditions for exploitation.

Some of the vulnerabilities addressed in the release include:

The release also included additional lower-severity vulnerabilities and updates to dependencies such as c-ares, OpenSSL, and Undici. The table highlights six issues rather than reproducing the entire advisory.

The classifications shown are from the Node.js project. The same underlying vulnerability may receive a different severity score in another product or advisory system.

The DNS and TLS problems deserve attention in their own right. For example, CVE-2026-105482 involves the way Node.js handles hostnames containing null bytes. Under the affected conditions, a hostname could be truncated before resolution, potentially causing an application to connect to a different destination than the developer intended.

The TLS issues involve how certificate validation handles certain IP address representations. Depending on how an application establishes connections and validates identities, these flaws could weaken protections that developers expect TLS to provide.

Not every application will be equally exposed to every issue. The relevant Node.js version, application behavior, configuration, and use of the affected APIs all matter.

Rather than working from severity ratings alone, development teams should review the complete advisory and determine which vulnerabilities are relevant to their applications.

Broccoli2Shell: The Vulnerability That Goes Beyond Node.js

The issue that initially caught my attention was CVE-2026-111497, also called Broccoli2Shell.

It involves Brotli, a compression algorithm that's become widely adopted because it compresses data efficiently without requiring much processing time.

Compression libraries aren't usually something application teams spend much time thinking about. They're a relatively low-level part of the software stack. You rely on them to encode and decode data, and most of the time they just work.

The problem here is in the decoder.

According to the Node.js advisory, malformed compressed input can cause the Brotli decoder to write beyond the end of an internal memory buffer.

The affected streaming decoder incorrectly handles a particular invalid block transition. Instead of recognizing the malformed input as an error, it can continue adding bytes to a fixed-size internal buffer.

That can corrupt process memory.

Depending on the circumstances, the result could be an application crash, disclosure of information from memory, or remote code execution.

Why Does This Affect Other Technologies?

Brotli is used by considerably more software than Node.js.

Other projects have incorporated Google's Brotli decoder into their own applications, packages, and runtimes. That includes Python packages such as Brotli and brotlicffi, along with a wider range of products and software components.

The Broccoli2Shell technical resource documents affected implementations and their available fixes.

This is particularly relevant for businesses with applications built on multiple technology stacks. A Node.js update won't address an affected .NET application, and updating a .NET runtime won't automatically fix independently vulnerable Python packages.

This is also where vulnerability tracking can become confusing.

Different products may use different advisory identifiers for related problems, and in some cases multiple CVEs can describe different manifestations of the same underlying issue.

You can have one vulnerable library affecting several software ecosystems, with different maintainers publishing their own fixes on different schedules.

I think that's one of the more important things for development teams to understand about this incident.

That doesn't mean every application using Brotli is necessarily exploitable. An attacker still needs a way to reach the vulnerable decoder under the relevant conditions.

But it's worth investigating where that decoder is used, even outside your Node.js applications.

What Makes Remote Code Execution So Dangerous?

Remote code execution, often abbreviated as RCE, is one of the categories of vulnerabilities I take particularly seriously.

The reason is straightforward. If an attacker can successfully exploit an RCE vulnerability, they may be able to execute code of their choosing on the affected system.

That goes well beyond making an application crash or return the wrong information.

Consider a fairly ordinary web application. It has a backend service and a database containing customer records.

Let's say an attacker finds a way to exploit a remote code execution vulnerability in that application.

Depending on the privileges available to the compromised process, the attacker might be able to write code that retrieves customer records from the database and sends them to another system.

Or the attacker might try something less immediately obvious, such as installing additional malicious software or modifying application behavior.

The exact consequences depend on the application architecture, service account permissions, and other security controls. Remote code execution doesn't automatically provide unlimited access to an entire environment.

But it can give an attacker capabilities that were never intended to be available remotely.

Does Every Vulnerable Node.js Application Face the Same Risk?

No. For CVE-2026-111497, the relevant question is whether an attacker can provide specially crafted Brotli-compressed data that the application passes to the vulnerable decoder.

An application that never processes untrusted Brotli data may have a different exposure profile than an API or service that routinely decompresses data from external sources.

But teams also need to consider how Brotli decompression can happen indirectly.

For example, HTTP clients may automatically decompress Brotli-encoded responses from external servers. Web frameworks and middleware may also decompress incoming request bodies before application code processes them.

The Broccoli2Shell technical guidance identifies these less obvious paths to the vulnerable decoder, including certain uses of Node.js fetch(), Express, and body-parser.

For a vulnerability with potentially serious consequences, I'd want to verify how an application actually handles compressed data rather than rely on assumptions about how it was built.

Which Node.js Versions Need to Be Updated?

The Node.js project released patches on October 21 for its 22.x, 24.x, and 26.x release lines.

The following versions address the issues covered by the security release:

Applications running earlier releases in these lines should be updated to the applicable patched version or a later supported security release.

Older, end-of-life Node.js release lines do not receive these fixes. Organizations still running them should plan to migrate to a supported version.

The project's release schedule provides information about supported versions and end-of-life dates.

What About Applications That Use Brotli Outside Node.js?

Those need to be evaluated separately.

For example, the Broccoli2Shell advisory identifies affected versions of the Google Brotli C library and Python packages, including patched versions for those implementations.

Microsoft's .NET guidance also distinguishes between deployment models. Framework-dependent applications need an updated runtime and a restart, while self-contained applications must be rebuilt and republished with the patched runtime. Containerized applications need updated images.

Updating Node.js won't fix a vulnerable decoder independently bundled with a Python application, included in a different runtime, or packaged into another software product.

That distinction is particularly important in production environments where different application instances may be running different versions.

What Should Businesses Do Right Now?

If your organization runs Node.js applications, the immediate goal is to identify affected systems, deploy the available fixes, and confirm that the applications are actually protected.

I would work through the following steps.

1. Inventory Your Node.js Applications

Identify applications, APIs, background services, and integrations that rely on Node.js.

Include development, staging, and production environments. Check the actual deployed versions rather than assuming every environment uses the same release.

If you use containerized applications, inspect the versions included in your deployed images.

2. Review the Entire October Security Release

Don't limit the assessment to Broccoli2Shell.

The October 21 release addressed multiple issues, including vulnerabilities affecting DNS resolution and TLS certificate validation.

Review the official Node.js advisory to understand which versions and APIs are affected.

Applications that perform outbound network requests, validate certificates, process compressed input, or use other affected functionality may require closer review.

3. Check for Vulnerable Brotli Implementations Elsewhere

Because CVE-2026-111497 involves a shared dependency, look beyond Node.js.

Review applications and products that use vulnerable versions of the Brotli decoder, especially where untrusted compressed data is processed.

For teams using .NET, consult Microsoft's October 25 advisory and check which runtimes and deployment models are in use.

Don't overlook indirect decompression through HTTP clients, web frameworks, or middleware. Application code may never explicitly call Brotli while still passing attacker-controlled compressed data to an affected decoder.

Dependency inventories and software bills of materials can help. When those aren't available, you may need to examine package manifests, build configurations, container images, and vendor advisories.

4. Deploy the Fixes and Test the Applications

Apply the appropriate patched Node.js version and any necessary dependency updates.

Test the functionality that matters most to the business, including APIs, integrations, authentication, data processing, and other critical workflows.

For production environments, follow your normal deployment controls while giving security updates the priority they warrant.

That may require coordinating maintenance windows, validating application compatibility, and preparing a rollback plan if an unrelated problem appears.

A rollback should never be treated as a complete security solution. If reverting would reintroduce the vulnerability, the team needs an alternative mitigation or containment plan.

5. Verify the Actual Production Environment

After deployment, confirm that affected services are running patched versions.

Check all instances, including background processes, containers, and systems that may not have been included in the initial update.

If there's evidence that a vulnerable application may have been exploited, involve the appropriate security or incident response personnel before taking actions that could destroy useful forensic evidence.

Finally, document what was updated and what still requires attention. That makes it easier to verify the work and follow up on any systems that couldn't be remediated immediately.

Why Dependencies Make Application Security Complicated

Something I've been thinking about since the Broccoli2Shell disclosure is how much responsibility comes with using someone else's software.

And I don't mean that as an argument against open-source libraries.

Reusing software is one of the reasons we're able to develop sophisticated applications efficiently. If another team has already built a good compression library, there's usually no reason to write your own.

You get the benefit of their development work, testing, and experience.

But you also become dependent on that project's maintenance and security practices.

Your Direct Dependencies Aren't the Whole Picture

Most developers can probably tell you which major packages their applications use.

The harder question is whether they can identify all the dependencies those packages introduce.

A framework might depend on a library, which depends on another library, which includes a vulnerable component.

Those indirect relationships are called transitive dependencies.

Broccoli2Shell is a good example of why they matter.

A company may have no direct relationship with Google's Brotli project and still be running software that includes the vulnerable decoder.

Historically, maintaining a complete dependency inventory was difficult. Fortunately, our tooling has improved.

In .NET, for example, it's possible to enumerate transitive package dependencies. Container images and automated dependency analysis can also help teams understand what's included in their applications.

A Software Bill of Materials (SBOM) can provide a more structured inventory of software components and their relationships.

None of these approaches guarantees you'll identify every possible exposure. But they make it much easier to answer an important question when a security advisory arrives: Do we use this component anywhere?

Updating Dependencies Introduces Its Own Risks

There's another tradeoff worth considering.

Given the number of malicious packages and supply chain attacks we've seen, some development teams deliberately delay installing newly released dependencies.

The idea is to allow some time for a new release to be reviewed before adopting it.

That's a reasonable precaution, sometimes called a dependency cooldown.

But what happens when a new release contains the fix for a serious vulnerability?

You don't want a policy intended to improve security to prevent you from applying an urgent patch.

So teams need a way to make exceptions.

That means knowing who can approve an emergency dependency update, how the change will be tested, and how to deploy it safely.

Ideally, those steps are already familiar before a vulnerability is announced.

Sometimes the Bigger Issue Is the Application Itself

Not every application can be updated easily.

Older custom applications may depend on unsupported frameworks or libraries that haven't been maintained in years.

Changing one component might require updating several others. In some cases, the application itself needs to be modified to work with a supported runtime.

This is where security and software modernization start to overlap.

If an application is so difficult to update that a routine security patch becomes a major project, it's worth investigating whether the underlying architecture needs attention.

That doesn't automatically mean rebuilding the entire application.

Sometimes a targeted dependency replacement or framework upgrade is enough. Other situations call for a more substantial application modernization effort.

The right choice depends on the application's importance, its technical limitations, and the cost of maintaining it in its current state.

How Emergent Software Can Help

At Emergent Software, we build and maintain custom applications across a wide range of technologies.

That work doesn't end when an application is deployed. Frameworks change, dependencies are updated, security vulnerabilities are discovered, and business requirements evolve.

Part of our responsibility is helping clients keep their software maintainable as those changes happen.

One advantage of working across different client environments is that our engineers regularly encounter security developments affecting a variety of technologies.

We saw that with the recent PHP2Shell disclosures, when our team proactively contacted clients and prospective clients whose systems we knew relied on PHP.

The same principle applies to Node.js and other application dependencies.

If a vulnerability affects a component used by a client's software, we can help evaluate the exposure, understand the available fixes, and determine what needs to change.

Depending on the situation, that might involve:

Sometimes the answer is a straightforward update. Other times, a vulnerability exposes a problem that's been building for years.

We can help clients understand the difference and make a decision based on the actual technical and business implications.

What I'd Take Away from This Node.js Release

The immediate priority for organizations running affected Node.js versions is to apply the security updates and verify that the fixes are deployed.

I'd also make sure the team has reviewed all the vulnerabilities in the release, not just the one attracting the most attention.

But I think there's a longer-term point here that's worth remembering.

Broccoli2Shell demonstrates how a vulnerability in a relatively low-level component can affect applications across several different technologies.

Your developers may not have written the vulnerable code. They may not even have known it was included in the application.

That doesn't make the risk any less relevant to the organization responsible for running the software.

The more clearly you understand your application's dependencies, the easier it becomes to identify exposure and respond when something goes wrong.

And when an update is necessary, having a reliable way to test, deploy, and verify it makes an enormous difference.

Frequently Asked Questions

What Vulnerabilities Were Fixed in the October 2026 Node.js Security Release?

The October 21, 2026 release addressed 10 vulnerabilities, including four classified as high severity. The issues affected components such as the Brotli decoder, DNS resolution, TLS certificate validation, HTTP handling, and filesystem permissions. The complete list is available in the official Node.js security advisory.

Is CVE-2026-111497 a Critical Node.js Vulnerability?

Node.js classified CVE-2026-111497 as high severity. The underlying Broccoli2Shell vulnerability received a critical CVSS 4.0 score of 9.2 in separate vulnerability reporting. The difference reflects the scoring and assessment context, so businesses should evaluate their actual exposure rather than relying on a single severity label.

Which Node.js Versions Fix the October 2026 Vulnerabilities?

The October 21 security updates were released as Node.js 22.23.4, 24.22.1, and 26.12.1. Organizations should use the applicable patched release or a later supported security release. End-of-life versions should be replaced with supported versions.

What Is Broccoli2Shell?

Broccoli2Shell is the name used for CVE-2026-111497, an out-of-bounds memory write vulnerability in the Brotli decoder. Under certain conditions, specially crafted compressed data can cause memory corruption, potentially resulting in an application crash, information disclosure, or remote code execution.

Does Broccoli2Shell Affect Software Other Than Node.js?

Yes. The underlying Brotli decoder is used across several software ecosystems. Certain Python packages and .NET applications using affected implementations may also require updates. Microsoft published out-of-band security updates on October 25 for .NET 8, 9, 10, and 11 Release Candidate 3. Organizations should consult the appropriate product advisories to identify affected versions and fixes.

Can an Application Be Exposed Through Brotli Without Explicitly Calling Its Decoder?

Yes. HTTP clients, web frameworks, and middleware can decompress Brotli data automatically. For example, an application that retrieves data from an external server may process a Brotli-compressed response through an affected library without directly calling a Brotli decompression API. Teams need to assess those indirect paths as well.

Can a Node.js Application Still Be Vulnerable After an Update?

Potentially. The update may not be active until the application restarts or is redeployed. An application may also include independently vulnerable dependencies that aren't fixed by upgrading Node.js. Teams should verify the versions actually running in production.

How Can Businesses Improve Node.js Application Security?

Maintain supported Node.js versions, track direct and transitive dependencies, review official security advisories, and test updates before deployment. Automated dependency analysis, software inventories, and established emergency patching procedures can also help teams respond more effectively to newly disclosed vulnerabilities.

Sources and Further Reading

The technical details and version information in this article are based on the following project and security advisories:

• Node.js: October 2026 Security Releases

• Broccoli2Shell: Technical Vulnerability Resource

• Microsoft: October 2026 Out-of-Band .NET Security Updates

• Node.js: Previous Releases and Support Schedule

• CISA: Software Bill of Materials Resources