CVE-2026-70493: Regular Expression Denial of Service (ReDoS) in Open WebUI Knowledge Search

Open WebUI is an extensible, user-friendly, self-hosted AI interface designed to operate alongside Large Language Model (LLM) managers like Ollama and OpenAI-compatible APIs. Among its core capabilities is a knowledge base system that permits users to upload documents and query their contents during chat interactions. The backend of this interface exposes file-search utilities via backend/open_webui/tools/knowledge_fs.py and backend/open_webui/tools/builtin.py to process, parse, and filter documents on behalf of users.

To increase query flexibility, the system allows the use of regular expressions to search the text inside uploaded files. This feature introduces a substantial attack surface when regular expression parsing and execution are delegated directly to untrusted inputs. The capability is accessible to any standard authenticated user who has privileges to interact with the chat interface and trigger document-searching operations.

Because the underlying engine is implemented synchronously within an asynchronous framework (ASGI), an evaluation that experiences execution delays will block the primary event loop thread. Under standard deployment configurations where only a single Uvicorn worker thread is assigned, a single user can exhaust the server's CPU capacity. This yields an immediate, complete denial of service across the entire application interface.

The root cause of CVE-2026-70493 is the synchronous execution of an unconstrained backtracking regular expression engine over user-supplied inputs within an asynchronous event loop. Python's standard re module relies on a backtracking Nondeterministic Finite Automaton (NFA) engine. When matching patterns containing nested quantifiers or overlapping groupings against problematic strings, the engine's execution path branches exponentially.

This behavior, often referred to as exponential backtracking, occurs when a pattern can match a target string in many different permutations. If the string contains a matching prefix but ends in a non-matching character, the engine must evaluate every single permutation of the match paths before failing. For example, applying the pattern (x|x)*y to a string consisting of 30 x characters forces the engine to run $2^{30}$ calculations. On a standard CPU thread, this process takes approximately 80 seconds, during which the thread is fully saturated.

The critical architectural flaw in Open WebUI is the context in which this match is executed. The application runs on Uvicorn, which implements an asynchronous, single-threaded cooperative multitasking event loop. The matching function is executing a blocking operation on this main loop. Because Python's standard backtracking engine does not yield control or support a timeout parameter, the event loop is blocked from executing other tasks. This blocks all incoming TCP connections and asynchronous handler evaluations.

In affected versions of Open WebUI, the backend compiles and executes searches via the build_matcher function in backend/open_webui/tools/knowledge_fs.py. The original implementation constructed a synchronous lambda function that called the standard re.compile and re.search methods without any time tracking.

Below is a comparison highlighting the vulnerable structure against the remediated implementation:

# === Vulnerable Implementation ===
def build_matcher(pattern: str, case_insensitive: bool = False, use_regex: bool = False):
    if use_regex:
        normalized = normalize_regex(pattern)
        try:
            re_flags = re.IGNORECASE if case_insensitive else 0
            # Compiles using standard library with no matching limits
            compiled = re.compile(normalized, re_flags)
        except re.error as e:
            return None, f'Invalid regex: {e}'
        # Synchronous execution within the event loop with no timeout
        return (lambda line: bool(compiled.search(line))), None

To resolve this issue, the maintainers integrated the third-party regex module, which supports inline matching timeouts. They also implemented a global dynamic budget using thread-safe context variables (contextvars):

# === Patched Implementation ===
import contextvars
import regex
import time
 
MATCH_BUDGET_SECONDS = 2.0
_active_budget: contextvars.ContextVar[MatchBudget | None] = contextvars.ContextVar('kb_match_budget', default=None)
 
def build_matcher(pattern: str, case_insensitive: bool = False, use_regex: bool = False):
    if use_regex:
        normalized = normalize_regex(pattern)
        try:
            # Swap 're' with 'regex' module which supports 'timeout'
            re_flags = regex.IGNORECASE if case_insensitive else 0
            compiled = regex.compile(normalized, re_flags)
        except regex.error as e:
            return None, f'Invalid regex: {e}'
 
        budget = _active_budget.get() or MatchBudget()
 
        def matches(line: str) -> bool:
            started = time.monotonic()
            try:
                # Avoid calling search if budget is already depleted
                if budget.remaining <= 0:
                    raise TimeoutError
                # Execute search with the remaining time budget
                return bool(compiled.search(line, timeout=budget.remaining))
            except TimeoutError:
                raise MatchBudgetExceeded(f'Search exceeded {MATCH_BUDGET_SECONDS:g}s') from None
            finally:
                # Deduct execution time from the current active budget
                budget.remaining -= time.monotonic() - started
 
        return matches, None

This change ensures that cumulative matching operations are capped to a strict 2.0-second limit per tool call. By tracking the runtime contextually, the application ensures that complex operations are aborted before causing system-wide degradation.

Exploiting this vulnerability does not require administrative or system-level privileges. An attacker must only have a valid authenticated session to interact with the chat interface. The execution path relies on targeting a custom file containing specific repeating structures and querying it using matching backtracking structures.

An attacker begins by uploading a document containing nested characters. For example, a file called exploit.txt is populated with 30 consecutive matching characters. The attacker then triggers a knowledge base search by providing a regular expression design containing overlapping wildcard sequences, such as (x|x)*y. This regular expression is evaluated against the target string.

The system evaluates the query using the sequential matching pipeline. During this evaluation, the regex engine enters an exponential state space, keeping the Uvicorn thread active. This blocks all incoming HTTP requests on the main loop. The server becomes completely unresponsive, dropping new connection attempts.

The overall impact of CVE-2026-70493 is rated as Medium under the CVSS v3.1 vector model, with a base score of 6.5. This score reflects low exploitation complexity, remote accessibility, and a requirement for basic authenticated credentials. However, the availability impact is high because of the server architecture.

In standard production configurations, Open WebUI is deployed within Docker containers or via script environments running Uvicorn with a single worker thread (UVICORN_WORKERS=1). Because python applications rely on a single execution thread unless specifically configured otherwise, blocking the event loop affects all global users of the service.

During an active exploit attempt, CPU resource usage for the primary worker thread spikes to 100%. While CPU core pinning is active, the application is unable to parse requests, establish new TCP handshakes, or process existing client connections. This allows any authenticated standard user to enforce a global denial of service.

While the mitigation introduced in version 0.11.0 successfully restricts individual regex search runtimes to 2.0 seconds, developers should be aware of remaining operational risks. Specifically, if multiple independent file search commands are executed outside the scoped kb_exec context, separate 2.0-second timers may initialize sequentially. An attacker could exploit this by uploading a large directory of files, causing multiple consecutive 1.9-second delays that accumulate into a longer CPU block.

Additionally, the current regex budget is assessed during the evaluation phase (regex.search). In highly complex patterns with deeply nested structures, the engine might still encounter high memory consumption or processing overhead during the initial compilation phase (regex.compile), which executes before the runtime budget is enforced.

To ensure complete isolation, administrators should run Open WebUI with multiple Uvicorn workers by configuring the UVICORN_WORKERS environment variable to a value greater than 1. This prevents a single blocked worker from completely taking down the application, ensuring other worker threads remain available to handle incoming concurrent traffic.