CVE-2026-44552: Open WebUI: Redis Cache Keys tool_servers and terminal_servers Missing Instance Prefix Enable Cross-Instance Cache Poisoning

Redis Cache Keys toolservers and terminalservers Missing Instance Prefix Enable Cross-Instance Cache Poisoning

Affected Component

Tool server and terminal server Redis cache: - backend/openwebui/utils/tools.py (line 841, toolservers SET) - backend/openwebui/utils/tools.py (line 850, toolservers GET) - backend/openwebui/utils/tools.py (line 976, terminalservers SET) - backend/openwebui/utils/tools.py (line 986, terminalservers GET)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions since the tool server / terminal server Redis cache was introduced.

Description

Open WebUI uses a REDISKEYPREFIX (default open-webui) to namespace Redis keys, allowing multiple instances to safely share a single Redis backend. Every Redis key in the codebase uses this prefix — except the toolservers and terminalservers keys in utils/tools.py, which use bare key names.

When two or more Open WebUI instances share a Redis database (a supported and documented deployment pattern, e.g., for multi-region deployments, blue-green setups, or cluster topologies), the unprefixed keys collide. An admin on Instance A writing to toolservers overwrites the value read by Instance B — causing Instance B's users to receive Instance A's tool server configuration.

python utils/tools.py — unprefixed keys (problem) await request.app.state.redis.set('toolservers', ...) # line 841 json.loads(await request.app.state.redis.get('toolservers')) # line 850 await request.app.state.redis.set('terminalservers', ...) # line 976 json.loads(await request.app.state.redis.get('terminalservers')) # line 986

Every other Redis key in the codebase — prefixed (correct pattern) f'{REDISKEYPREFIX}:auth:token:{jti}:revoked' f'{REDISKEYPREFIX}:ratelimit:{email}:{bucket}' f'{REDISKEYPREFIX}:tasks:commands'

Attack Scenario

Two Open WebUI instances (A and B) share a Redis backend — a supported deployment for multi-region setups, blue-green deployments, or hot-standby. Both instances have their own admin accounts; the shared Redis was chosen for coordinated session handling, rate limiting, and task management.

1. Attacker is an admin on Instance A (a legitimately provisioned admin, or one that escalated via any available path including the LDAP empty-password or stale-admin-role findings). 2. Attacker on Instance A configures a tool server pointing to https://attacker-controlled.example.com/openapi.json. This triggers utils/tools.py:841 to write the new tool server list under the bare key toolservers. 3. Instance B's users query tools. Instance B reads from toolservers (line 850) — gets Instance A's poisoned list, which now includes the attacker's server alongside or instead of Instance B's legitimate tool servers. 4. Instance B's users invoke tools through the model's context. The attacker's server receives tool call payloads containing: chat content, user identity, OAuth tokens scoped to the tool server (if the user has bound their external account), and in-flight conversation context. 5. The attacker's server returns arbitrary tool responses, which are fed back into Instance B's LLM context as "trusted tool output" — enabling prompt injection, misinformation delivery, and further data exfiltration cascades.

The same cross-instance poisoning applies to terminalservers.

Impact

- Cross-instance cache poisoning: an admin on one instance affects all users of another instance sharing the Redis backend - Data exfiltration: tool call payloads contain chat content and user identity, delivered to the attacker's server - Prompt injection delivery: attacker-returned tool responses enter the victim instance's LLM context as trusted data - Undermines the multi-instance isolation guarantee that REDISKEYPREFIX was introduced to provide - Silent failure mode: no error is raised; the victim instance sees a valid, signed cache entry and has no way to detect it came from a different instance

Preconditions

- Multiple Open WebUI instances share a single Redis backend (a supported and documented deployment) - Attacker has admin access on one of the instances (or escalates to admin via any available path)