Node.js Brotli Flaw: What Store Owners Need to Patch

Node.js Brotli Flaw: What Store Owners Need to Patch
Node.js Brotli Flaw: What Store Owners Need to Patch
Affiliate disclosure: This post contains affiliate links. If you buy through them, I may earn a commission at no extra cost to you. Full disclosure

Node.js patched a Brotli decompression flaw on October 21 that can crash a server, leak memory or let an attacker run code.

If you run a hosted Shopify store, you do not run a Node.js server, so your exposure is second-hand. It sits in the things bolted to your store: custom apps, headless storefronts, self-hosted automation tools, supplier-feed scripts and whatever your agency deployed last year. For readers of Ecommerce Paradise who have a developer, a custom app or a homegrown automation, this is a patch-this-week item. Everyone else needs three questions and one email.

Below: what the Node.js project fixed, how the same bug reached Python and .NET by October 26, how much of the severity claim holds up, which store stacks sit in the blast radius, and a five-step list you can finish before Friday. It also ties back to the PHP2Shell exploitation report I covered earlier, because this is another server-side flaw that lands on store hosts.

Patching servers is one job. Forming your store’s LLC the right way is the other, and Northwest Registered Agent is the best LLC formation service for ecommerce owners. It does not sell your address and puts its own address on your public filings, which beats the cheap formation sites that upsell you after checkout. Start your LLC the right way with Northwest →

Node.js Brotli Flaw CVE-2026-111497: What Was Patched and When

The Node.js project shipped security releases on Wednesday, October 21, covering versions 26.12.1, 24.22.1 and 22.23.4, according to its official security advisory. The batch fixed ten CVEs. Four are rated High, and one of them is CVE-2026-111497, the Brotli decoder bug.

Per the advisory, the flaw lets malformed compressed input write past the end of an internal decoder buffer. The cause, in the advisory’s words: “An invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer.”

The advisory states the impact plainly. An attacker who can supply Brotli data that an application decompresses with node:zlib “can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution.”

Brotli is a compression format Google developed. Browsers and servers use it to shrink web pages and API responses, so it sits in a lot of request and response paths. Node.js bundles its own copy of the decoder. That detail matters later, because updating your operating system does not touch it.

Semgrep published a post on October 22 that spells out who is reachable. Exposure depends on how an application touches the decoder, not just on running Node. Per Semgrep, the risky paths are servers that accept request bodies (Express 5 apps using body-parser 2.x with inflation enabled, Koa with co-body, Fastify with @fastify/compress), apps using Node’s built-in fetch() against a source an attacker can influence, and code that passes untrusted data straight to createBrotliDecompress(). Semgrep says Express 4 apps do not have the same default request path and calls the bug “not universally exploitable.”

On the proof side, The Hacker News reported on October 23 that researchers at Imperva demonstrated code execution on the official Node.js 24.22.0 Docker image for Linux arm64. It took several attempts. As of October 22, per the same report, there were no reports of exploitation in the wild.

BleepingComputer’s October 26 coverage puts the vulnerable upstream Brotli range at 1.0.3 through 1.0.9, 1.1.0 and 1.2.0, with fixes in Brotli 1.0.10, 1.1.1 and 1.2.1. Public proof-of-concept exploits exist, and BleepingComputer found no confirmed malicious use.

One more line from the advisory matters if you inherited a server from a contractor: “End-of-Life versions are always affected when a security release occurs.” Node 20.x and 25.x get no fix. They have to be replaced, not patched.

How a Compression Library Bug Hit Node.js, Python and .NET

The timeline runs longer than the headlines suggest. Per BleepingComputer, upstream Brotli fixes were first committed to source in February. Node.js and Google released stable fixes on October 21, public disclosure followed on October 22, and Python packages with fixes appeared on PyPI on October 23.

