mpv hand-off: isStreamUrl validates the parsed URL but the raw string is handed to mpv (tabs, newlines and spaces survive) #154

Severity: low

Where: native-host/faststream-mpv-host.mjs (isStreamUrl, withoutFsTags(message.url), mpvTargetUrl), chrome/background/MpvBackend.mjs (isStreamUrl, url: url in the message)

What happens

if (typeof url !== 'string' || !/^https?:\/\//i.test(url)) return false;
try { const {protocol} = new URL(url); return protocol === 'http:' || protocol === 'https:'; }

The WHATWG parser strips ASCII tab and newline before parsing, so 'https://cdn.test/v.m3u8\n--foo bar' passes (checked in Node: new URL(...).href === 'https://cdn.test/v.m3u8--foo%20bar'), yet the host builds mpv's target from message.url as received.

Failure scenario

Anything that reaches the host with a raw CR/LF or space in the URL hands mpv a request line ffmpeg's http client does not escape (GET /v.m3u8\n--foo bar HTTP/1.1): header injection toward the host the attacker names (LAN hosts included, with the relayed Referer/Origin/UA), and a plain space breaks a request the browser would have sent as %20. The extension's own paths currently normalise first (webRequest details.url; location.hash cannot carry a raw newline; parseHeadersParam re-serialises), so this is reachable only by something else talking to the host, which the host's own threat model says to assume.

Suggested fix

In both isStreamUrl callers use the parsed form (message.url = new URL(message.url).href; MpvBackend sends new URL(url).href), and additionally reject a raw string that is not printable ASCII (/^[!-~]+$/).

Confidence: high on the behaviour; medium on the exploit impact.

From a line-by-line code review of the tree at 41363fd (2026-10-02). Each claim above was checked against the source before filing; the reproduction steps and line references are as of that commit.

Generated by Claude Code