If your product lets users type a regular expression (a log search box, an alerting rule, a URL routing rule, a “block messages matching” filter), you have handed them a way to burn your CPU. In a backtracking engine, a short pattern and a short input can keep a thread busy for seconds or years. The fix is not a better regex review process, because you are not the one writing the patterns.

The short answer: run user-supplied patterns on an engine that guarantees linear-time matching (RE2, Go’s regexp, Rust’s regex), cap pattern length, and reject features those engines do not support instead of quietly falling back. If you are stuck with a backtracking engine, run the match somewhere you can kill it on a deadline.

Why a backtracking engine is the problem

Python’s re, JavaScript’s RegExp (V8’s Irregexp) and .NET’s default engine are backtracking engines. When a match fails, they back up and try every other way the pattern could have split the input. For most patterns that is fast. For patterns with nested or overlapping repetition, the number of ways to split the input grows exponentially.

OWASP’s wiki page on ReDoS describes an “evil” regex as one with grouping with repetition where the repeated group contains repetition or overlapping alternation. Its examples include (a+)+, ([a-zA-Z]+)*, (a|aa)+ and (a|a?)+.

We timed the first one in Python 3.13.18 against a string of a characters followed by !, so the match has to fail:

import re, time

pat = re.compile(r'^(a+)+$')
pos = re.compile(r'^(?:a++)+$')   # possessive quantifier, Python 3.11+

for n in (18, 20, 22, 24):
    s = 'a' * n + '!'
    t = time.perf_counter(); pat.match(s); t1 = time.perf_counter() - t
    t = time.perf_counter(); pos.match(s); t2 = time.perf_counter() - t
    print(f"n={n:2d} backtracking={t1:8.4f}s possessive={t2:.6f}s")

n=18 backtracking=  0.0088s possessive=0.000005s
n=20 backtracking=  0.0429s possessive=0.000005s
n=22 backtracking=  0.1680s possessive=0.000003s
n=24 backtracking=  0.5356s possessive=0.000005s

Each additional two characters roughly quadrupled the time. Extrapolate to a 40-character input and one request ties up a worker for hours. Node.js 22 behaves the same way: /^(a+)+$/.test('a'.repeat(24) + '!') took 495 ms in our sandbox.

The possessive rewrite fixes this pattern because a++ refuses to give characters back. That is a valid fix when you write the pattern. It does nothing when a user writes it, because the user will not write the possessive version.

Two different threats

It helps to separate the cases, because the defences differ.

This article is about the second row. The third row is the most common way the second row happens by accident: someone builds new RegExp(userInput) to implement a “contains” search that never needed a regex.

Engines that are built for untrusted patterns

RE2. Google’s RE2 README states the design goal directly: it was built “to handle regular expressions from untrusted users without risk”, and “one of its primary guarantees is that the match time is linear in the length of the input string”. It also says its parser, compiler and execution engines “limit their memory usage by working within a configurable budget”. The price is features: RE2 “does not support constructs for which only backtracking solutions are known to exist”. That means no backreferences and no look-around.

Go’s regexp. The package uses RE2 syntax, and its source documents that the implementation “is guaranteed to run in time linear in the size of the input”.

Rust’s regex crate. Its README says “all regex searches in this crate have worst case O(m * n) time complexity, where m is proportional to the size of the regex and n is proportional to the size of the string being searched”. Its documentation says the crate “also, to a certain extent, supports untrusted patterns”, mainly “by limiting their size by default”, which you can tune with RegexBuilder::size_limit.

Note the m in that complexity. Linear in the input is not the same as free: a huge pattern still costs more to compile and run. That is why a pattern length cap belongs in front of every engine, safe or not.

Engines that say they are not

.NET. Microsoft’s regex best-practices page is unusually direct:

The .NET regular expression engine does not offer protection against untrusted patterns, and applications should not create regular expression patterns from untrusted user-provided values.

It adds that time-out values and RegexOptions.NonBacktracking (introduced in .NET 7, which “guarantees linear-time processing in the length of the input”) “help protect against accidental performance problems in developer-authored patterns. They are not intended as a security boundary against malicious patterns.” Use them for your own patterns, and do not treat them as permission to accept user-written ones.

Ruby. Ruby 3.2 added two ReDoS mitigations, described in the 3.2.0 release notes. A memoization-based matcher completes “most Regexp matching (about 90% in our experiments)” in linear time, at the cost of memory “proportional to the input length”. Because that optimization “cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around)”, Ruby also added Regexp.timeout, a global setting, and a per-regex timeout: keyword on Regexp.new. Both help. Neither turns Ruby’s engine into one designed for hostile patterns.