The Python side is wider than most store owners would guess. BleepingComputer lists urllib3 with the brotli extra, requests, httpx and aiohttp with speedups as affected when configured with a vulnerable decoder. The fixed packages are Brotli 1.2.1 and brotlicffi 1.2.1.0. Sysdig’s technical write-up adds Bun 1.4.3 and earlier to the list (fixed in 1.4.4) and notes that, as of October 23, Debian’s tracker showed no fixed package for either Brotli or nodejs.

Then Microsoft joined in. On Sunday, October 26, it released out-of-band .NET updates for the same flaw, per BleepingComputer: .NET 8.0.33, 9.0.22, 10.0.14 and .NET 11 Release Candidate 3. Microsoft says apps are exposed if they process Brotli through ASP.NET Core request decompression, HttpClient automatic response decompression or the Brotli compression APIs. Brotli decoding is not on by default in a standard .NET install, so an app has to opt in. Microsoft advised updating as soon as possible.

The severity story is not settled, and the sources disagree. Sysdig reports that Google scores the bug 9.2, Critical, on CVSS v4.0, while the Node.js project rates it High. Sysdig also notes that some researchers argue the practical impact is a denial of service, and that the fix commit itself describes the bug as low severity and hard to exploit. In one team’s tests, blind remote code execution failed with address randomization turned on. Vercel, per The Hacker News, reported memory disclosure on unpatched 22.x, 24.x and 26.x lines and added inbound request blocking rules on October 21.

That spread is the honest picture. A reliable remote shell has been shown only in a controlled setup. Crashes and memory exposure are the easy outcomes. The vendors are patching on an emergency schedule anyway. For a comparison, my earlier report covers the PHP2Shell patches as attackers probed WordPress stores.

Which Store Stacks Are Exposed to the Node.js Brotli Bug

My read is that the severity argument matters less than reachability. If nothing you own decompresses untrusted Brotli data on Node, Python or .NET, the score is academic. If something does, a patch costs an afternoon and being wrong costs you a server that sits next to your customer data.

Here is where I would look first, in order of how often a high-ticket store owner has it. First, a headless or custom storefront built on Node, hosted on Vercel or a VPS. I explained the tradeoffs in my guide to Shopify headless commerce. The wider headless commerce explainer covers when it is worth it. The cost of that flexibility is that you now own a runtime.

Second, custom Shopify apps your agency built for quoting, supplier sync or inventory. These are usually small Node or Python services that call supplier APIs, which is exactly the outbound-fetch path Semgrep flagged. Third, self-hosted automation. The n8n tool runs on Node.js, and if you host it yourself you own its patch schedule. My comparison of n8n alternatives covers the options. The Zapier alternatives roundup covers hosted tools where someone else carries that burden.

Fourth, vendors. Your email platform, your helpdesk and your CRM run their own servers, and you cannot patch them. You can ask. A single email to Klaviyo support or your Klaviyo account rep takes two minutes. The same goes for Gorgias if it holds your customer tickets. I found no vendor advisory from either in the sources I reviewed, which is not the same as no exposure, only no public statement.

Fifth, hosting. If you rent a VPS or managed server from a host such as Cloudways, ask whether any Node.js or Python tooling runs on the account and who patches it. On unmanaged plans the answer is you. On managed plans the answer is in the support docs, and a ticket gets it in writing. The same question applies to a dedicated box at Liquid Web.

Hypothetical math, not a reported figure: take a store doing $90,000 a month, which is about $3,000 a day. Two days offline while a contractor cleans a compromised server is roughly $6,000 in missed sales. Add a day of wasted ad spend at $150 and the time spent rotating keys, and a “low severity” bug has cost more than a year of any hosting plan. Add disputes if a payment path was touched and you are reading my guide on chargeback prevention for high-ticket stores under pressure.

Thresholds I would use. If you have no custom code and no self-hosted tools, send the vendor email and move on. If you have one custom app on a patched-line Node version, update within days. If a public-facing service runs Node 20 or older, treat it as this week’s job, because there is no patch coming for that line. And if a payment or order path touches the affected service, read my piece on why your payment processor is a single point of failure and decide what happens when that service is down.

