LLMOps、代理介面與安全
Open WebUI 0.11.2 Adds Per-Model-Request Filters and Fixes Cross-Instance Stop Handling and Streaming Bottlenecks
The new Open WebUI release allows extensions to modify the payload before every model call, including follow-up requests after tool execution. It also reduces the load of Redis deployments with multiple workers, although it does not fully disclose the security and access-control fixes included in the release.
Open WebUI 0.11.2 adds a new `request` stage to the filter lifecycle. Unlike the existing `inlet`, `stream`, and `outlet` stages, it receives the final payload before every model call; follow-up inference requests sent after an agent completes a tool call also pass through this stage again. Enterprise deployments can therefore inject tenant information, remove sensitive fields, or apply model-routing policies closer to the model gateway. However, custom filters also gain greater control over prompts and tool context, so extension code should be reviewed again during upgrades.
Distributed execution is another focus of the release. Previously, when multiple Open WebUI instances and a Redis cluster were in use, pressing Stop did not always terminate a request being processed by another instance. In 0.11.2, cancellation signals now work across instances. The WebSocket path also does less work to clean up stale sessions, repeatedly read its own state back from Redis, and check every output message for nonexistent attachments. Workers also no longer rewrite the shared cache when the model list has not changed.
For agent streaming, when an Anthropic-compatible client sends large tool arguments, the new release waits until the data may be complete before parsing it, avoiding expensive validation for every small chunk. It also fixes reasoning models freezing mid-response, thinking text leaking into the regular answer after tool use, and a rejected `ask_user` command terminating the entire response. These changes directly improve the usability of long-running tool calls and multi-step agents rather than merely updating the interface.
The maintainers also state that the release contains security and access-control fixes, while temporarily withholding some details, and recommend upgrading production environments as soon as possible. Because a complete vulnerability list is not yet available, administrators should first back up the database, validate SSO, tool servers, and custom filters in a test environment, and then monitor subsequent announcements. The PyPI package uses Trusted Publishing and provides Sigstore provenance, allowing deployment artifacts to be pinned with public hashes, but this is not a substitute for application-layer security validation.