A vulnerability in the Linux kernel's fsl-imx8mq-usb PHY driver caused a resource leak of the typec switch on probe error paths. This occurred because the cleanup code was only executed during driver removal, which does not run if the probe fails. The issue is fixed by using devm_add_action_or_reset() to ensure proper cleanup on both probe failure and driver removal.
The npm package '@test1230504/probe-7f3k2m-utils' contains malicious code that compromises any computer on which it is installed or running. The compromise is severe enough that all secrets and keys stored on the affected machine should be rotated immediately from a different, trusted device. Removal of the package alone may not eliminate all malicious software introduced by its installation.
The npm package bytepack-probe-a7x3 versions 1.0.0 and 1.0.1 declare a dependency on a package named leak-internal, which is fetched from an external HTTPS tarball URL rather than a standard registry. This tarball is retrieved without version pinning, integrity verification, or signature checks, allowing arbitrary code execution during npm install. The external URL and dependency name suggest the payload is designed to perform internal network probing, potentially leaking sensitive information.
The npm package '@baanx/blockchain-config' version 9.9.11 contains malicious code that executes automatically during installation and when required. It performs an obfuscated probe that collects system information including the username, hostname, and current working directory, then exfiltrates this data via DNS queries to an external domain unrelated to the legitimate publisher. This behavior indicates a compromise of any system where the package is installed, potentially exposing all stored secrets and keys.
The npm package @baanx/abis version 9.9.11 contains malicious code that performs DNS-based exfiltration of the installer's host identity. During installation and runtime, it collects the OS username, hostname, and current working directory name, combines these with a timestamp and a specific prefix, and sends this data via DNS queries to an attacker-controlled domain. This behavior is disguised under misleading telemetry and connectivity probe comments. The package compromises the host system, potentially exposing all stored secrets and keys.
The npm package @insiderintelligence/componentlibrary version 9.9.10 contains malicious code that executes automatically upon installation and import. It collects system information such as username, hostname, and current directory, then exfiltrates this data via DNS queries to an external domain. This behavior is disguised as a connectivity probe and is unrelated to the package's stated purpose. Installation of this package compromises the host system, potentially exposing all stored secrets and keys.
### 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 `<root>/.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 and the payload only writes a marker file.
Attacker repository — four ordinary tracked files at the root:
| path | mode | content |
|---|---|---|
| `gitdir` | 100644 | `.git\n` |
| `commondir` | 100644 | `.git\n` |
| `HEAD` | 100644 | `ref: refs/heads/master\n` |
| `hooks/pre-commit` | **100755** | `#!/bin/sh` + payload |
Victim — two ordinary calls:
```python
repo = git.Repo.clone_from(url, dst) # or git.Repo(dst)
repo.index.commit("automated commit") # code execution happens here
```
Observed on the PyPI release 3.1.59 (Linux and Windows):
```
real git says the git dir is : /tmp/.../victim/.git
GitPython says it is : /tmp/.../victim <- shadowed
attacker's hook executed : True
git fsck : (clean)
```
The `pre-commit` hook runs at `git/index/base.py:1201`, before `write_tree()`, so it fires even though
the commit later fails.
### Impact
A service that opens or clones an untrusted repository with GitPython — a CI runner building a fork
pull request, a code-scanning/SBOM service, a mirror, a dependency bot, an AI code-review/agent tool —
can be made to:
1. **Execute arbitrary commands** via the tracked `<root>/hooks/pre-commit` when the victim calls
`index.commit()`.
2. **Read files outside the repository**: the tracked `<root>/config` becomes the repository config and
is parsed with `merge_includes=True` (`git/repo/base.py:765`), so `[include] path = ~/.aws/credentials`
discloses the file. (`Repo._config_reader` still defaults `merge_includes=True`, so the hardening
added in 3.1.59 for `.gitmodules`/GHSA-7833 does not cover this path.)
3. **Write a config file to an attacker-chosen directory** via an absolute tracked `commondir`.
Delivery is silent: `git clone` exits 0, `git fsck` (including `--strict`, and with
`transfer.fsckObjects`/`fetch.fsckObjects=true`) reports nothing, and the clone passes every read-only
probe (`head.commit`, `branches`, `is_dirty()`, `untracked_files`, `iter_commits`) because a tracked
`commondir` of `.git` pins `common_dir` to the real `.git`.
### Threat model / preconditions
- Attacker controls the content of a repository the victim opens or clones with GitPython (public repo,
fork PR, mirrored dependency).
- For code execution, the victim performs a commit via GitPython's native `index.commit()`. For the
file-read impact, opening the repo and reading config is enough.
- `GIT_WORK_TREE` is **not** a mitigation — `git_dir` is assigned and the discovery loop breaks before
the environment is consulted.
- Real git is unaffected; only GitPython mis-resolves the directory.
### Remediation
1. Test `curpath/.git` **before** the `gitdir`/`commondir`/`HEAD` triple and before `is_git_dir(curpath)`.
2. Resolve `hook_path` / `_commit_hook_path` / `_get_validated_reflog_path` through `repo.common_dir`.
3. Containment-check `commondir`/`gitdir` contents before joining (reuse
`SymbolicReference._get_validated_path`).
4. Validate `HEAD` in `is_git_dir` (require `ref: refs/...` or a 40-hex sha).
5. Pass `merge_includes=False` in `Repo._config_reader` (`git/repo/base.py:765`).
### Note for the maintainers
Commit `406b98e1` (2026-05-31, "respect core.hooksPath for commit hooks") resolved the hook path via
`git rev-parse --git-path`, which is immune because git rediscovers the true `.git`. Commit `9bc287a2`
(2026-07-20) reverted it to avoid an unconditional `rev-parse` dependency — reintroducing the exec step.
Measured at each commit with the healthy-lo
Cotonti through 1.0.0 derives password recovery validation tokens from md5(microtime()) in users.passrecover.php, creating a predictable token space of approximately one million values per second. Unauthenticated attackers can read the server Date header, precompute candidate tokens within a narrow time window, and probe them against the passrecover authentication endpoint to reset any account password including administrators.
The npm package test890-auth version 1.0.0 contains malicious code that executes during installation. It collects sensitive environment information and the full contents of the consuming project's package.json file, then sends this data to a hardcoded external server. The package does not provide any legitimate functionality and is designed as a dependency-confusion probe. Systems with this package installed should be considered fully compromised.
The npm package 'test899-auth' version 1.0.1 contains malicious code that executes during installation. It collects detailed host and user identity information and exfiltrates it via DNS queries to a malicious domain, bypassing typical HTTP egress filtering. The package also has a self-referential dependency, indicating it may be a proof-of-concept or malicious probe rather than a legitimate authentication library. Installation of this package compromises the host, and removal may not fully restore system integrity.
Glean is a self-hosted RSS reader and personal knowledge management tool. Prior to 0.2.6, POST /api/feeds/discover passes an attacker-supplied feed_url to discover_feed(feed_url), creates a subscription through FeedService.create_subscription(), and enqueues fetch_feed_task. The background path calls fetch_feed(feed.url) and parse_feed(), which assigns each RSS item link to ParsedEntry.url. The task then passes ParsedEntry.url to fetch_and_extract_fulltext(parsed_entry.url) without network-level validation in backend/packages/rss/glean_rss/extractor.py and backend/apps/worker/glean_worker/tasks/feed_fetcher.py. A malicious feed can therefore make the server request private, loopback, link-local, or cloud-metadata resources. The fetched response is stored in Entry.content and can be retrieved through GET /api/entries/{id}, producing non-blind server-side request forgery with full response disclosure. This can bypass network perimeters, probe internal services and ports, expose internal configuration or web content, and potentially disclose cloud metadata access tokens. This issue is fixed in version 0.2.6.
A resource leak vulnerability in the Linux kernel's asus-wmi driver was fixed by correcting the error handling sequence during driver initialization. The issue caused resource cleanup steps to be skipped on certain initialization failures, leading to leaks of input device, sysfs groups, backlight, and rfkill resources.
A use-after-free vulnerability in the Linux kernel's HID subsystem was identified and resolved. The issue arises when a driver's probe enables input delivery via hid_device_io_start(), but later fails and calls hid_hw_stop() to unwind. This sequence can free a hidraw structure while HID reports are still processed on another CPU, leading to dereferencing freed memory. The problem affects multiple drivers that call hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(). The fix centralizes the stopping of input delivery inside hid_hw_stop() to prevent this class-wide API misuse.
A vulnerability in the Linux kernel's irqchip/renesas-irqc driver causes a resource leak and potential use-after-free leading to kernel crashes. The issue arises because generic interrupt chips allocated during probe are not freed on driver removal due to missing domain flags. This allows stale generic chips to remain accessible after removal, risking system instability. The flaw has been fixed by setting IRQ_DOMAIN_FLAG_DESTROY_GC to enable automatic cleanup of generic chips when the interrupt domain is removed.
A vulnerability in the Linux kernel's arm_scmi firmware component related to the P2A receiver mailbox setup has been resolved. The issue occurs when mailbox_chan_setup() requests an additional P2A receiver channel after successfully acquiring the primary channel; if the additional request fails, the primary channel remains allocated improperly. This can cause the primary mailbox channel to stay busy, potentially affecting probe deferral or other setup processes. The fix ensures the primary channel is properly released on failure.
A vulnerability in the Linux kernel's ARM SCMI firmware component was resolved. The issue involved improper cleanup of channels on setup failure in the scmi_channels_setup() function, which could leave transport channels, devices, and IDR state allocated after a failure. This was fixed by routing failures through an existing cleanup path to properly release resources before the probe error path frees the SCMI instance ID.
A vulnerability in the Linux kernel's RDMA/hfi1 driver causes a memory leak when device initialization fails late in the probe process. Specifically, the RX data allocated during hfi1_init_dd() is not freed if hfi1_init() or hfi1_register_ib_device() fails, leading to leaked netdev_rx and dummy netdev structures. This issue has been resolved by ensuring RX support is freed after IB unregistration and before postinit_cleanup().
A vulnerability in the Linux kernel's platform/surface ACPI notification code allows a NULL pointer dereference when a platform driver is force-bound to a device lacking an ACPI companion object. This occurs because the driver does not verify the presence of the ACPI companion before dereferencing it, leading to a potential denial of service. The issue was introduced when the probe function switched from ACPI_HANDLE() to ACPI_COMPANION() without proper NULL checks.