Any authenticated user can exhaust worker memory via a nested-repetition knowledge-search pattern

Impact

Availability, against every other user of the affected worker. Peak allocation grows with the fourth power of the repetition count while the pattern stays the same length, so the attacker chooses the cost by editing two digits, and the compiled result is then retained in the engine's pattern cache, which holds up to 500 entries before it evicts anything. Each distinct pattern is therefore a permanent bite out of the worker rather than a spike that unwinds: measured directly, one pattern at a repetition count of 40 retained about 740 MB, six distinct patterns at counts of 30 to 35 retained 1.38 GB together, and under a 2 GB memory limit the next compile failed with the process out of memory. A modest sequence of requests walks the process into memory exhaustion with no recovery short of a restart, and a deployment whose container memory limit sits below the peak loses the worker outright. While each compile runs, the work happens synchronously on the event loop, so the worker serves nobody else for its duration. There is no confidentiality or integrity effect, and no data is read or altered.

Fix

Fixed in 0.11.4 by https://github.com/open-webui/open-webui/commit/97e013a66169c4fcd7f26ab9e41a4ff260ffd4da. Search patterns are now compiled with RE2, which refuses oversized repetition and runs under a fixed 1 MiB memory limit for the compiled pattern, and search patterns are also capped in length. Ordinary search patterns are unaffected, though regex searches now follow RE2 syntax (no lookarounds or backreferences). Upgrading is sufficient; there is nothing an operator has to configure.

Root cause

• backend/open_webui/tools/knowledge_fs.py, build_matcher: compiled the caller's pattern with no limit on the result.
• backend/open_webui/tools/builtin.py, grep_knowledge_files: the default-configuration caller that passes an unvalidated pattern to it; grep_chat_files and the kb_exec grep command reach the same function.
• Affected setup: releases 0.11.0 through 0.11.3.

The earlier fix for catastrophic backtracking moved matching to an engine that supports a per-search timeout and placed every search under a shared time budget. That budget is acquired after the pattern has been compiled, so by construction it governs matching only. The replacement engine materialises counted repetition at compile time, which the previous one did not, so the migration introduced a new cost on a step that had never needed a limit before and that the budget was never positioned to cover. The pattern reached the compiler with no check beyond being non-empty. The count check added in 0.11.1 scanned the raw pattern text for repetition counts, so any spelling the engine reads as a count but the scan did not recognise went through unchecked.

Proof of concept

Against a running instance, as a user with the default user role and no workspace permissions:

1. Upload any small text file.
2. In a chat on a model with the knowledge tools available, have the model grep that file for ((((a{40}){40}){40}){40})|x.
3. The worker allocates several hundred megabytes inside the compile, and requests arriving from other connections during that window are delayed by the full duration. Repeating the request with different repetition counts adds to the total rather than reusing it.

Observed on the vulnerable code, with the tool call driven by a stub upstream so the model's choice to call the tool is deterministic. Everything from the tool call onward is unmodified Open WebUI code. Worker memory growth and the delay seen by a concurrent request on a second connection:

The pattern is 27 bytes at every row, so limiting the length of the input does not bound the cost. The engine used before 0.11.0 compiles all of these in under a millisecond with no measurable allocation, and 0.11.4 rejects them outright.

Credits

@baeseungwon1010, for identifying that compilation runs outside the matching budget.