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,…
Published May 8, 2026 · Updated May 15, 2026
Affected packages
open-webui
- Ecosystem
- PyPI
- Affected
- <= 0.8.12
- Fixed in
- 0.9.0
- Check
pip show open-webui
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Redis Cache Keys tool_servers and terminal_servers Missing Instance Prefix Enable Cross-Instance Cache Poisoning
Affected Component
Tool server and terminal server Redis cache:
backend/open_webui/utils/tools.py(line 841, tool_servers SET)backend/open_webui/utils/tools.py(line 850, tool_servers GET)backend/open_webui/utils/tools.py(line 976, terminal_servers SET)backend/open_webui/utils/tools.py(line 986, terminal_servers 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 REDIS_KEY_PREFIX (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 tool_servers and terminal_servers 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 tool_servers overwrites the value read by Instance B — causing Instance B's users to receive Instance A's tool server configuration.
# utils/tools.py — unprefixed keys (problem)
await request.app.state.redis.set('tool_servers', ...) # line 841
json.loads(await request.app.state.redis.get('tool_servers')) # line 850
await request.app.state.redis.set('terminal_servers', ...) # line 976
json.loads(await request.app.state.redis.get('terminal_servers')) # line 986
# Every other Redis key in the codebase — prefixed (correct pattern)
f'{REDIS_KEY_PREFIX}:auth:token:{jti}:revoked'
f'{REDIS_KEY_PREFIX}:ratelimit:{email}:{bucket}'
f'{REDIS_KEY_PREFIX}: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.
- 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).
- Attacker on Instance A configures a tool server pointing to
https://attacker-controlled.example.com/openapi.json. This triggersutils/tools.py:841to write the new tool server list under the bare keytool_servers. - Instance B's users query tools. Instance B reads from
tool_servers(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. - 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.
- 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 terminal_servers.
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
REDIS_KEY_PREFIXwas 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)
Credited to Classic298.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Open WebUI vulnerabilities
All Open WebUI entriesCVE-2026-87011
Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout
high7.5Sep 10, 2026CVE-2026-87012
Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
medium4.3Sep 10, 2026CVE-2026-87013
Open WebUI: Any authenticated user can start a non-terminating request via a folder parent cycle
medium4.3Sep 10, 2026CVE-2026-87014
Open WebUI: Admin demoted through SSO role sync keeps read and write access to all users' notes
medium6.5Sep 10, 2026CVE-2026-87015
Open WebUI: A user's session cookies are sent to tool servers configured for bearer authentication
medium6.8Sep 10, 2026CVE-2026-87016
Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite
high8.1Sep 10, 2026
