HTTP2Shell (CVE-2026-111497): WordPress and Next.js exposure

HTTP2Shell is CVE-2026-111497, a flaw in Google's Brotli decoder that can corrupt memory when software decompresses malicious data. Also called Node2Shell and Broccoli2Shell, it has fixes in Node.js 22.23.4, 24.22.1 and 26.12.1, plus Brotli 1.0.10, 1.1.1 and 1.2.1. Update the runtimes and libraries that decode untrusted Brotli, or temporarily block incoming Content-Encoding: br requests before they reach an unpatched decoder.

For WordPress and WooCommerce owners, the question is which components decompress Brotli. A PHP-only site has a different exposure path from a headless site running Next.js on Node.js.

What happened between February and 25 October 2026?

The Node.js security announcement (opens in a new tab) rates the issue high and credits OpenAI Codex Security researchers Khai Tran and Sylvie Mayer.

Google's Brotli release history (opens in a new tab) confirms the three upstream security releases on 21 October.

What does the Brotli decoder bug do?

Brotli is a compression format developed by Google. It makes files smaller so websites can transfer them using less bandwidth.

Decompression means restoring that compressed data to its original form. Browsers commonly receive compressed HTML, CSS and JavaScript.

HTTP uses the Content-Encoding header to identify compression. Content-Encoding: br means the content uses Brotli.

The vulnerability sits inside the decoder, the software that decompresses Brotli data.

An out-of-bounds write happens when software writes beyond the memory space reserved for it. This can damage nearby data, crash the process or create opportunities for an attacker to control execution.

What went wrong inside the decoder?

The CVE record for CVE-2026-111497 (opens in a new tab), assigned by Google, identifies an out-of-bounds write in the Brotli decoder.

The record assigns CVSS v4.0 severity 9.2 and identifies CWE-787 (out-of-bounds write) and CWE-252 (unchecked return value).

Node.js describes the failure more precisely.

When the decoder encountered an invalid block switch, it reported that more input was needed. It should have reported a permanent format error.

The streaming decoder therefore continued appending incoming bytes to an internal eight-byte buffer.

That could corrupt adjacent process memory.

The reported consequences include denial of service, memory disclosure and remote code execution (RCE), where an attacker causes a program to run commands.

The affected upstream Brotli range is 1.0.3 through 1.2.0, excluding the fixed maintenance releases 1.0.10 and 1.1.1.

The defining exposure condition is that software decompresses Brotli data an attacker can control. Merely serving compressed website assets does not establish that condition.

Which WordPress, Next.js and server stacks are exposed?

As of 25 October 2026, affected software spans multiple languages and infrastructure components.

What matters for a classic WordPress site?

A conventional WordPress installation runs PHP on a web server.

The reviewed advisories do not identify WordPress core, WooCommerce core or PHP core as directly affected.

That does not prove every PHP hosting stack is safe.

For example, a PHP extension that bundles vulnerable Brotli code would need examination. A PHP application using libcurl could also reach a vulnerable system Brotli decoder if its HTTP client enables decompression of untrusted Brotli responses.

Neither path is confirmed for WordPress or PHP core in the reviewed sources.

Ask your hosting provider which Brotli and curl libraries are installed, whether they decode untrusted responses, and whether their packages contain the fix.

What matters for a headless WordPress site?

In a headless WordPress setup with a Next.js front end, the WordPress API and the Node.js application have separate security responsibilities.

The Next.js server can fetch content, process images and run server-side code. Those operations deserve review wherever a library might decompress attacker-controlled data.

Vercel's Node.js security bulletin (opens in a new tab) confirms that Node.js does not automatically decode every incoming request. Exposure requires a decoding path.

Vercel deployed free WAF rules on 21 October for inbound requests. Those rules cannot inspect responses that application functions fetch from other servers.

Vercel-managed projects using supported Node.js 22.x or 24.x runtimes receive managed patch versions. Projects still configured for Node.js 20.x must select 22.x or 24.x and redeploy.

Self-hosted deployments must upgrade their own Node.js runtime.

Why did Node2Shell become Broccoli2Shell?

The first widespread nickname was Node2Shell because Node.js disclosed the issue on 21 October.