Python and JavaScript. Python’s re documentation describes no match timeout. Python 3.11 added possessive quantifiers and atomic groups (?>...), which help you write safer patterns but do nothing about patterns you did not write. JavaScript’s RegExp has no timeout either. V8 has shipped an experimental non-backtracking engine since V8 8.8, behind --enable-experimental-regexp-engine, which adds a non-standard l (“linear”) flag. V8’s own post calls it experimental “because Irregexp is orders of magnitude faster than the new engine on most common patterns”. With the flag on, /^(a+)+$/l failed on a 50,000-character evil input in about 3 ms in our Node.js 22.23 test. Running production on an experimental V8 flag is a decision to make deliberately, not a default.

Accepting patterns also exposes you to bugs in the regex parser and compiler themselves, not just slow matching. Our write-up of GitLab CVE-2026-97229 covers a remote code execution flaw in how GitLab compiled regular expressions from CI/CD configuration. Using a small, heavily fuzzed engine reduces that risk too.

Pattern 1: Python with RE2

This uses the google-re2 package (we tested 1.1.20251105 with Python 3.13). It caps pattern length, compiles with RE2, and turns unsupported syntax into a clear error your API can return as a 400.

import re2

MAX_PATTERN = 256

def compile_user_pattern(pattern: str):
    """Compile a user-supplied pattern with RE2 or raise ValueError."""
    if len(pattern) > MAX_PATTERN:
        raise ValueError("pattern too long")
    try:
        return re2.compile(pattern)
    except re2.error as e:
        raise ValueError(f"unsupported or invalid pattern: {e}") from None

What happened when we ran it:

The same evil pattern that took half a second on 24 characters in re finished a million characters in milliseconds. Two practical notes from the test: RE2 logs parse errors to stderr through its own logging, so expect noise in your logs when users submit bad patterns. And do not catch the error and retry with re. That fallback reopens the exact hole you closed.

Pattern 2: Node.js with a killable worker

If you cannot add a native RE2 binding, isolate the backtracking engine. A worker thread can be terminated mid-match, which a setTimeout on the main thread cannot do: a regex blocks the event loop until it returns. This is tested on Node.js 22.23.4:

// safe_match.mjs: run an untrusted pattern in a worker and kill it after a deadline.
import { Worker } from 'node:worker_threads';

const WORKER_SRC = `
  const { parentPort, workerData } = require('node:worker_threads');
  const { pattern, flags, input } = workerData;
  try {
    parentPort.postMessage({ ok: true, match: new RegExp(pattern, flags).test(input) });
  } catch (e) {
    parentPort.postMessage({ ok: false, error: e.message });
  }
`;

export function safeTest(pattern, input, { flags = '', timeoutMs = 100, maxPattern = 256 } = {}) {
  if (pattern.length > maxPattern) return Promise.resolve({ ok: false, error: 'pattern too long' });
  if (!/^[gimsuy]*$/.test(flags)) return Promise.resolve({ ok: false, error: 'bad flags' });
  return new Promise((resolve) => {
    const w = new Worker(WORKER_SRC, {
      eval: true,
      workerData: { pattern, flags, input },
      resourceLimits: { maxOldGenerationSizeMb: 32 },
    });
    const timer = setTimeout(() => { w.terminate(); resolve({ ok: false, error: 'timeout' }); }, timeoutMs);
    w.once('message', (m) => { clearTimeout(timer); w.terminate(); resolve(m); });
    w.once('error', (e) => { clearTimeout(timer); resolve({ ok: false, error: e.message }); });
  });
}

Results:

• safeTest('^(a+)+$', 'a'.repeat(40) + '!') returned { ok: false, error: 'timeout' } after 103 ms. On the main thread that match would not finish.
• safeTest('^[a-z]+@example\\.com$', 'alice@example.com') returned { ok: true, match: true }.
• safeTest('(unclosed', 'x') returned the syntax error instead of throwing.

The cost: spawning a worker per call averaged 25.4 ms in our sandbox, over 20 calls. That is fine for saving a rule. It is too slow for matching every log line. For high-volume matching, keep a small pool of long-lived workers and replace any worker you have to terminate, or move to an RE2 binding. This is a containment pattern, not a fix: an attacker can still make every match hit the timeout, so rate-limit pattern submissions and count timeouts per user.

A checklist for features that accept patterns

