A vulnerability in setuptools on Windows allows a crafted wheel's namespace_packages.txt to cause creation of an __init__.py file outside the intended installation directory. This occurs during legacy wheel installation when an absolute Windows path is supplied in the namespace_packages.txt file. The created file contains fixed content and is placed with the permissions of the installing process. The parent directory must already exist for this to succeed.
### 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.
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 file content is fixed and the path is attacker-influenced but requires the target directory to preexist. This can lead to unauthorized file creation with the installer's permissions.
A regular expression used in the OpenTelemetry Python API's TraceState.from_header method causes quadratic CPU time complexity when parsing specially crafted tracestate headers with long runs of spaces or tabs. This can lead to denial of service by blocking the handling worker for several seconds on a single unauthenticated request. The issue affects versions from 1.0.0 through at least v1.45.0 and is fixed in version 5.14.0_18.
Nbdime's GitPython integration has a vulnerability where submodule paths are validated too late, allowing cloning into the live .git/hooks directory. This enables planting an attacker-controlled executable hook that runs on subsequent git operations, leading to arbitrary code execution. Versions from 3.1.x through 3.2.0+ are affected, with 3.2.0+ raising a ValueError after the malicious hook is already written. The issue is fixed in version 4.0.4_11.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing content streams with many small operations.
### Patches
This has been fixed in [pypdf==6.21.0](https://github.com/py-pdf/pypdf/releases/tag/6.21.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4218](https://github.com/py-pdf/pypdf/pull/4218).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing arrays and/or dictionaries with lots of elements.
### Patches
This has been fixed in [pypdf==6.21.0](https://github.com/py-pdf/pypdf/releases/tag/6.21.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4218](https://github.com/py-pdf/pypdf/pull/4218).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage and/or long runtimes. This requires retrieving the form fields of a document.
### Patches
This has been fixed in [pypdf==6.21.0](https://github.com/py-pdf/pypdf/releases/tag/6.21.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4219](https://github.com/py-pdf/pypdf/pull/4219).
Parsedmarc versions from 8.11.0 up to but not including 9.9.0, and from 9.11.0 up to but not including 11.0.4, are affected by multiple cases where aiohttp can consume excessive or unbounded memory or CPU resources when processing attacker-controlled requests. This vulnerability allows an attacker to cause resource exhaustion, potentially impacting service availability.
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires accessing any stream with a large amount of filters or multiple filters which pass around large amounts of data.
### Patches
This has been fixed in [pypdf==6.20.0](https://github.com/py-pdf/pypdf/releases/tag/6.20.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4173](https://github.com/py-pdf/pypdf/pull/4173).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires an incomplete file which ends inside the xref table.
### Patches
This has been fixed in [pypdf==6.20.0](https://github.com/py-pdf/pypdf/releases/tag/6.20.0).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4170](https://github.com/py-pdf/pypdf/pull/4170).
### Notes
This has been reported through both the secure channel and as a public issue at [#4169](https://github.com/py-pdf/pypdf/issues/4169).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires removing an object from a tree, for example an outline item.
### Patches
This has been fixed in [pypdf==6.20.1](https://github.com/py-pdf/pypdf/releases/tag/6.20.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4188](https://github.com/py-pdf/pypdf/pull/4188).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires calling `find_outline_item` on a `PdfWriter`.
### Patches
This has been fixed in [pypdf==6.20.1](https://github.com/py-pdf/pypdf/releases/tag/6.20.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4188](https://github.com/py-pdf/pypdf/pull/4188).
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to arbitrary image parsers being called. This requires loading an image which claims to use the `/DCTDecode` filter (JPEG data).
Users which do not have the optional *Pillow* dependency installed in their environment are not affected.
### Patches
This has been fixed in [pypdf==6.21.1](https://github.com/py-pdf/pypdf/releases/tag/6.21.1).
### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#4222](https://github.com/py-pdf/pypdf/pull/4222).
### Summary
Browser CDP discovery could accept blocked WebSocket URLs. In affected versions, a lower-trust caller or configured input path could reach network destinations that should have been blocked by OpenClaw policy.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
### Impact
When the affected feature is enabled and reachable, this could reach network destinations that should have been blocked by OpenClaw policy. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
### Patched Versions
The first stable patched version is `2026.6.6`.
### Mitigations
Upgrade to a patched OpenClaw release when one is listed. Before upgrading, restrict the affected feature to trusted operators or disable it when it is not needed. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.