By 23 October, reports covered Python, Bun, Envoy, Istio and native libraries. Researchers began using HTTP2Shell to reflect the wider affected software.

Broccoli2Shell also circulated, including in Wiz Research reporting.

All three names identify CVE-2026-111497. The flaw is in Brotli decoding, not the HTTP/2 protocol.

Brandefense tracked the changing terminology and warned about suspicious tools offered under these names.

Its reporting describes public proof-of-concept repositories, supposed vulnerability checkers, exploit sales and cryptocurrency promotions.

Use the CVE identifier when checking vendor advisories. Avoid running unknown scanners against production servers or installing software from unsolicited security messages.

How do you check your running stack?

Checking the deployed software matters more than checking your development machine.

Step 1: Check Node.js inside the running application

Open a shell in the actual application environment and run:

node --version

For a Node.js application, compare the result against the fixed release in its major version line.

Also check the Brotli version bundled with that Node.js runtime:

node -p "process.versions.brotli"

This second command reports Node.js runtime metadata. The Node.js security release version remains the reference for confirming its fix.

If your application runs inside a container, execute these checks inside that container.

A container image is the packaged filesystem and runtime used to start an application. An older image may still carry the vulnerable decoder after the host operating system has been updated.

Rebuild the application using a patched image, then verify the running version again.

Step 2: Find code that decompresses Brotli

Check installed Express and body-parser versions:

npm ls express body-parser

According to Brandefense's source-code review, Express 5 with body-parser 2.x accepts Brotli-compressed JSON bodies by default through express.json().

Its review finds a different default in Express 4 with body-parser 1.x, which does not handle Brotli through that parser.

These distinctions apply to the named parser versions. Other middleware may still decode Brotli.

Search your tracked application code:

git grep -n -E 'createBrotliDecompress|brotliDecompress|express[.]json|bodyParser|fetch[[:space:]]*[(]'

Review each match, especially fetch() calls to external servers and routes accepting compressed request bodies.

A code search is an inventory tool, not proof of safety. Dependencies can decompress responses internally without exposing those function names in your application code.

Step 3: Check Python and server libraries

For Python, run this inside the application's active environment:

pip show brotli brotlicffi

The GitHub Python Brotli advisory (opens in a new tab) identifies the fixed package versions.

On Debian or Ubuntu, inspect the relevant packages:

dpkg -l 'brotli*' 'libbrotli*'

On RPM-based systems:

rpm -q brotli

For curl:

curl -V

According to Aikido, curl -V can show brotli among the supported Features. This indicates Brotli support, but does not prove that the linked decoder has been patched.

Also inspect how your application uses libcurl.

As of 25 October 2026, Brandefense reported these distribution states:

• Debian bookworm and trixie had fixed packages, including DSA-6582-1 for trixie. Sid was also fixed.
• Debian forky still lacked a listed fix.
• Ubuntu listed Brotli as needing evaluation.
• RHEL 8, 9 and 10 were affected, without a listed fixed Brotli package. Red Hat also identified affected Firefox and Thunderbird packages.

Distribution maintainers can backport security fixes into packages bearing older upstream version numbers. Check your exact release against its vendor notice.

Which versions fix the vulnerability?

Envoy 1.36.12 also contains the fix, but that branch is unsupported. Istio 1.29 has reached end of life, so operators should prefer a supported branch.

Node.js 20.x and older lines, along with 25.x, are end of life and receive no fix for this issue. Migrate Node.js 20 deployments to a patched 22.x or 24.x release.

An end-of-life release is software whose regular security maintenance has ended.

The version guidance above follows the vendor advisories and Aikido's cross-platform Brotli investigation (opens in a new tab).

After updating, rebuild affected applications and container images. Restart workers, background jobs, scheduled processes and all deployed replicas.

For Bun applications, rebuild executable files created with bun build --compile. The runtime is embedded into those files.

For system libraries, install the security-fixed package from your distribution rather than replacing operating-system files with a manually downloaded library.

What can you block until patches are installed?

Temporary controls reduce exposure. They do not repair the decoder.

Reject Brotli-compressed incoming requests

A web application firewall (WAF) filters HTTP traffic before it reaches your application.