1. Ask whether you need regex at all. Substring, prefix or glob matching covers most “search” features and has no ReDoS surface.
2. Pick a linear-time engine (RE2 or a binding, Go regexp, Rust regex) for any pattern a user can write, including admins and API clients.
3. Cap pattern length and, if you can, the number of patterns per user or rule set.
4. Reject unsupported features with a clear message. Never fall back to a backtracking engine.
5. Cap input length for each match. Linear time on a 2 GB input is still a lot of time. Our post on decompression bombs in Node.js covers the related problem of inputs that grow after you accept them.
6. If you must backtrack, isolate it. Use a worker or process you can kill, a hard deadline, and a memory limit. Ruby’s Regexp.timeout and .NET’s matchTimeout are useful extra layers.
7. Watch for it. Log match timeouts and compile failures by user, and alert on spikes.

Limits of this article

• Timings are from a shared cloud sandbox and will differ on your hardware. The growth rate, not the absolute numbers, is the point.
• We did not test .NET or Ruby directly, and we do not cover Java, PCRE or other engines here. Statements about them come from their documentation, quoted above.
• We tested one Python RE2 binding (google-re2). Node.js RE2 bindings exist, but we did not test one for this article.
• A linear-time engine removes catastrophic backtracking. It does not remove the need for size limits, rate limits or patching the engine itself.

Sources and verification

A secure file upload accepts only the types you need, decides the filename and extension itself, stores the bytes somewhere nothing will execute or serve them directly, and checks authorization again on download. The OWASP File Upload Cheat Sheet says it plainly: “There is no silver bullet in validating user content.” No single check is enough, so you stack them.

This guide builds that stack in Node.js and tests it. Versions: Node.js 22.23.4, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 and sharp 0.35.5, installed from npm on 2026-10-30.

Why uploads keep turning into breaches

Unrestricted upload is CWE-434. In the CISA KEV catalog (version 2026.10.29), 24 entries carry CWE-434, eight of them added in 2026. The count is a floor: not every KEV entry has a CWE assigned. The most recent is the Magento “PolyShell” bug we covered in Magento CVE-2026-48356: Patch and Hunt, where the fix included making sure upload directories can’t execute code.

The OWASP cheat sheet groups the risks into two kinds:

• Malicious files: exploits for the parser that processes the file, phishing documents, zip and XML bombs, overwriting existing files, and active content such as HTML or SVG that attacks other users.
• Public retrieval: if uploads are publicly reachable, attackers can enumerate other users’ files, use them for DoS, or host illegal content on your domain.

The endpoint, step by step

Here is the full server. Each control is explained below.

// Node.js 22, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 (package.json: "type": "module")
import express from 'express';
import multer from 'multer';
import { fileTypeFromBuffer } from 'file-type';
import { randomUUID } from 'node:crypto';
import { writeFile, mkdir } from 'node:fs/promises';
import path from 'node:path';

const UPLOAD_DIR = process.env.UPLOAD_DIR ?? '/srv/app-uploads'; // not under any static/public dir
const ALLOWED = new Map([            // detected type -> extension we will store
  ['image/png', 'png'],
  ['image/jpeg', 'jpg'],
  ['application/pdf', 'pdf'],
]);
const files = new Map();             // id -> { owner, mime, ext }; use your database in production

const upload = multer({
  storage: multer.memoryStorage(),   // bytes stay in memory until they pass checks
  limits: { fileSize: 5 * 1024 * 1024, files: 1, fields: 5, parts: 6 },
});

// Stand-in for your real auth middleware
function requireUser(req, res, next) {
  const user = req.get('x-demo-user');
  if (!user) return res.status(401).json({ error: 'login required' });
  req.user = { id: user };
  next();
}

const app = express();

app.post('/uploads', requireUser, upload.single('file'), async (req, res) => {
  if (!req.file) return res.status(400).json({ error: 'no file' });
  const detected = await fileTypeFromBuffer(req.file.buffer);   // magic bytes, not the client's Content-Type
  if (!detected || !ALLOWED.has(detected.mime)) {
    return res.status(415).json({ error: 'file type not allowed' });
  }
  const id = randomUUID();
  const ext = ALLOWED.get(detected.mime);
  await mkdir(UPLOAD_DIR, { recursive: true, mode: 0o700 });
  // Server-chosen name; 'wx' fails instead of overwriting; 0o600 = no execute bit
  await writeFile(path.join(UPLOAD_DIR, `${id}.${ext}`), req.file.buffer, { flag: 'wx', mode: 0o600 });
  files.set(id, { owner: req.user.id, mime: detected.mime, ext });
  res.status(201).json({ id });
});

