Threats tagged 'homebrew'

A vulnerability in `nltk.downloader` in nltk/nltk versions <= 3.9.4 allows for cross-package resource and model poisoning. The downloader extracts package archives into shared namespaces such as `corpora/` and `taggers/` instead of package-isolated roots, and validates package integrity only after the archive has been written and extracted. This design flaw enables one package to overwrite another package's trusted resources within the same namespace, making the changes immediately active through ordinary NLTK APIs. This issue persists across fresh interpreter restarts and can affect downstream workflows, including machine learning pipelines and reproducibility-sensitive environments.

HTTPX2 versions from 1.4.0 up to but not including 1.5.1_1 can automatically add a Content-Length header to requests that already include a Transfer-Encoding header. This results in HTTP/1.1 requests containing both headers, violating HTTP framing rules and potentially enabling request smuggling or connection desynchronization attacks when intermediaries interpret these headers differently. The issue is fixed in HTTPX2 version 1.5.1_1.

HTTPX2 versions from 1.4.0 up to but not including 1.5.1_1 improperly serialize per-file Content-Type and custom headers in multipart/form-data requests without validating for CR or LF characters. This allows an attacker controlling upload metadata to inject additional multipart part headers by terminating headers early. The impact depends on how the receiving server processes multipart parts, potentially altering part semantics or bypassing header-based checks. The issue does not affect the outer HTTP request structure. A fix is available in HTTPX2 version 1.5.1_1 and later.

HTTPX2 versions before 2.10.0 have a Server-Sent Events (SSE) parser vulnerability where processing a long SSE line split across many small chunks causes CPU usage to grow quadratically. This can lead to denial of service by exhausting client CPU resources when consuming SSE from attacker-controlled or compromised endpoints. The issue affects both synchronous and asynchronous SSE client APIs. Upgrading to HTTPX2 2.10.0 or later mitigates the issue by improving parsing efficiency and limiting buffered event size.

HTTPX2 versions prior to 1.5.1_1 decompress streaming response bodies fully per network read, causing large intermediate memory allocations. This decompression amplification can lead to high memory usage or out-of-memory termination when processing malicious compressed responses from untrusted servers. The issue affects compressed responses using gzip, deflate, Brotli, or Zstandard encodings. The vulnerability is fixed in HTTPX2 version 1.5.1_1 by implementing incremental decompression with bounded buffers.

