The 9x encoded path argument is 285 bytes long, so this is not a megabyte-sized or impractical URL. When sent through the real route, account for the ASGI server decoding the HTTP path once before filling the {path:path} parameter: an external request can use one additional encoding layer so _sanitize_proxy_path() receives the 9x encoded parameter shown above.
Root Cause / Technical Details
_sanitize_proxy_path() in backend/open_webui/routers/terminals.py performs this loop:
decoded = path
for _ in range(8):
once = unquote(decoded)
if once == decoded:
break
decoded = once
The subsequent traversal check is applied only to the value after those 8 iterations. If the input still contains encoded dot and slash bytes after the loop, posixpath.normpath() treats them as ordinary characters rather than path separators. The code then builds target_url = f'{base_url}/{safe_path}' and sends it with aiohttp.ClientSession.request(). The upstream server receives and decodes the forwarded path, turning the accepted %2E%2E%2F... into ../....
The same vulnerable sanitizer is present in v0.9.6, the latest release. I verified the v0.9.6 backend/open_webui/routers/terminals.py hash matches current main for this file.
Remediation
Do not rely on a fixed decode-depth cap for a traversal security boundary. Recommended fixes:
Decode until stable with a strict input length cap, and reject if the final value still contains encoded dot, slash, or backslash separators.
Reconstruct the allowed relative path from fully decoded segments: split on path separators, reject empty/current/parent segments, then join allowed segments with /.
Add regression tests for at least 9x and 10x encoded ../ payloads, including a route-level test that accounts for the ASGI server's initial path decode before the {path:path} parameter reaches _sanitize_proxy_path().