const UUID = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/;

app.get('/files/:id', requireUser, (req, res) => {
  const meta = UUID.test(req.params.id) && files.get(req.params.id);
  if (!meta || meta.owner !== req.user.id) return res.status(404).end();  // authz on every download
  res.set({
    'Content-Type': meta.mime,                       // the type we detected, never the client's
    'Content-Disposition': `attachment; filename="${req.params.id}.${meta.ext}"`,
    'X-Content-Type-Options': 'nosniff',
    'Content-Security-Policy': "default-src 'none'; sandbox",
  });
  res.sendFile(`${req.params.id}.${meta.ext}`, { root: UPLOAD_DIR });
});

app.use((err, req, res, next) => {
  if (err instanceof multer.MulterError) {
    const status = err.code === 'LIMIT_FILE_SIZE' ? 413 : 400;
    return res.status(status).json({ error: err.code });
  }
  next(err);
});

app.listen(3000, () => console.log('listening on :3000'));

The x-demo-user header and the in-memory files map exist only so the example runs on its own. Replace them with your session middleware and a database table.

1. Authenticate before parsing, and only on the routes that need it

requireUser runs before upload.single(), so an anonymous request is rejected before Multer reads a byte of the body. Multer’s README warns: “Never add multer as a global middleware since a malicious user could upload files to a route that you didn’t anticipate.” Mount it per route, as above.

2. Set every limit

Multer passes limits straight to busboy, and the defaults in the Multer 2.5.0 README are generous: fileSize, files, parts and fields all default to Infinity. The README also notes that “Limits apply to the whole request; there is no per-file limit.” Set them to what the feature needs. Map LIMIT_FILE_SIZE to 413 and other Multer errors to 400 in your error handler, as the example does.

memoryStorage() holds the whole file in RAM, which is why fileSize matters. For large files, use disk storage into a private temp directory and run the same checks before moving the file into place. If you also accept compressed data, the limit has to apply after decompression; see Node.js decompression bombs.

3. Detect the type from content, against an allowlist

The Content-Type of each part is whatever the client says. OWASP: “it is trivial to spoof.” fileTypeFromBuffer() reads the file’s magic number instead, and we compare the result to a short allowlist of types the feature actually needs.

Know the limits of this check. The file-type readme says detection “is a best-effort hint. It does not guarantee the file is actually of that type or that the file is valid/not malformed.” It also covers only binary formats, “not text-based formats like .txt, .csv, .svg”. If you need text formats, validate them with a real parser.

4. Choose the name and extension yourself

The stored name is a UUID plus the extension mapped from the detected type. The user’s originalname is never used on disk, which removes the whole class of tricks OWASP lists for extensions (.jpg.php, .php%00.jpg, .pHp, .phtml, shell.asp:.jpg) and path traversal in filenames. If you need to show the original name, store it as data in your database and escape it on output.

The wx flag makes writeFile fail if the path exists rather than overwrite it. Mode 0o600 means no execute bit, and your process umask can only make it stricter.

5. Store outside anything that serves or executes files

OWASP ranks storage options in this order: a different host, then outside the webroot, then inside the webroot with write-only permissions. UPLOAD_DIR must not be inside express.static(), your nginx root, or a PHP document root. Private object storage (an S3 bucket with Block Public Access on, served by short-lived signed URLs) satisfies “different host”.

If files have to live under a web server’s document root, also turn off per-directory overrides there. OWASP’s example is Apache AllowOverride None, so an uploaded .htaccess can’t remap .png to the PHP handler. For PHP stacks, our php.ini hardening guide covers the upload-related settings.

6. Serve through a handler with defensive headers

The download route checks ownership on every request. Without that, a guessable or leaked ID becomes an IDOR. It then sets four headers:

Serving user files from a separate domain (for example a dedicated usercontent domain) adds one more layer: active content never runs on the same origin as your session cookies.

What we tested, and what got through

We started the server with UPLOAD_DIR set to a temp directory and sent ten requests with curl:

Both stored files were -rw-------. Test 4 is the one to remember. A PNG with code appended is still a valid PNG, so magic-byte detection passed it. It did no harm because of what came after: the traversal filename was ignored, the stored name ended in .png, the directory isn’t served or interpreted, and downloads go out as attachments with a sandbox CSP. Remove any one of those and the polyglot becomes more dangerous.

Re-encode images when you can

For images, OWASP recommends decoding and re-encoding to strip anything that isn’t pixels. With sharp, metadata is dropped by default (“The default behaviour, when withMetadata is not used, is to strip all metadata”, per its type definitions):

import sharp from 'sharp';
// limitInputPixels guards against decompression-style image bombs; sharp's default is 268402689 pixels
const clean = await sharp(req.file.buffer, { limitInputPixels: 40_000_000 }).png().toBuffer();

Run on the polyglot from test 4, the 97-byte input contained <?php; the 90-byte output did not. OWASP adds a caveat worth keeping: the image library “itself handles untrusted input”, so keep it patched and, for high-volume or high-risk uploads, run processing in a separate worker or sandbox. The file-type readme makes the same point for its own parser, recommending a size limit and “a worker thread with a timeout” for untrusted files.

Checklist

• Authenticate before parsing; mount Multer only on upload routes.
• Set fileSize, files, fields and parts.
• Detect type from content; compare to a short allowlist; reject text formats you can’t parse.
• Generate the stored name and extension; never write originalname to disk.
• Store outside the webroot or in private object storage, without execute permissions.
• Serve via a handler that checks ownership and sets attachment, nosniff and a sandbox CSP.
• Re-encode images; scan or sandbox documents if they will be opened by staff.
• Protect the upload form from CSRF if it uses cookie auth.

Limits of this article

• We tested one stack (Express 5.3.0, Multer 2.5.0). Other frameworks have different defaults; check their docs for limits and filename handling.
• We did not test antivirus scanning or Content Disarm and Reconstruction for Office or PDF files, which OWASP also recommends where applicable.
• The in-memory metadata map and header-based “auth” are placeholders and are not production-ready.

Sources and verification

A decompression bomb is a small compressed payload that expands into far more data than your service expects, enough to exhaust memory or tie up a CPU core. MITRE files it as CWE-409, “Improper Handling of Highly Compressed Data (Data Amplification)”. In Node.js, the defence is to count decompressed bytes and stop at a limit you choose. Node gives you that limit in one place, maxOutputLength on the one-shot zlib functions, and nowhere else. Streams, HTTP clients and custom middleware all need their own cap.

We ran every example below on Node.js 22.23.4. Results for each are in the text.

How big the amplification gets

We compressed 100 MiB (104,857,600 bytes) of zeros with each codec Node ships:

Zeros are the best case for a compressor, and the ratio for real data is far lower. That’s the point: an attacker picks the input. A request-body limit of 1 MB on the wire tells you nothing about the decompressed size.

The one-shot functions: maxOutputLength works

Node’s one-shot functions (zlib.gunzip, zlib.inflate, zlib.brotliDecompress, zlib.zstdDecompress and their *Sync forms) accept maxOutputLength. The zlib docs describe it as an option that “Limits output size when using convenience methods”. The default is buffer.kMaxLength, the largest Buffer Node can allocate, so without it you have no practical limit.

const zlib = require('node:zlib');

const LIMIT = 1024 * 1024; // 1 MiB of decompressed output

function safeGunzip(buf) {
  try {
    return zlib.gunzipSync(buf, { maxOutputLength: LIMIT });
  } catch (err) {
    if (err.code === 'ERR_BUFFER_TOO_LARGE') {
      throw Object.assign(new Error('decompressed payload too large'), { status: 413 });
    }
    throw err; // corrupt input, wrong format, etc.
  }
}

With the 100 MiB bombs from the table, gunzipSync, brotliDecompressSync and zstdDecompressSync all threw RangeError with code ERR_BUFFER_TOO_LARGE and the message “Cannot create a Buffer larger than 1048576 bytes”. The async zlib.gunzip() passed the same error to its callback.

Use the one-shot functions when the whole payload is already in memory and you can name a sensible maximum: a webhook body, a cached blob, a small config file.

Streams: maxOutputLength is ignored

The stream classes accept the same options object, so this looks right:

// Looks safe. Isn't.
zlib.createGunzip({ maxOutputLength: 1024 * 1024 });

In our test, piping the gzip bomb through that stream delivered all 104,857,600 bytes and finished without an error. The option is documented for the convenience methods only, and the stream path doesn’t enforce it. Nothing warns you.

The fix is a Transform that counts bytes after the decompressor and fails the pipeline when the count passes your limit:

const zlib = require('node:zlib');
const { pipeline, Transform } = require('node:stream');