My bias, stated plainly: the cleanest fix is owning less infrastructure. That is why my turnkey done-for-you service builds high-ticket stores on hosted Shopify, where your team does not maintain a runtime. Fewer moving parts means fewer emergency weekends like this one.

Would you rather never own a server patch list? My team can build and run the store for you. See the turnkey done-for-you service →

Node.js Brotli Patch Checklist for Store Owners This Week

Five moves, in order. Most take under an hour if you know who built what.

  1. Inventory what runs code. Write down every custom app, headless storefront, automation server and script that talks to your store. If you use a password manager for shared logins, your 1Password alternatives comparison helps you keep the hosting and vendor accounts in one place. Mark each as Node, Python, .NET or “not sure.”
  2. Send the three-question email. To your developer, agency and each app vendor: Which runtime and version do you run? Does anything decompress Brotli, through request middleware or outbound fetch? When will you be on Node 22.23.4, 24.22.1 or 26.12.1, or the equivalent? Get the answer in writing.
  3. Patch and redeploy. Node 22.23.4, 24.22.1 or 26.12.1. Python Brotli 1.2.1 or brotlicffi 1.2.1.0. .NET 8.0.33, 9.0.22 or 10.0.14. Rebuild container images from a patched base and restart processes. Updating the system Brotli library does not fix an app that ships its own copy. If you need hands, a freelance developer from Upwork can run a short audit against that list.
  4. Replace end-of-life runtimes. Node 20 and older get no fix. Move to 22.x or 24.x. If a migration cannot happen this week, Sysdig suggests express.json({ inflate: false }) to reject compressed bodies, and BleepingComputer says blocking Brotli-compressed requests at the proxy helps with inbound traffic only. Neither covers a malicious response fetched from a server you do not control.
  5. Rotate secrets if anything stayed unpatched. Treat API keys, database passwords and Shopify tokens on an exposed service as suspect and rotate them. My write-up of the Railway breach and store API keys walks through the order. Review the Turnkey service details and email me with questions before ordering.

Managed WordPress and Shopify stores can skip steps three and four. Steps one and two still apply to anything custom, including the DreamHost-style password resets a host can force on you without warning.

Frequently Asked Questions

Does the Node.js Brotli flaw affect my Shopify store?
Not directly if you run standard hosted Shopify with no custom servers. I found no Shopify advisory about it in the sources I reviewed. Your exposure is whatever Node, Python or .NET code you or your apps run outside Shopify, so start with the inventory step and read my high-ticket dropshipping basics if you are still choosing a platform.

Is anyone exploiting CVE-2026-111497 right now?
BleepingComputer reported no confirmed malicious exploitation as of October 26, and The Hacker News reported none as of October 22. Public proof-of-concept exploits exist, so that status can change quickly.

Which versions fix it?
Node.js 22.23.4, 24.22.1 and 26.12.1. Brotli 1.0.10, 1.1.1 or 1.2.1. Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Bun 1.4.4. Microsoft shipped .NET 8.0.33, 9.0.22 and 10.0.14, plus .NET 11 Release Candidate 3.

Is a WordPress or WooCommerce store affected?
WordPress itself runs on PHP, not Node, so the Node bug is not the same as the PHP flaws in my PHP2Shell coverage. Ask your host whether any Node or Python tooling runs on the account. A host like SiteGround can answer that from its support team.

Can I just update my server’s operating system?
No. Per the tracking material cited by BleepingComputer, updating the system Brotli library does not fix Node.js or any app that bundles its own copy. You have to update the runtime or package and restart.

I am still planning my first store. Does this change my platform choice?
It is one more argument for starting on Shopify and adding custom code only when revenue justifies it. My free high-ticket niches list is a good place to start. Keeping the stack small is the point.

Want to work through your stack with other store owners and me inside the community? Join the Skool community →

Subscribe to the YouTube channel for daily breakdowns. More breaking news coming through the day. If you only do one thing from this post, send the three-question email today and keep the replies in one folder. When the next emergency patch lands, you will know in minutes who owns what.

Related Articles

If this was useful, these go deeper: