Bind io_stream sessions to creator to prevent terminal/fm hijack
Committed by naiba
fix(rpc): bind io_stream sessions to creator to prevent terminal/fm hijack
createTerminal and createFM correctly check server ownership before
issuing a stream UUID, but terminalStream and fmStream only verified
that the UUID existed. Any authenticated user holding a valid stream
UUID could attach to it, gaining the original creator's live shell or
file-manager session — and the UUID is exposed via URL path (referer
leaks, access logs, browser history, frontend error reporters).
Bind the creator user ID into ioStreamContext at CreateStream time,
expose StreamOwnership and IsStreamAuthorizedForUser, and check
ownership in terminalStream/fmStream before the WebSocket upgrade so a
rejected attempt does not tear down the legitimate stream via defer.
NAT streams are also routed through CreateStream(_, 0); they are not
reachable from /ws/terminal or /ws/file so a sentinel user ID is fine.
Co-authored-by: naiba/CloudCode <[email protected]>Editor assessment
This commit patches CVE-2026-62283. `fix(rpc): bind io_stream sessions to creator to prevent terminal/fm hijack` is close to ideal: the scope names the transport layer, the subject states the binding being added, and the purpose is explicit. The body explains the flaw: ownership was checked when issuing a UUID but not when attaching, so any authenticated user holding that UUID could reach another creator's shell or file-manager session. It lists the UUID's exposure vectors - referers, access logs, browser history - and explains the defense, including checking ownership before the WebSocket upgrade so a rejected attempt does not tear down the legitimate stream via defer. The NAT sentinel-user case and co-author trailer are handled cleanly.