// Fail the pipeline once decompressed output exceeds maxBytes.
function byteLimit(maxBytes) {
  let seen = 0;
  return new Transform({
    transform(chunk, _enc, cb) {
      seen += chunk.length;
      if (seen > maxBytes) {
        const err = new RangeError(`decompressed body exceeds ${maxBytes} bytes`);
        err.code = 'ERR_DECOMPRESSED_TOO_LARGE';
        return cb(err);
      }
      cb(null, chunk);
    },
  });
}

pipeline(
  source,                 // e.g. req, a file stream, an upstream response
  zlib.createGunzip(),
  byteLimit(1024 * 1024),
  destination,
  (err) => { /* err.code === 'ERR_DECOMPRESSED_TOO_LARGE' on a bomb */ },
);

Against the 100 MiB bomb, the pipeline failed with ERR_DECOMPRESSED_TOO_LARGE after exactly 1,048,576 bytes had reached the destination. pipeline() destroys every stream in the chain on error, so the decompressor stops as well.

Two details make this work. The limiter must sit after the decompressor, because counting compressed bytes is the mistake you’re avoiding. And use pipeline(), not chained .pipe() calls, which don’t propagate errors or destroy the upstream streams.

Express: the body parser already counts decompressed bytes

Express’s express.json(), express.urlencoded(), express.text() and express.raw() come from body-parser. Its inflate option defaults to true, and in body-parser 2.4.0 it decodes deflate, gzip, br and, where Node supports it, zstd.

We sent express.json() (default limit of '100kb') a 10 MB JSON body compressed each way:

All three compressed bodies were under 100 KB on the wire and still got 413, so the limit is applied to the decoded body. That’s the behaviour you want. Tested with Express 5.3.0, body-parser 2.4.0 and raw-body 3.0.2.

Two cautions. The body-parser README warns that limits “above the default, for example payloads of 5 MB or more” increase memory use and response times, so raise limit per route, not globally. And if you don’t expect compressed request bodies, inflate: false turns them away with 415 before any decoding.

Custom code is where the gaps are: a handler that does req.pipe(zlib.createGunzip()) for an upload endpoint, or a framework plugin with its own decoder. Give each one the byte limiter above.

fetch(): responses are decompressed with no cap

Node’s built-in fetch() decodes Content-Encoding: gzip for you. We served the 100 MiB gzip bomb from a local server:

• res.headers.get('content-length') returned 101941, the compressed size.
• await res.arrayBuffer() returned 104,857,600 bytes.

There’s no size option on arrayBuffer(), json() or text(). If you fetch URLs you don’t control (webhooks, link previews, feed readers, anything with a user-supplied URL), read the body with a cap:

// Read at most maxBytes of a fetch() response body (after fetch's own decompression).
async function readCapped(res, maxBytes) {
  const reader = res.body.getReader();
  const chunks = [];
  let total = 0;
  for (;;) {
    const { done, value } = await reader.read();
    if (done) break;
    total += value.byteLength;
    if (total > maxBytes) {
      await reader.cancel();
      throw new RangeError(`response exceeds ${maxBytes} bytes`);
    }
    chunks.push(value);
  }
  return Buffer.concat(chunks);
}

const res = await fetch(url, { signal: AbortSignal.timeout(10_000) });
const body = await readCapped(res, 1024 * 1024);

Against the bomb, readCapped(res, 1 MiB) threw “response exceeds 1048576 bytes”. Pair it with a timeout, because a slow trickle is a different attack that a byte cap doesn’t stop. Fetching arbitrary URLs has bigger risks than size, too; our SSRF guide covers the network side.

A checklist for Node services

Also consider:

• Keep the decoder patched. Size limits don’t help against bugs in the decompressor itself. CVE-2026-111497 was an out-of-bounds write in Brotli’s decoder, fixed in Node.js 22.23.4, 24.22.1 and 26.12.1; see our Brotli guide.
• Decide whether you need each codec. zstd arrived in Node.js 22.15.0 and is marked Experimental in the Node 22 docs, yet body-parser 2.4.0 accepts it automatically when the runtime supports it. If clients never send it, inflate: false or a proxy rule removes that path.
• Push the limit to the edge as well. A reverse proxy that decompresses request bodies should cap the decoded size too, so the application isn’t your only control.

Limits of this article

All results come from Node.js 22.23.4 on Linux with Express 5.3.0, body-parser 2.4.0 and raw-body 3.0.2, using 100 MiB of zeros as the bomb. Other Node release lines, frameworks (Fastify, Koa, NestJS adapters) and HTTP clients (axios, undici’s request) may behave differently. Test them the same way. We measured whether limits held, not peak memory use or CPU time.

