<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 01 Oct 2026 10:42:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-38519 — yt-dlp and youtube-dl vulnerable to file system modification and RCE through improper file-extension sanitization</title>
      <link>https://db.gcve.eu/vuln/cve-2024-38519</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; yt-dlp, ytdl-org youtube-dl, yt-dlp_project yt-dlp&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;`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&amp;#39;s user directory, `system32`, or other binaries locations. For users who are not able to upgrade, keep the default output template (`-o &amp;#34;%(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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; yt-dlp, ytdl-org youtube-dl, yt-dlp_project yt-dlp&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;`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&amp;#39;s user directory, `system32`, or other binaries locations. For users who are not able to upgrade, keep the default output template (`-o &amp;#34;%(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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2024-38519</guid>
    </item>
    <item>
      <title>GHSA-79w7-vh3h-8g4j — yt-dlp File system modification and RCE through improper file-extension sanitization</title>
      <link>https://db.gcve.eu/vuln/ghsa-79w7-vh3h-8g4j</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: yt-dlp&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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 &amp;#34;%(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&lt;/p&gt;
&lt;p&gt;### Details
One potential exploitation might look like this:&lt;/p&gt;
&lt;p&gt;From a mimetype we…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: yt-dlp&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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 &amp;#34;%(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&lt;/p&gt;
&lt;p&gt;### Details
One potential exploitation might look like this:&lt;/p&gt;
&lt;p&gt;From a mimetype we…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-79w7-vh3h-8g4j</guid>
    </item>
    <item>
      <title>PYSEC-2026-2065 — yt-dlp File system modification and RCE through improper file-extension sanitization</title>
      <link>https://db.gcve.eu/vuln/pysec-2026-2065</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: yt-dlp&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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 &amp;#34;%(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&lt;/p&gt;
&lt;p&gt;### Details
One potential exploitation might look like this:&lt;/p&gt;
&lt;p&gt;From a mimetype we…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: yt-dlp&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;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 &amp;#34;%(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&lt;/p&gt;
&lt;p&gt;### Details
One potential exploitation might look like this:&lt;/p&gt;
&lt;p&gt;From a mimetype we…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/pysec-2026-2065</guid>
    </item>
  </channel>
</rss>
