Snakemake's use of GitPython allows an attacker to execute arbitrary code by creating a submodule with a path that points to the .git/hooks directory. This causes an attacker-controlled executable hook to be planted and run on subsequent git operations. Versions from 5.5.3 up to but not including 9.27.1 are affected. Although versions 3.2.0 and later raise a ValueError after cloning, the malicious hook remains on disk and executable. This vulnerability enables remote code execution if an attacker can influence the submodule path parameter.
A vulnerability in setuptools on Windows allows an attacker to craft a wheel file with a specially crafted namespace_packages.txt that causes setuptools to create an __init__.py file outside the intended installation directory. This file has fixed content and is created with the permissions of the installing process. The issue arises because an absolute Windows path in namespace_packages.txt is not properly validated, leading to path escape during legacy wheel installation.
A vulnerability in setuptools on Windows allows attacker-controlled content in a wheel's .dist-info/namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. The created file has fixed content and is placed at a filesystem path influenced by the wheel, with the permissions of the installing process. This requires the target parent directory to already exist.
A vulnerability in setuptools on Windows allows an attacker to craft a wheel containing a .dist-info/namespace_packages.txt file with an absolute Windows path. During legacy wheel installation, this causes setuptools to create an __init__.py file outside the intended installation directory at a path influenced by the attacker. The created file has fixed content and is created with the permissions of the installing process. The vulnerability requires the target parent directory to already exist.
A buffer overflow vulnerability exists in the Brotli decoder component of Google Brotli versions 1.0.3 through 1.2.0. This flaw allows remote unauthenticated attackers to corrupt adjacent memory, potentially leading to sensitive data disclosure, denial of service, or arbitrary code execution. Users should update affected Brotli libraries or binaries to fixed versions 1.0.10, 1.1.1, or 1.2.1. Additionally, the vulnerability affects the locust product in versions >=2.2.1 <2.18.4 and >=2.23.1 <2.47.0_1, with fixes available in 2.18.4 and 2.47.0_1.
PyJWT versions up to 2.13.0 and current master at commit 7144e4534c34810f4525dc4578a32addd8212cff contain a vulnerability where the HMACAlgorithm.from_jwk method accepts an empty HMAC key from an oct JWK without rejection. This allows an attacker to forge tokens by exploiting the zero-length key acceptance during verification via PyJWK, PyJWKSet, or PyJWKClient. The issue arises because the empty-key rejection added in 2.13.0 for string/bytes keys was not applied to the JWK verification path. The vulnerability requires no authentication but depends on the verifier resolving an empty 'k' value from a JWK, which can occur due to misconfiguration or trusting a JWKS with such an entry. A fix is available in version 1.50.0 of the affected product kimi-cli.
FastMCP versions 3.0.0 through 3.4.9 and 4.0.0 through 4.1.1 contain an authorization bypass vulnerability where direct calls to transformed components skip the final authorization check. This allows low-privilege users to invoke protected tools, resources, templates, or prompts that should be denied. The issue arises because the server applies transforms before authorization but does not re-check the authorization on the transformed component in direct lookup paths. Fixes are available in FastMCP 3.4.10 and 4.1.2.
A regular expression used in OpenTelemetry Python's TraceState.from_header method causes quadratic CPU time complexity when parsing large tracestate headers containing long runs of spaces or tabs without commas. This can lead to significant processing delays and blocking of other connections in asynchronous servers. The issue affects versions from 1.0.0 through 1.49.x and is fixed in version 1.50.0.
A vulnerability in setuptools on Windows allows a crafted wheel's namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. The created file has fixed content and is placed at a filesystem path influenced by the wheel, with the permissions of the installing process. The parent directory must already exist for this to occur.
A vulnerability in setuptools on Windows allows a crafted wheel's namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. The attacker can control the destination path of this file but not its contents. This occurs because an absolute Windows path in namespace_packages.txt bypasses normal path restrictions during installation.
### Summary
On Windows, attacker-controlled content in a wheel's
`.dist-info/namespace_packages.txt` can cause setuptools' legacy wheel
installation path to create an `__init__.py` outside the requested
`destination_eggdir`.
The attacker can influence the destination path, but not the contents of
the created file.
### Details
Tested setuptools commit:
`6ead555c5fb29bc57fe6105b1bffc163f56fd558`
Relevant source:
`setuptools/wheel.py`
SHA-256:
`359b7e0d5dd8c3135653abe08a8ed5dc0352eadfd7df22cb5e2b5303b7c3cafd`
The relevant call path is:
`Wheel(wheel_path).install_as_egg(destination)`
→ `_install_as_egg`
→ `_convert_metadata`
→ `_fix_namespace_packages`
A wheel can provide attacker-controlled content in:
`<distribution>.dist-info/namespace_packages.txt`
The namespace value is eventually used approximately as:
```python
mod_dir = os.path.join(destination_eggdir, *mod.split('.'))
mod_init = os.path.join(mod_dir, '__init__.py')
If mod is a Windows drive-qualified absolute path containing no dots,
mod.split('.') preserves it as a single component.
On Windows, os.path.join(destination_eggdir, absolute_component) discards
the original base directory and resolves to the attacker-supplied absolute
path.
The existing wheel filename and ZIP traversal checks do not validate this
metadata value before it is subsequently interpreted as a filesystem path.
```markdown
### PoC
The reproduction was performed entirely inside a disposable temporary
directory.
Layout:
```text
sandbox/
destination/
outside/
input/
canary.txt
```
A synthetic wheel was created containing:
`demo_pkg-1.0.dist-info/namespace_packages.txt`
whose content was the absolute path of:
`sandbox\outside`
The real acquired setuptools implementation was then invoked:
```python
setuptools.wheel.Wheel(synthetic_wheel).install_as_egg(
sandbox_destination
)
```
The operation completed without exception.
Expected metadata was created under:
`sandbox\destination\EGG-INFO`
but setuptools also created:
`sandbox\outside\__init__.py`
The file did not exist before execution.
Its contents were:
```python
__import__('pkg_resources').declare_namespace(__name__)
```
The unrelated canary remained byte-identical.
The sandbox was deleted after recording the evidence.
```
### Impact
A crafted wheel can cause setuptools to create a fixed-content
`__init__.py` outside the intended installation directory at a
filesystem path influenced by the wheel, with the permissions of the
process performing the installation.
The demonstrated reproduction required the target parent directory to
already exist.
The Include directive in `src/mistune/directives/include.py` does not validate that the resolved file path stays within the source directory, allowing path traversal via `../` sequences to read arbitrary files.
Additionally, error messages and included file contents are rendered without HTML escaping, leading to XSS even when `escape=True`.
Affected functions:
- Path resolution (lines 27-31)
- `block_error()` in html.py (line 140)
- `render_html_include()` (line 72)
The Include plugin must be explicitly enabled via the plugins parameter.
CVE-2026-113719 is a vulnerability in virtualenv's app-data seeder that improperly deletes files outside the intended environment during seed package removal. It occurs when the seeder processes distribution metadata containing paths that traverse outside the environment root, allowing deletion of arbitrary user files if the environment is reused and the user has deletion rights. This flaw was introduced in version 20.8.1 and fixed in virtualenvwrapper version 6.1.1_4.
A vulnerability in virtualenv's xonsh activation script allows attacker-controlled prompt text to become executable code during environment activation if the xonsh source decoding uses legacy multibyte encodings like GBK or Big5. This occurs because UTF-8 encoded activation scripts containing non-ASCII characters are misinterpreted under these encodings, causing string literals to be improperly closed and arbitrary statements to execute. The issue affects POSIX activation scripts and requires an attacker to control the prompt or destination argument passed to virtualenv and a user to source the generated activation script. A fix is available in virtualenv version 6.1.1_4.
CVE-2026-113717 is a vulnerability in virtualenv's pip seeder when used with the --download option. The issue arises because virtualenv skips wheel digest verification for wheels obtained via index lookup during pip seeding, allowing an attacker-controlled index to serve a modified pip wheel without detection. This can lead to installation of tampered pip packages in the created environment. The vulnerability requires both --seeder pip and --download options to be enabled and a non-default index configured. A fix is available in virtualenv version 6.1.1_4.
CVE-2026-113714 is a low-severity vulnerability in virtualenv's wheel download and caching mechanism. The issue arises because downloaded wheel files are placed directly into a reusable cache before verification, and verification is based on pip's textual output rather than the actual downloaded file. This can allow a malicious package index to trick virtualenv into using a modified wheel by forging pip output lines, causing a mismatch between the cached file and the verified file. The vulnerability does not bypass TLS or affect the default PyPI setup and was fixed in virtualenv version 6.1.1_4.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with repeated malformed cross-reference streams.
### Patches
This has been fixed in [pypdf==6.21.2](https://github.com/py-pdf/pypdf/releases/tag/6.21.2).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4240](https://github.com/py-pdf/pypdf/pull/4240).
### Notes
This is a follow-up to https://github.com/py-pdf/pypdf/security/advisories/GHSA-55h5-xmcq-c37v, which had the side-effect of still loading the whole stream again despite the cache being present.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires opening a file with large/wrong upper limits in the xref table.
### Patches
This has been fixed in [pypdf==6.21.2](https://github.com/py-pdf/pypdf/releases/tag/6.21.2).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4239](https://github.com/py-pdf/pypdf/pull/4239).