HTTPX2 versions 2.6.0 through 2.9.1 and underlying httpcore2 releases before 2.10.0 do not initiate TLS for secure WebSocket (wss://) connections routed through SOCKS5 proxies. This results in the WebSocket handshake and subsequent frames being sent in plaintext through the proxy, exposing sensitive data such as authorization headers, cookies, and application messages. An attacker controlling or observing the SOCKS proxy path can intercept or modify this traffic, impersonate the WebSocket server, and inject malicious messages. The issue is fixed in HTTPX2 and httpcore2 version 2.10.0 and later.

GitPython versions up to 3.1.58 contain a vulnerability in TagReference.create() where a positional argument 'reference' can bypass the unsafe option guard for '--file', allowing an attacker to read arbitrary local files. This occurs because the guard only inspects keyword arguments, not positional ones, enabling injection of '--file=<path>' as a positional argument. The file contents are returned in the annotated tag message. The issue is fixed in version 9.25.2.

GitPython versions before 3.1.60 contain a regular expression denial of service (ReDoS) vulnerability in the Actor.name_email_regex component that processes commit author and committer fields. An attacker can craft a commit object with a malformed author field containing an unterminated angle bracket, causing the regex to perform quadratic backtracking. This results in excessive CPU consumption, potentially exhausting resources for over two minutes per commit access.

GitPython version 3.1.59 contains a vulnerability in its high-level diff API where the --no-index option is not properly restricted. This flaw allows attackers with limited privileges to read arbitrary filesystem paths by using the --no-index option combined with the -I/--ignore-matching-lines flag. This can be exploited as a content-dependent Boolean oracle to extract single-line secrets from local files based on success or error responses.

GitPython versions before 3.1.60 contain a code injection vulnerability due to improper validation of the git directory location. This flaw allows attackers to impersonate the git directory by manipulating tracked files such as gitdir, commondir, and HEAD. Exploitation can lead to arbitrary code execution when a victim calls index.commit() on a cloned or opened repository with a malicious pre-commit hook.

A high severity vulnerability (CVE-2026-69248) exists in the python3.14-cryptography package for Red Hat Enterprise Linux 9. The issue allows the verifier to accept wildcard DNS names that can escape from permittedSubtrees. Red Hat has released patches to address this vulnerability in updated packages.

A critical vulnerability (CVE-2026-78676) in GitPython's GitConfigParser allows dormant multi-line git-config values to be corrupted into live injected directives upon any unrelated config write. This occurs because the parser's re-serialization logic mishandles multi-line values, causing injected directives like core.hooksPath to be interpreted by Git, enabling remote code execution (RCE). The issue affects GitPython version 3.1.58 at HEAD and specific kimi-cli versions. A patch is available.

A high-severity vulnerability in GitPython (CVE-2026-78675) allows arbitrary local file content disclosure via the [include] directive in an untrusted .gitmodules file. The SubmoduleConfigParser does not disable merge_includes, enabling an attacker to craft a malicious .gitmodules file that causes the parser to include and read arbitrary files on the victim's system. When the parser encounters a non-gitconfig file, it raises an exception that leaks the first line of the included file in the error message. This disclosure occurs during common read-only operations such as enumerating submodules, without requiring repository updates or checkouts. A fix is available for this vulnerability.

- **CWE:** CWE-73 (External Control of File Name or Path) / CWE-22 (Path Traversal, in the "escapes intended base directory" sense) - **Affected component:** `git/repo/base.py`, `Repo.unsafe_git_clone_options` (class attribute, lines 153-165) and `Repo._clone()` (lines 1477-1520), reached via the public `Repo.clone_from()` (line 1626) and `Repo.clone()` (line 1567) APIs. - **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`) ## Reachability `Repo.clone_from(url, to_path, **kwargs)` (and `Repo.clone()`) forward arbitrary keyword arguments to the underlying `git clone` invocation. Before forwarding, GitPython builds a candidate option list from the kwargs (`Git._option_candidates`) and checks it against a denylist, `Repo.unsafe_git_clone_options`, via `Git.check_unsafe_options()` — *unless* the caller passes `allow_unsafe_options=True`. This denylist mechanism is exactly the guard that the last ~16 published GHSAs against this repo (2026-07-12 → 2026-08-05) have repeatedly found incomplete or bypassable for other options (`--template`, `--upload-pack`, `--config`, `--exec`, `--output`, `--index-output`, `--pathspec-from-file`, etc.). `git clone` also accepts `--separate-git-dir=<path>`, which redirects the repository's entire `.git` metadata directory to an **arbitrary, caller-controlled filesystem path**, leaving only a gitlink text file (`gitdir: <path>`) at the intended destination. This is the exact same primitive already recognized as unsafe by GitPython's own code: `Repo.unsafe_git_init_options` (line 145-150) blocks `--separate-git-dir` for `Repo.init()`, with the comment *"Redirects the repository metadata to a caller-controlled path"*. The `Repo._clone()`/`clone()`/`clone_from()` docstring (line 1450-1452) is even more explicit: ``` :param allow_unsafe_options: Allow unsafe options to be used, such as ``--template`` and ``--separate-git-dir``. ``` i.e. the maintainers' own documentation states that `allow_unsafe_options=False` (the default) is supposed to block `--separate-git-dir` for clone. But **`Repo.unsafe_git_clone_options` does not contain it**: ```python unsafe_git_clone_options = [ "--upload-pack", "-u", "--config", "-c", "--template", "--bundle-uri", ] ``` So any application that forwards a `separate_git_dir` (or `separate-git-dir`) kwarg into `Repo.clone_from()` / `Repo.clone()` — e.g. a CI/build service, a Git-hosting proxy, or any tool that exposes a subset of clone options to a client, the exact threat model already accepted for the sibling `--template`/`--upload-pack`/`--config` entries in this same list — gets **no protection at all** for `--separate-git-dir`, even with the default `allow_unsafe_options=False`. ## Root cause Parity gap between two sibling denylists that guard the same underlying primitive (arbitrary redirection of git metadata storage): `unsafe_git_init_options` correctly lists `--separate-git-dir`; `unsafe_git_clone_options`, covering the same option on a different git subcommand that also accepts it, does not — despite the function's own docstring claiming otherwise. This is the same "denylist omits an equally-dangerous sibling option" pattern already responsible for `GHSA-539m-9xh6-q6rr` (`archive` denylist missing `--add-file`/`--add-virtual-file`) and `GHSA-6p8h-3wgx-97gf` (`clone` denylist missing `--template`, since fixed). ## Exploit path 1. Attacker-controlled input reaches a `separate_git_dir=...` (or equivalently `"separate-git-dir"`) keyword argument passed into `Repo.clone_from()` / `Repo.clone()` by the host application, with `allow_unsafe_options` left at its default `False`. 2. `Git._option_candidates()` renders this as `--separate-git-dir` and `Git.check_unsafe_options()` checks it against `Repo.unsafe_git_clone_options` — no match, no `UnsafeOptionError` raised. 3. `Git.transform_kwargs()` renders the same kwarg into the real command line as `--separate-git-dir=<attacker path>` and GitPython executes `git clone -v --separate-git-dir=<attacker path> -- <url> <dest>` via `subprocess` (no shell). 4. `git` itself creates the full repository metadata tree (`config`, `description`, `HEAD`, `hooks/`, `index`, `objects/`, `refs/`, `packed-refs`, `logs/`) at the attacker-specified path — which can be **any path outside the intended clone destination** that the process has permission to create — and leaves a gitlink file at the intended destination pointing to it. ## Impact Arbitrary directory/file creation at a path fully controlled by the attacker (bounded only by filesystem permissions of the process running GitPython), matching the impact class of the already-published, High-severity `GHSA-hmq2-w58f-27jc` ("Arbitrary Git Repository Creation Outside the Working Tree", CVSS 8.2). Concretely: - Planting a git repository structure (including a `hooks/` directory) at an attacker-chosen location outside the sandboxed clone destination the calling application in

GitPython's Repo.blame() and Repo.blame_incremental() methods have an incomplete denylist for unsafe git revision options, omitting the --contents and -S options. This omission allows an attacker to cause arbitrary local file reads by passing these options, which echo file contents into the blame result. The vulnerability affects GitPython versions up to 3.1.58. A patch is available to address this issue by expanding the denylist to include these options.