Sources and verification

CVE-2026-111497 is a memory-corruption bug in Google’s Brotli decompressor. Upstream versions 1.0.3 through 1.2.0 are affected, and 1.0.10, 1.1.1 and 1.2.1 fix it. CISA added it to the Known Exploited Vulnerabilities catalog on October 27, 2026, with a federal remediation date of November 10. The hard part is not the patch. Brotli is compiled into Node.js, Python wheels, Go modules, proxies and service meshes, and several patched builds still report the old version number. Here is where it hides, what “fixed” looks like for each, and a tested way to check code you vendor yourself.

Are you affected?

You are exposed if a vulnerable Brotli decoder processes data an attacker can supply. The CVE record says an attacker with “a crafted Brotli-compressed stream” can “corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code”. Google’s CNA scored it CVSS 4.0 9.2 (Critical). The Node.js project rates its copy High.

The Envoy, Istio and Bun ranges come from Wiz’s write-up, not from those projects’ advisories. We did not read those advisories directly. For Envoy we checked the source instead: bazel/repository_locations.bzl pins Brotli 1.2.0 at tag v1.39.2, while v1.39.3 pins a Brotli commit whose decode.c contains the fix.

Linux distributions usually backport fixes and keep the upstream version. Our Ubuntu 24.04 sandbox, for example, has libbrotli1 1.1.0-2ubuntu0.1. That string alone does not tell you whether the fix is in. Use your distribution’s security tracker for the CVE.

Why the version string can mislead you

Node.js patched its bundled Brotli in place. On the fixed Node.js 22.23.4 the reported library version is still the old one:

$ node -v
v22.23.4
$ node -p process.versions.brotli
1.1.0

We ran that in our sandbox. The source tree agrees: deps/brotli/c/common/version.h declares 1.1.0 at both v22.23.3 and v22.23.4, and 1.2.0 at v24.22.1 and v26.12.1, but only the fixed tags contain the patched decoder (v22.23.3 and v24.22.0 do not). A scanner that flags process.versions.brotli < 1.2.1 will raise false positives on fixed Node.js. A scanner that trusts a vendored version.h can miss real exposure the other way round. For Node.js, use the Node.js version. For anything else you vendor, check the code.

What the bug is

The Node.js advisory gives the clearest description: “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 upstream diff between v1.2.0 and v1.2.1 of c/dec/decode.c shows exactly that. DecodeBlockTypeAndLength() used to return a plain boolean, so “invalid stream” and “need more input” looked the same, and the non-safe callers ignored the result altogether (static void DecodeLiteralBlockSwitch(...)). After the fix the function returns a BrotliDecoderErrorCode, emits BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH for the invalid case, and every caller checks it through a new BROTLI_SAFE_WITH_STATUS macro. That matches the two weaknesses in the CVE record: CWE-252 (unchecked return value) and CWE-787 (out-of-bounds write).

The flaw was found by Khai Tran and Sylvie Mayer of OpenAI Codex Security, who are credited in both the CVE record and the Node.js advisory.

Where untrusted Brotli reaches your code

The flaw is in decompression, so look for places that decode data you did not produce:

• Request bodies. Any endpoint or middleware that inflates Content-Encoding: br uploads.
• Outbound HTTP. HTTP clients decode Brotli responses for you. If an attacker controls or can redirect the URL (webhooks, link previews, feed fetchers, scrapers), they control the compressed bytes.
• Files and archives that contain Brotli streams.
• Proxies and meshes that decompress traffic to inspect or transform it.

Two behaviours we checked, because they mean code that never mentions Brotli can still run it:

• Node.js fetch() decodes Brotli it never asked for. On Node.js 22.23.4, fetch() sent accept-encoding: gzip, deflate. When our local test server replied with content-encoding: br, fetch() decompressed the body anyway. A hostile server can choose Brotli whatever the client advertises.
• Python’s requests turns Brotli on when it is installed. urllib3’s util/request.py appends br to its default Accept-Encoding when brotlicffi or brotli can be imported. With Brotli 1.2.1 installed, requests.utils.default_headers() returned gzip, deflate, br in our test. The decoding then runs in whichever Brotli package is installed.

What to do now

