There is a particular kind of dread that comes from a vulnerability with a catchy name and a lot of retweets. You have maybe fifteen Node services, some in containers nobody has rebuilt since spring, and the question is not “should I patch” but “where do I even start?” This post is that start.
Here is how to check whether your Node.js app is exposed to Node2Shell (CVE-2026-111497), roughly in the order we would do it. Fifteen minutes gets you a first answer for one service.
1. Find every Node.js runtime you own
Not just the production server. Look at container images, serverless functions, CI runners, staging machines, a laptop that runs a cron job, the old admin tool someone set up two years ago. Then run node -v on each one, or read the base image tag for containers.
You are looking for anything below 22.23.4, 24.22.1 or 26.12.1. Versions 20 and older, 23 and 25 are end of life, affected, and will not get a fix.
2. Look for Express and body-parser versions
Reports on this flaw list Express 5.0.0 to 5.3.0 and body-parser 2.0.0 to 2.3.0 as a path in, specifically through the raw() and json() parsers handling Brotli compressed request bodies. Check with:
- npm ls express body-parser in each project
- Your lockfile, if the code is not checked out on the machine
Be careful with one conclusion. Being on a different Express version does not clear you if some other part of your code decompresses Brotli. And updating Express will not patch the runtime. It is a clue about where to look, nothing more.
3. Search your code for places that decompress untrusted data
Grep for the obvious ones: fetch( calls to URLs you do not own, Content-Encoding handling, brotli and zlib usage. Anything that takes a user supplied URL and fetches it deserves a second look. That covers link preview features, webhook testers, image proxies, import-from-URL buttons and scrapers.
Your server being safe to talk to is half the question. The other half is whether it is safe to listen to.
Outbound fetch is the case that surprises people, because nothing about it looks like an attack surface. You made the request. But if the server on the other end sends back a hostile Brotli response, your runtime still has to unpack it.
4. Reduce exposure while you wait for the upgrade
Upgrading is the actual fix. Node.js lists no workaround. These are stopgaps and they only cover part of the problem:
- Reject requests with Content-Encoding: br at your reverse proxy, load balancer or middleware. This reduces inbound exposure only.
- With body-parser, setting inflate: false makes it reject encoded request bodies before they are decompressed. It does not protect outbound fetch.
- Temporarily restrict outbound fetch for features that take arbitrary URLs.
A WAF rule is the weakest option here. Treat it as a sticking plaster.
5. Do not rely on logs to tell you it is fine
Imperva noted that unexpected process exits and decoder errors can help you prioritise investigation, but neither is a reliable sign of exploitation, and no indicators of compromise had been published when we looked. A clean log is not a clean bill of health. Patch, then watch.
If you want the background first, start with what Node2Shell actually is. If your fix involves leaving an old version behind, read upgrading Node.js after Node2Shell.
If you have a dozen services and nobody who has time to audit them, that is a normal situation, and it is the sort of job our software development team in Delhi NCR takes on. Browse our services or contact us with a list of what you run. Indian startups and SMEs are most of our work, so we know how thin the DevOps bench usually is.