CVE-2026-92164 in Streamlink
Summary
by MITRE • 09/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/23/2026
Streamlink operates as a command-line utility designed to extract video streams from various online services and pipe them directly into compatible media players for playback. The software relies heavily on its internal HTTPSession class, which manages network requests using the Python requests library under the hood. In versions prior to 8.6.0, this session object was configured with a FileAdapter specifically intended to handle local file scheme URLs. However, the implementation failed to properly restrict cross-protocol redirects during request processing. Specifically, while the application attempted to validate direct file URL inputs for certain content types like HLS and DASH manifests, it did not enforce similar restrictions on HTTP or HTTPS requests that subsequently redirect to a different protocol scheme. This architectural oversight created a significant security gap where remote servers could manipulate the flow of data by issuing standard HTTP redirects pointing toward local filesystem paths rather than external network resources.
The technical flaw centers on how Streamlink handles URL redirections within its request lifecycle. When a user initiates playback for a stream hosted on an HTTP or HTTPS server, the application sends a request to that remote endpoint. If the remote server responds with a redirect status code pointing to a file:// URI, the underlying requests library follows this instruction by default unless explicitly configured otherwise. Because Streamlink had registered a FileAdapter for the file scheme but did not implement logic to reject redirects originating from non-file schemes into the file scheme, the application would proceed to read the contents of the specified local file on the victim's machine. This behavior effectively bypasses earlier security checks that were designed to prevent direct access to local files via HLS or DASH manifest URLs, as those checks only applied when the initial URL was already a file path, not when it arrived via an HTTP redirect chain.
The operational impact of this vulnerability is severe due to its potential for information disclosure and unauthorized data exfiltration. An attacker controlling a malicious streaming server can craft a response that redirects Streamlink to read sensitive local files such as configuration files, private keys, or user documents. Since the contents of these files are returned within the HTTP response object consumed by the application, they may be exposed through error messages, logging mechanisms, or potentially forwarded if the stream output is piped into another process without proper sanitization. This issue affects every request made through the vulnerable HTTPSession instance, meaning that any interaction with a compromised server could lead to local file access. The vulnerability persists across segment fetches as well, allowing an attacker to repeatedly probe for sensitive data during the playback of a stream.
To mitigate this risk, users must upgrade Streamlink to version 8.6.0 or later, where the developers have implemented strict validation to prevent cross-protocol redirects from file schemes back into local filesystem access. This fix ensures that HTTP and HTTPS sessions do not follow redirects leading to file:// URLs, thereby closing the attack vector entirely. From a broader security perspective, this incident highlights the importance of validating redirect targets against allowed protocols in any application handling network requests with potential side effects on the local system. The vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to unintended destinations, and specifically relates to SSRF via cross-protocol redirects. It also maps to MITRE ATT&CK technique T1560.002, Data Staged via Local File Access, as the attacker uses the application's own capabilities to stage local data for potential exfiltration or further exploitation within a controlled environment.