Open WebUI Redis Cache Key Collision Vulnerability in Tool and Terminal Servers Allowing Cross-Instance Cache Poisoning

A vulnerability exists in Open WebUI versions through 0.8.12, where the tool_servers and terminal_servers Redis cache keys lack a proper instance prefix. This omission can lead to key collisions when multiple Open WebUI instances share the same Redis database, a supported deployment pattern. As a result, an admin on one instance can inadvertently overwrite tool server configurations of another instance, causing data exfiltration and prompt injection risks.

Impact

Exploitation of this vulnerability allows for cross-instance cache poisoning, where an admin on one instance can disrupt the tool server configuration of another instance sharing the same Redis backend. This interference can lead to data exfiltration, as tool call payloads containing sensitive chat content and user identity are sent to the attacker's server. Additionally, it enables prompt injection, as responses from the attacker's server are integrated into the victim instance's LLM context as trusted information. This vulnerability undermines the intended isolation between instances that the Redis key prefix was designed to maintain, all without any indication of failure, as the victim instance receives a valid cache entry that appears legitimate.

Reproduction

To reproduce this vulnerability, set up two Open WebUI instances (A and B) that share a Redis backend. This can be done in a multi-region deployment, blue-green setup, or cluster topology. Once both instances are running, an admin on Instance A can configure a tool server. This action will write the tool server information under the unprefixed key 'tool_servers' in the shared Redis database. Meanwhile, Instance B will read from the same key, unknowingly receiving the poisoned tool server list from Instance A. This process can be repeated with the 'terminal_servers' key, causing similar cross-instance poisoning effects.

Remediation

Users can upgrade to Open WebUI version 0.9.0 or later, where this vulnerability has been fixed.