Most recent entries from osv_homebrew

BREW-snakeviz-GHSA-chx6-46f5-w4vp — tornado: CurlAsyncHTTPClient enforces no response-size limit — decompression bomb drives unbounded memory accumulation…

2026-10-01T11:45:24+00:00

Affected: Homebrew: snakeviz

An unbounded memory accumulation (decompression bomb) in `tornado.curl_httpclient.CurlAsyncHTTPClient` — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (`6.6.dev1`) and present unchanged in the latest release tag `v6.5.8` and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and `fetch()`es an attacker-chosen or attacker-compromised URL with default `decompress_response=True`, a malicious server replying `Content-Encoding: gzip` with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to **1,032,100 kB (~1008 MB) in 3.18 s** (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup `OOMKilled=true`) — with the transfer only 67% complete and **no client-side size check ever intervening**: `curl_httpclient.py` contains zero occurrences of `max_body_size`/`MAXFILESIZE`. The identical bomb against the default `SimpleAsyncHTTPClient` fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — `http1connection.py:620,676,742`) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed `_GzipMessageDelegate`/`SimpleAsyncHTTPClient` only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57);…

BREW-snakeviz-GHSA-c2m8-h5v5-343r — Tornado: StaticFileHandler follows symlinks outside static root (path traversal)

2026-10-01T11:45:24+00:00

Affected: Homebrew: snakeviz

### Summary StaticFileHandler allows an unauthenticated attacker to read arbitrary files from the server's filesystem by requesting a path that resolves to a symbolic link placed inside the static root directory. Any application that serves user-uploadable content, or whose static directory is populated by a build/deploy pipeline that creates symlinks (e.g. npm link, webpack, Docker volume mounts, CDN sync tools), is affected. An attacker who can trigger the creation of a symlink pointing outside the static root—or exploit one that already exists—can retrieve sensitive files such as /etc/passwd, private keys, configuration files, or application secrets.

### Details The vulnerability is in tornado.web.StaticFileHandler, specifically in the interaction between two methods in [tornado/web.py](vscode-webview://1grdaaa6v64itrol06qu70pq3d1b9h9im5c3npvvc9snaprc1q9f/tornado/web.py): - [get_absolute_path](https://github.com/tornadoweb/tornado/blob/0ca3c5f8279d402b245718d16522bc18a8f5d958/tornado/web.py#L2932) uses `os.path.abspath()` to resolve the requested path: - [validate_absolute_path](https://github.com/tornadoweb/tornado/blob/0ca3c5f8279d402b245718d16522bc18a8f5d958/tornado/web.py#L2935) uses the same `os.path.abspath()` on the root, then performs a string prefix check:

`os.path.abspath()` normalises . and .. segments but does not resolve symbolic links. As a result, a path like `/var/www/static/link` passes the `startswith("/var/www/static/")` check regardless of where `l…

BREW-snakeviz-GHSA-3hv7-mjh2-fv65 — Tornado: Unbounded query-string argument count allows event-loop-stalling DoS

2026-10-01T11:45:24+00:00

Affected: Homebrew: snakeviz

## Summary

`HTTPServerRequest.__init__` in `tornado/httputil.py` parses the URL query string via `parse_qs_bytes()` with no field-count limit — while the sibling POST-body parsing path (`parse_body_arguments`) received a `max_num_fields=1000` cap added earlier in this exact same release (v6.5.8, commit `8d6363ed`), explicitly to bound parsing cost for the identical underlying primitive. This leaves the query-string path with the resource-exhaustion exposure the body-path fix was meant to close.

**File**: `tornado/httputil.py`, line 553 (`HTTPServerRequest.__init__`)

### Root Cause

```python # tornado/httputil.py:553 (before fix) self.arguments = parse_qs_bytes(self.query, keep_blank_values=True) ```

Compare with the POST-body path fixed one commit earlier in the same release:

```python # tornado/httputil.py:1038-1041 uri_arguments = parse_qs_bytes( body, keep_blank_values=True, max_num_fields=config.urlencoded.max_arguments, # default 1000 ) ```

Both call sites funnel through the same `tornado.escape.parse_qs_bytes` (a thin wrapper over `urllib.parse.parse_qs`), which is exactly why `max_num_fields` was added to `urllib.parse.parse_qsl` upstream — to let frameworks bound field count. The fix was applied only to the body path; the query-string path was missed.

