Most recent entries from all

BREW-yewtube-CVE-2024-38519 — yt-dlp File system modification and RCE through improper file-extension sanitization

Affected: Homebrew: yewtube

### Summary `yt-dlp` does not limit the extensions of downloaded files, which could lead to arbitrary filenames being created in the download folder (and path traversal on Windows). Since `yt-dlp` also reads config from the working directory (and on Windows executables will be executed from the yt-dlp directory) this could lead to arbitrary code being executed.

### Patches `yt-dlp` version 2024.07.01 fixes this issue by whitelisting the allowed extensions. This means some very uncommon extensions might not get downloaded; however, it will also limit the possible exploitation surface.

### Workarounds It is recommended to upgrade yt-dlp to version 2024.07.01 as soon as possible, **always** have `.%(ext)s` at the end of the output template, and make sure you trust the websites that you are downloading from. Also, make sure to never download to a directory within PATH or other sensitive locations like your user directory, `system32`, or other binaries locations.

For users not able to upgrade: - Make sure the extension of the media to download is a common video/audio/sub/... one - Try to avoid the generic extractor (`--ies default,-generic`) - Keep the default output template (`-o "%(title)s [%(id)s].%(ext)s`) - Omit any of the subtitle options (`--write-subs`, `--write-auto-subs`, `--all-subs`, `--write-srt`) - Use `--ignore-config --config-location ...` to not load config from common locations

### Details One potential exploitation might look like this:

From a mimetype we…

EUVD-2026-6053

fkie_cve-2024-38519

`yt-dlp` version 2024.07.01 fixes this issue by whitelisting the allowed extensions. `youtube-dl` fixes this issue in commit `d42a222` on the `master` branch and in nightly builds tagged 2024-07-03 or later. This might mean some very uncommon extensions might not get downloaded, however it will also limit the possible exploitation surface. In addition to upgrading, have `.%(ext)s` at the end of the output template and make sure the user trusts the websites that they are downloading from. Also, make sure to never download to a directory within PATH or other sensitive locations like one's user directory, `system32`, or other binaries locations. For users who are not able to upgrade, keep the default output template (`-o "%(title)s [%(id)s].%(ext)s`); make sure the extension of the media to download is a common video/audio/sub/... one; try to avoid the generic extractor; and/or use `--ignore-config --config-location ...` to not load config from common locations.

GHSA-79w7-vh3h-8g4j — yt-dlp File system modification and RCE through improper file-extension sanitization

Affected: PyPI: yt-dlp

### Details One potential exploitation might look like this:

From a mimetype we…

openSUSE-SU-2024:14094-1 — python310-yt-dlp-2024.07.01-1.1 on GA media

python310-yt-dlp-2024.07.01-1.1 on GA media

PYSEC-2026-2065 — yt-dlp File system modification and RCE through improper file-extension sanitization

Affected: PyPI: yt-dlp

### Details One potential exploitation might look like this:

From a mimetype we…

UBUNTU-CVE-2024-38519

Affected: Ubuntu:22.04:LTS: yt-dlp, Ubuntu:24.04:LTS: yt-dlp, Ubuntu:25.10: yt-dlp, Ubuntu:26.04:LTS: yt-dlp

`yt-dlp` and `youtube-dl` are command-line audio/video downloaders. Prior to the fixed versions, `yt-dlp` and `youtube-dl` do not limit the extensions of downloaded files, which could lead to arbitrary filenames being created in the download folder (and path traversal on Windows). Since `yt-dlp` and `youtube-dl` also read config from the working directory (and on Windows executables will be executed from the `yt-dlp` or `youtube-dl` directory), this could lead to arbitrary code being executed. `yt-dlp` version 2024.07.01 fixes this issue by whitelisting the allowed extensions. `youtube-dl` fixes this issue in commit `d42a222` on the `master` branch and in nightly builds tagged 2024-07-03 or later. This might mean some very uncommon extensions might not get downloaded, however it will also limit the possible exploitation surface. In addition to upgrading, have `.%(ext)s` at the end of the output template and make sure the user trusts the websites that they are downloading from. Also, make sure to never download to a directory within PATH or other sensitive locations like one's user directory, `system32`, or other binaries locations. For users who are not able to upgrade, keep the default output template (`-o "%(title)s [%(id)s].%(ext)s`); make sure the extension of the media to download is a common video/audio/sub/... one; try to avoid the generic extractor; and/or use `--ignore-config --config-location ...` to not load config from common locations.