At Cloudflare or another edge proxy, reject incoming requests whose Content-Encoding contains the br encoding token.

Match encoding names without case sensitivity, including comma-separated values. Apply the check before any vulnerable component decompresses the request.

The guide to writing Cloudflare WAF rules for WordPress explains where to configure request filtering.

This can break legitimate clients sending compressed request bodies. Test API integrations, direct-to-origin connections and alternate routes.

For Express applications using its JSON parser, a temporary setting is:

app.use(express.json({ inflate: false }));

This rejects compressed bodies handled by that parser, including gzip. Install it in the correct middleware order and test clients before deployment.

It does not protect other decoders or outbound requests.

Limit risky fetched responses

Server-side fetch() can decode Brotli responses.

Reject untrusted Brotli responses before decompression wherever your HTTP client allows that control. Removing br from Accept-Encoding alone is insufficient because a server can ignore the preference.

For self-hosted Next.js, a temporary image configuration is:

// next.config.js
module.exports = {
  images: {
    unoptimized: true,
  },
};

This disables Next.js image optimization. Images are served without that processing, which may increase transferred bytes or remove resizing benefits.

It does not protect other server-side fetches. Upgrading Node.js remains necessary.

Restrict process permissions

Run vulnerable services as unprivileged users.

Limit filesystem access, and keep unnecessary credentials out of process environment variables. This reduces what code running inside a compromised process can access.

Such restrictions do not prevent memory corruption or service crashes.

What is known about exploitation as of 25 October 2026?

The official advisories classify the vulnerability as capable of serious memory corruption.

The CVE record assigns a critical CVSS v4.0 score of 9.2. Node.js rates its bundled-decoder issue high.

CISA's assessment attached to the CVE record listed exploitation as "none" on 22 and 23 October.

Brandefense also reported that the CVE was absent from CISA's Known Exploited Vulnerabilities catalog on 23 October.

That does not establish that exploitation is impossible. It means confirmed exploitation had not been recorded in those sources.

Brandefense found public proof-of-concept repositories within hours of the disclosure.

Its review describes code that reportedly crashes unpatched Node.js installations. Publicly demonstrated, reliable remote code execution was not established by that review.

Researchers have separately claimed command execution. Vercel's bulletin states that researchers demonstrated memory disclosure and command execution against unpatched Node.js releases.

One researcher cited by Brandefense disputes the wider execution impact and argues for denial of service instead.

There was no confirmed exploitation in the wild in the reviewed evidence as of 25 October 2026.

Wiz Research also reported vulnerable resources in 91% of cloud environments covered by its telemetry. Brandefense attributes that figure to Wiz. It is a measurement from one vendor's data, not proof that those systems were exploited.

HTTP2Shell exposure check you can copy

Use this checklist when asking your developer, hosting provider or managed platform for confirmation.

Node.js | node --version inside running app/container | Fixed: 22.23.4 / 24.22.1 / 26.12.1
Next.js | Check deployed Node.js runtime and hosting settings | Same Node.js fixes; Vercel 20.x: move to 22.x/24.x and redeploy
Bun | bun --version; check compiled executables | Fixed: 1.4.4
Python | pip show brotli brotlicffi | Fixed: brotli 1.2.1 / brotlicffi 1.2.1.0
Envoy/Istio | Check deployed proxy image and control-plane release | Envoy: 1.40.0 / 1.39.3 / 1.38.6 / 1.37.8; Istio: 1.31.2 / 1.30.6 / 1.29.9
curl/libbrotli | curl -V; dpkg -l '*brotli*' or rpm -q brotli | Brotli: 1.0.10 / 1.1.1 / 1.2.1 or vendor-fixed package
Edge rule | Inspect WAF/proxy request-header rules | Temporarily reject incoming Content-Encoding containing br

A version check identifies a component requiring review. Exposure also depends on whether it decodes attacker-controlled Brotli.

For your WordPress or WooCommerce site, ask the host to confirm the installed Brotli and curl packages, their decoding behavior, and the applicable vendor security updates.

For a headless site, request the deployed Node.js version and evidence that every instance has been restarted or redeployed.

If the site owner cannot manage those checks, ongoing WordPress maintenance and monitoring provides a place to arrange the required operational review.