The request line + headers together are capped at `max_header_size` (default 65536 bytes), so this is not literally unbounded, but a single ~64KB request line can carry thousands of short `key=value…

BREW-snakemake-CVE-2026-87819 — GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer…

2026-10-01T11:43:20+00:00

Affected: Homebrew: snakemake

### Summary

GitPython's `Actor.name_email_regex` regular expression (`git/util.py`, line 863) is vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of Service). When GitPython parses the `author` or `committer` header of a git commit object that contains a long string with an unterminated `<` (no matching `>`), the Python regex engine enters quadratic backtracking, causing complete single-threaded CPU exhaustion proportional to the square of the input length.

A single crafted commit object can block any GitPython API call that reads `.author` or `.committer` for **over two minutes per invocation**, enabling denial of service against CI runners, code-hosting backends, repository-scanning pipelines, or any service that processes commits from third-party or untrusted repositories.

---

### Details

**Vulnerable file and line:**

`git/util.py`, line 863:

```python name_email_regex = re.compile(r"(.*) <(.*?)>") ```

This regex is evaluated inside `Actor._from_string()` (line 909) every time GitPython resolves a commit's `.author` or `.committer` property.

**Full call chain — from public API to vulnerable sink:**

commit.author # any ordinary GitPython API call └── git/objects/commit.py:917 Commit._deserialize() └── git/objects/util.py:341 parse_actor_and_date(author_line) └── git/util.py:909 Actor._from_string(string) └── Actor.name_email_regex.search(string) ← VULNERABLE

`author_line` is decoded directly from the raw bytes of the git commit ob…

BREW-snakemake-CVE-2026-87818 — GitPython: --no-index bypasses diff unsafe-option protections and enables a blind local-file content oracle

2026-10-01T11:43:20+00:00

Affected: Homebrew: snakemake

### Summary

GitPython 3.1.59 blocks a previously available local-file read path through unsafe git diff options such as -O/--orderfile.

However, the high-level diff API still permits --no-index with the default allow_unsafe_options=False.

--no-index changes the semantics of the paths arguments: instead of repository-relative pathspecs, Git interprets them as arbitrary filesystem paths.

When combined with the still-allowed -I/--ignore-matching-lines option, this creates a content-dependent Boolean oracle over a caller-selected local file.

This was reproduced against the published GitPython 3.1.59 wheel.

The original unsafe-option path is blocked in 3.1.59, while this alternate path remains reachable without setting allow_unsafe_options=True.

### Details

Confirmed API surface:

repo.index.diff( None, no_index=True, I=pattern, paths=[baseline_path, target_path], create_patch=True, )

The relevant behavior is:

1. --no-index makes the two values supplied via paths filesystem operands rather than repository pathspecs. 2. -I/--ignore-matching-lines makes Git's result depend on whether the supplied regular expression matches the relevant file content. 3. GitPython exposes the resulting bit through distinguishable behavior: - matching condition: normal return with an empty DiffIndex - non-matching condition: GitCommandError with exit status 1

An application that forwards attacker-influenced diff options and paths and exposes the success/error disti…

BREW-snakemake-CVE-2026-87817 — GitPython: Repository content can impersonate the git directory, leading to arbitrary code execution

2026-10-01T11:43:20+00:00

Affected: Homebrew: snakemake

### Summary

`Repo.__init__` decides which directory is the git directory by testing candidate paths in an order that considers the real `.git` **last**. Two earlier tests can be satisfied by ordinary tracked files. Git reserves only the literal name `.git`, so `HEAD`, `objects/`, `refs/`, `config`, `gitdir`, `commondir` and `hooks/` at a repository root are all legal tracked content.

Consequently, after a victim opens or clones an attacker's repository, GitPython resolves `git_dir` to the **working-tree root** while real git correctly resolves `/.git`. Everything GitPython then treats as "inside the git directory" is attacker-authored content — including `hooks/`, which it executes.

### CVE-2026-87817

### Affected code (3.1.59)

The discovery loop in `git/repo/base.py` tests, in order:

1. `git/repo/base.py:299` — `isfile(curpath/gitdir)` **and** `isfile(curpath/commondir)` **and** `isfile(curpath/HEAD)` 2. `git/repo/base.py:320` — `is_git_dir(curpath)` 3. `git/repo/base.py:341` — `dotgit = osp.join(curpath, ".git")` ← the real git dir, considered last

`is_git_dir` (`git/repo/fun.py:60`) requires only that `objects/` and `refs/` are directories and that `HEAD` is a file; **`HEAD`'s contents are never parsed.** The hook path is resolved from `index.repo.git_dir` (`git/index/fun.py:73`), i.e. the mis-resolved directory.

### Proof of concept

Requires only `pip install GitPython==3.1.59`. Full script attached as `poc1_rce.py`; it runs entirely in a temp directory an…

BREW-snakemake-CVE-2026-100689 — GitPython submodule update path traversal can write outside the repository

2026-10-01T11:43:20+00:00

Affected: Homebrew: snakemake

**Affected:** `GitPython` **3.1.61** (latest release) and `main` — `git/objects/submodule/base.py`. `git diff 3.1.61 origin/main -- git/objects/submodule/` is empty, so both are identical here.

---

## The gap

The fix for `GHSA-hmq2-w58f-27jc` added `Submodule._validated_name()` and wired it into `update()` and five siblings, closing the `.gitmodules` **name** → `.git/modules/` traversal. The other attacker-controlled `.gitmodules` field, **`path`**, is read raw:

```python # git/objects/submodule/base.py:172-177 def _set_cache_(self, attr): if attr in ("path", "_url", "_branch_path"): reader = self.config_reader() self.path = reader.get("path") # raw .gitmodules value ```

