Any authenticated user can repeatedly stall a worker via file-search regex on the event loop

Upgrade to 0.11.4

Impact

Availability, against every other user of the affected worker. Each call held the event loop for the full 2 second budget, during which the worker handled no other request, and every further call from the same or another chat held it again. The same file searched with a literal pattern finished in a few milliseconds. There is no confidentiality or integrity effect, and no data is read or altered.

Fix

Fixed in 0.11.4. https://github.com/open-webui/open-webui/pull/29621 moved the built-in chat and knowledge file searches off the event loop into a worker thread, the knowledge filesystem search was moved off the event loop the same way, and pattern matching switched to the RE2 engine, which runs in linear time and cannot backtrack catastrophically. Upgrading is sufficient; there is nothing an operator has to configure.

Root cause

• backend/open_webui/tools/builtin.py, grep_knowledge_files and grep_chat_files: called the synchronous file search directly from the async tool.
• backend/open_webui/tools/knowledge_fs.py, build_matcher: compiled the caller's pattern with a backtracking engine under a 2 second timeout.
• Affected builds: 0.11.0 through 0.11.3. Earlier versions had no time limit at all and are covered by GHSA-2f54-p244-32q6.

The fix for GHSA-2f54-p244-32q6 bounded how long one search could run, but a time limit on a synchronous call does not give the event loop back while the call is running. The search still executed on the loop thread, so for the whole budget the worker could not serve anyone else, and the budget reset on every tool call.

Proof of concept

Against the tool code of 0.11.3 as an ordinary user:

1. Upload a text file whose content is a single line of 28 a characters followed by !.
2. In a chat, instruct the model to call grep_knowledge_files with the pattern (a|a)+$ and that file's id.
3. The tool returns Search exceeded 2s, narrow the pattern after about 2 seconds. A task scheduled every 50 ms on the same event loop does not run for 2.06 seconds while the search is in progress. Repeating the call repeats the stall.

Measured by running the real tool functions of each release with a concurrent 50 ms event-loop heartbeat (file lookup seeded directly with the file above):

Credits

@yousif-IQ, for the finding. @tahahassan773, analysis.