CVE-2026-50019

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

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.

yt-dlp is a command-line audio/video downloader. From 2023.09.24 until 2026.06.09, if curl is used as 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. 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. This vulnerability is fixed in 2026.06.09.

CVE-2026-50019 If curl is used as 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. CVE-2026-50023 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. CVE-2026-50574 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. For mageia 9 we import yt-dlp-ejs to ensure the application still works.

These are all security issues fixed in the python313-yt-dlp-2026.06.09-1.1 package on the GA media of openSUSE Tumbleweed.

This update for yt-dlp fixes the following issues:

Changes in yt-dlp:

• Update to version 2026.06.09
  • Fixed [CVE-2026-50019]: File Downloader cookie leak with curl
  • Fixed [CVE-2026-50023]: Dangerous file type creation via insufficient filename sanitization
  • Fixed [CVE-2026-50574]: Arbitrary code execution via manifest downloads with aria2c
  • Added lockfile and pinned extras
  • Removed url, desktop and webloc from safe extensions
  • Extract supplemental codecs from DASH manifests
  • abematv: Extract subtitles
  • ard: Support new ardsounds domain
  • monstercat: Support older URLs
  • pornhub: Support browser impersonation
  • reddit: Fix unauthenticated extraction
  • rtp: Support multi-part episodes and --no-playlist
  • s4c: Extract more metadata
  • soop: Adapt extractors to new domain
  • soundcloud: Support --extractor-retries for original formats
  • twitch: Remove dead rechat subtitles
  • twitter: Fix view_count extraction
  • external: aria2c: Remove support for m3u8/dash protocols
  • ffmpegmetadata: Avoid erroneous ISO 639 conversions