Affected: open-webui

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, backend/open_webui/routers/terminals.py built the ws_terminal upstream URL from an unencoded session_id and appended user_id as a query parameter, allowing query injection to make the terminal backend resolve another user identity; the HTTP proxy path also forwarded X-User-Id as an integrity-unbound identity claim. This issue is fixed in version 0.10.0.

Affected: PyPI: open-webui

## Summary

The terminal proxy in `backend/open_webui/routers/terminals.py` forwards the Open WebUI user's identity to the upstream terminal server / backend coordinator as an authorization claim, with no cryptographic binding to the session that produced it. The forwarded identity is attacker-influenceable on both proxy paths:

1. **HTTP path (`proxy_terminal`)** sets `headers['X-User-Id'] = user.id`. Upstreams that trust `X-User-Id` as identity receive it unsigned, so an attacker who can reach the upstream by other means (directly, a compromised peer, SSRF) can spoof it. 2. **WebSocket path (`ws_terminal`)** is exploitable through Open WebUI itself, with no "other means" required. It interpolates the path parameter `session_id` directly into the upstream URL and then appends `?user_id=<caller>`:

```python upstream_url = f'{ws_base}/p/{policy_id}/api/terminals/{session_id}' upstream_url += f'?{urllib.parse.urlencode({"user_id": user.id})}' ```

`session_id` is neither validated nor URL-encoded (the HTTP sibling runs `_sanitize_proxy_path`; this path runs nothing). An encoded `?`/`&` smuggled through `session_id` survives Open WebUI's single decode and is re-decoded by the upstream, injecting an attacker-chosen `user_id` ahead of the appended one. Query parsing binds the first occurrence, so the backend coordinator resolves the spoofed user's terminal scope.

## Technical Details

The forwarded terminal identity is a bearer-style authorization claim with no inte…