Summary
This vulnerability only apply when running on a Windows OS.
An unsafe conversion of arguments allows the injection of a malicous commands when starting yt-dlp from a commands prompt.
[!CAUTION]
NOTE THAT DEPENDING ON THE CONTEXT AND WHERE THE LIBRARY IS USED, THIS MAY HAVE MORE SEVERE CONSEQUENCES. FOR EXAMPLE, A USER USING THE LIBRARY LOCALLY IS A LOT LESS VULNERABLE THAN AN ASP.NET APPLICATION ACCEPTING INPUTS FROM A NETWORK/INTERNET.
Details
The vulnerability have been implemented in a commit (https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50) 3 year ago to fix a issue with unicode characters on Windows. ( In the latest version at the time of writing this, the code seems to have moved here : https://github.com/Bluegrams/YoutubeDLSharp/blob/b2f7968a2ef06a9c7b2c212785cfeac0b187b6d8/YoutubeDLSharp/YoutubeDLProcess.cs#L87 )
In this commit, a new way of starting yt-dlp was implemented, method that was defined as the default behaviour.
When the internal method ConvertToArgs get called, the application will test multiples conditions to decide on how the yt-dlp application should be started. The condition we are interesed in, as well a the default one on Windows, is at line 99 . Inside the if statement, we can see that insead of directly calling the yt-dlp binary, a command prompt is opened to run yt-dlp.
The problem arises when you realize that both arguments in the ConvertToArgs method may be provided by an untrusted client. Since the documentation of YoutubeDLSharp does not warn developers about this behavior, they might assume that the library handles this safely by ensuring that the arguments are secure to run inside a command prompt. Instead, the two potentially malicious arguments are directly appended to the command string without any sanitization (see line 104 and 107).
PoC
For this example, I'm going to use the version 1.1.1 and a method inside YoutubeDL.cs. Assuming you are running on a Windows OS, this method will by default use a CMD to open yt-dlp.
using YoutubeDLSharp;
public async Task<RunResult<VideoData>> GetMediaInformation()
{
YoutubeDL youtubeDl = new YoutubeDL();
// Fetch media information using a badly crafted "url" (escaped)
return await youtubeDl.RunVideoDataFetch("https://example.com/\" & start calc.exe");
}
At the call of GetMediaInformation, the method RunVideoDataFetch will be called, internally this method will call the vulnerable method [ConvertToArgs] resulting in the following string:
/C chcp 65001 >nul 2>&1 && "yt-dlp.exe" --external-downloader "m3u8:native" --external-downloader-args "ffmpeg:-nostats -loglevel 0" -o "C:\Users\<hidden>\Documents\GitHub\<hidden>\<hidden>\bin\Release\net8.0\%(title)s [%(id)s]_%(epoch)s.%(ext)s" --force-overwrites --no-part -i --ignore-config --ffmpeg-location "ffmpeg.exe" --exec "echo outfile: {}" -- "https://example.com/" & start calc.exe"
[!NOTE]
Some text have been replaced by <hidden> inside the command.
The important part here is at the end of the command, we can see "https://example.com/" & start calc.exe", if we compare it with our
malicious URL https://example.com/" & start calc.exe, we can see that the method added quotes at the start and the end of the string. However, our additional quote in the URL followed by the & character made it so the CMD interprets what follows the & as a new command, thus executing yt-dlp AND the very dangerous start calc.exe 😊.
Here is a screenshot of the processes using another malicious url https://example.com/" & start msinfo32
Workaround
(only for v1.1.1 or lower, please upgrade to the latest version)
Using YoutubeDLProcess
If you are using a YoutubeDLProcess object directly to communicate with yt-dlp, you can disable UseWindowsEncodingWorkaround to mitigate the vulnerability. Doing so will execute the yt-dlp binary directly. However, you will lose support for Unicode characters.
Example:
YoutubeDLProcess youtubeDLProc = new YoutubeDLProcess()
{
UseWindowsEncodingWorkaround = false
};
Sanitizing url
If you want to keep support for Unicode characters or are using methods from the YoutubeDL.cs file, you would need to manually sanitize your inputs until a version with a fix is released. For URL sanitization, I managed to prevent the exploitation of the PoC by creating this method. However, I can't guarantee it would work in every case.
public static string? SanitizeUrl(string url)
{
// Parse the URL using Uri
if (Uri.TryCreate(url, UriKind.Absolute, out Uri? urlUri))
{
// According to the microsoft docs getting the absolute url append
// all of the others fields, theses fields get URI escaped when you GET them
// (https://learn.microsoft.com/en-us/dotnet/api/system.uri.query?view=net-8.0#remarks)
return urlUri.AbsoluteUri;
}
// Invalid url format
return null;
}
This works because Uri properties have special characters like spaces and " escaped into percent numbers like %20, thus turning our malicous url into https://example.com/%22%20&%20start%20calc.exe.
Note, however, that if you modify the options with which yt-dlp is run, you need to ensure every option is also sanitized (assuming they are taken from a untrusted user input). This method won't work as these options are not URLs.
Impact
Every users running a effected version on a Windows OS with the UseWindowsEncodingWorkaround value defined to true (default behaviour). If you are using build-in methods form the YoutubeDL.cs file, the value is true by default and you cannot disable it from theses methods.
Untrusted input is inserted into a command that is later executed by the application, allowing the attacker to alter the intent of that command. Typical impact: arbitrary command execution in the application's environment.
CVE-2025-43858 has a CVSS score of 9.2 (Critical). The vector is requires local access, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.1.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Upgrade to v.1.1.2 or higher of YoutubeDLSharp. The UseWindowsEncodingWorkaround property has been removed entirely in v.1.1.2.
Frequently Asked Questions
- What is CVE-2025-43858? CVE-2025-43858 is a critical-severity command injection vulnerability in YoutubeDLSharp (nuget), affecting versions >= 1.0.0-beta4, < 1.1.2. It is fixed in 1.1.2. Untrusted input is inserted into a command that is later executed by the application, allowing the attacker to alter the intent of that command.
- How severe is CVE-2025-43858? CVE-2025-43858 has a CVSS score of 9.2 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of YoutubeDLSharp are affected by CVE-2025-43858? YoutubeDLSharp (nuget) versions >= 1.0.0-beta4, < 1.1.2 is affected.
- Is there a fix for CVE-2025-43858? Yes. CVE-2025-43858 is fixed in 1.1.2. Upgrade to this version or later.
- Is CVE-2025-43858 exploitable, and should I be worried? Whether CVE-2025-43858 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2025-43858 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2025-43858? Upgrade
YoutubeDLSharpto 1.1.2 or later.