and GitPython's own containment guard is applied in only two of the places that consume it:

``` 400: def _to_relative_path(cls, parent_repo, path) # the guard (abspath + commonpath containment) 542: path = cls._to_relative_path(repo, path) # add() — guarded 1041: module_checkout_path = self._to_relative_path(self.repo, module_path) # move() — guarded ```

`update()` validates only the name and then uses the path-derived absolute location directly:

``` 788: self._validated_name(self.name) # NAME only 801: checkout_module_abspath = self.abspath # derived from self.path — unguarded 821: os.makedirs(checkout_module_abspath, exist_ok=True) ```

So `path = ../../../tmp/escaped` in an attacker-authored `.gitmodules` s…

BREW-mlx-lm-CVE-2026-80047 — Hugging Face Transformers downloads custom generation code before trust consent

2026-10-01T11:27:48+00:00

Affected: Homebrew: mlx-lm

A vulnerability in Hugging Face Transformers (versions 4.49.0, <= 5.8.1) allows remote Python files to be written to local disk without user consent when using GenerativePreTrainedModel.load_custom_generate(). The function fetches and caches a remote module file before performing the required trust_remote_code consent check, inverting the security model enforced by other code-loading paths (such as AutoConfig, AutoModel, and AutoTokenizer). As a result, attacker‑controlled Python code from custom_generate/generate.py is copied into the user’s ~/.cache/huggingface/modules directory even if the user declines the trust prompt. Although execution is correctly gated, the file write is not reversible and can persist across sessions. This can lead to persistent, unauthorized files on disk and stale cache collisions where cached attacker code may later be executed during trusted model loads. The issue stems from an unconditional file write in dynamic_module_utils.py prior to any trust verification.

BREW-legit-CVE-2026-87819 — GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer…

2026-10-01T11:22:53+00:00

Affected: Homebrew: legit

### Summary

---

### Details

**Vulnerable file and line:**

`git/util.py`, line 863:

```python name_email_regex = re.compile(r"(.*) <(.*?)>") ```

This regex is evaluated inside `Actor._from_string()` (line 909) every time GitPython resolves a commit's `.author` or `.committer` property.

**Full call chain — from public API to vulnerable sink:**

`author_line` is decoded directly from the raw bytes of the git commit ob…

BREW-legit-CVE-2026-87817 — GitPython: Repository content can impersonate the git directory, leading to arbitrary code execution

2026-10-01T11:21:36+00:00

Affected: Homebrew: legit

### Summary

### CVE-2026-87817

### Affected code (3.1.59)

The discovery loop in `git/repo/base.py` tests, in order:

### Proof of concept

Requires only `pip install GitPython==3.1.59`. Full script attached as `poc1_rce.py`; it runs entirely in a temp directory an…