1. Update the runtimes. Node.js to 22.23.4, 24.22.1 or 26.12.1 or later. Move off end-of-life Node.js lines: the advisory notes that “End-of-Life versions are always affected when a security release occurs.”
2. Update language packages in every lockfile and image: Brotli>=1.2.1, brotlicffi>=1.2.1.0, github.com/andybalholm/brotli v1.2.7. Both Python fixes were published to PyPI on October 22, 2026.
3. Update proxies and meshes (Envoy, Istio) and Bun to the fixed releases above. Confirm the ranges against each project’s own advisory.
4. Apply distro updates for libbrotli/brotli, then restart the long-running processes that loaded the old library.
5. Rebuild container images. A fixed base image does not help a running container that was built from the old one.
6. Hunt for vendored copies with the check below.

If you cannot patch a service today, reduce what it decodes. As a stopgap, reject Content-Encoding: br request bodies at the edge for services that do not need them, and stop server-side fetchers from decoding responses from untrusted URLs. This is our editorial suggestion, not vendor guidance, and it does not replace the update.

Inventory commands

# Node.js: the version that matters
node -v

# Python: every environment and image
pip show Brotli brotlicffi 2>/dev/null | grep -E '^(Name|Version)'
pipdeptree -r -p Brotli          # who pulls it in

# Go modules
go list -m all | grep andybalholm/brotli

# Debian/Ubuntu and RHEL-family system libraries
dpkg -l 'libbrotli*' 2>/dev/null | awk '/^ii/{print $2, $3}'
rpm -q brotli libbrotli 2>/dev/null

The pip, node and dpkg lines were run in our sandbox. The go, pipdeptree and rpm lines are standard tool usage that we did not run here.

Checking vendored source for the fix

C and C++ projects often copy c/dec/decode.c into their tree, and Go programs carry decode.go in the module cache or a vendor/ directory. This script looks for the patched function signature instead of trusting any version string:

#!/bin/sh
# brotli-fixcheck.sh DIR...: find vendored Brotli decoder sources and report
# whether they carry the CVE-2026-111497 fix. Looks at the code, not the
# version string, because patched Node.js still reports the old version.
for root in "$@"; do
  find "$root" \( -name decode.c -path '*dec*' \) -o \( -name decode.go -path '*brotli*' \) 2>/dev/null |
  while read -r f; do
    if grep -q 'BrotliDecoderErrorCode DecodeBlockTypeAndLength' "$f" ||
       grep -q 'func decodeBlockTypeAndLength(.*) int {' "$f"; then
      echo "PATCHED    $f"
    elif grep -q 'DecodeBlockTypeAndLength\|decodeBlockTypeAndLength' "$f"; then
      echo "VULNERABLE $f"
    fi
  done
done

We tested it against 12 sources pulled from GitHub: upstream Brotli v1.0.9, v1.0.10, v1.1.0, v1.1.1, v1.2.0 and v1.2.1; Node.js deps/brotli at v22.23.3, v22.23.4, v24.22.0 and v24.22.1; and andybalholm/brotli v1.2.6 and v1.2.7. It reported every fixed release as PATCHED and every earlier one as VULNERABLE. Run it over source trees, vendor/ directories and $(go env GOMODCACHE).

It cannot inspect compiled binaries, and a heavily modified fork may not match either pattern. Treat “no output” as “no recognisable copy found”, not as “safe”.

What to hunt for

No vendor or agency has published indicators of compromise for this CVE, and CISA’s KEV entry does not require forensic triage (forensicTriage: No). Practical checks:

• Crashes. Segfaults or aborts in Node.js, Python or proxy processes since late October, especially in services that fetch remote content or accept compressed uploads.
• Unexpected Brotli. Requests with Content-Encoding: br to endpoints that never receive compressed bodies. Wiz recommends reviewing WAF, application and network logs for suspicious Brotli-compressed traffic.
• Outbound fetches from services that took user-supplied URLs, close in time to a crash.

Limits of this article

We did not reproduce the memory corruption or test any exploit. Our checks cover version strings, source code and HTTP client behaviour in a sandbox: Node.js 22.23.4, Python with Brotli 1.2.1, Ubuntu 24.04. The Envoy, Istio and Bun ranges come from a security vendor’s summary. The list of affected software is not complete. Wiz notes that other products that bundle or link vulnerable versions of the Brotli C decoder may also be affected.

For the wider process of keeping dependency updates moving, see dependency audits without slowing down releases. For publishing or reading “not affected” statements about a library like this, see VEX explained. Last week’s PHP2Shell patch-and-hunt guide covers the two PHP runtime flaws CISA added to KEV the day before.

Sources and verification