Summary
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.
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)
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
CVE-2026-44552 has a CVSS score of 8.7 (High). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.9.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-44552? CVE-2026-44552 is a high-severity security vulnerability in open-webui (pip), affecting versions <= 0.8.12. It is fixed in 0.9.0.
- How severe is CVE-2026-44552? CVE-2026-44552 has a CVSS score of 8.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of open-webui are affected by CVE-2026-44552? open-webui (pip) versions <= 0.8.12 is affected.
- Is there a fix for CVE-2026-44552? Yes. CVE-2026-44552 is fixed in 0.9.0. Upgrade to this version or later.
- Is CVE-2026-44552 exploitable, and should I be worried? Whether CVE-2026-44552 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-44552 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-44552? Upgrade
open-webuito 0.9.0 or later.