A path traversal vulnerability in the PackageIndex.download function of setuptools allows an attacker to write files to arbitrary locations on the filesystem. This occurs because the filename derived from a URL is insufficiently sanitized before being joined with a temporary directory path. The vulnerability was fixed in setuptools version 1.39.0. Exploitation could lead to arbitrary file write with the permissions of the running process, potentially escalating to remote code execution depending on context.
A platform-dependent path pattern matching issue exists in python-tuf's delegation implementation used by ggshield. On Windows, path matching is case-insensitive due to the use of fnmatch.fnmatch, which applies os.path.normcase that lowercases input on Windows but not on POSIX systems. This causes authorization decisions to differ by OS, violating the TUF specification. An attacker controlling a delegation role with a path pattern differing only by case can exploit this on Windows clients to override legitimate delegations. The vulnerability affects ggshield versions >=1.50.3 and <1.51.0_1 and has a medium severity rating with a CVSS score of 4. A fix is available by replacing fnmatch.fnmatch with fnmatch.fnmatchcase to ensure consistent case-sensitive matching across platforms.
urllib3, when used in a Pyodide runtime environment such as browsers or Node.js, does not enforce its redirect control parameters (`retries` and `redirect`). This is because the runtime itself controls redirect behavior, ignoring urllib3's settings. This can lead to applications relying on urllib3 for redirect control remaining vulnerable to SSRF or open redirect attacks if they depend on disabling redirects. A patched version of urllib3 is available for Node.js usage, but browsers inherently lack mechanisms to control redirects via XMLHttpRequest or the Fetch API, resulting in default redirect behavior.
PyJWKClient in the kimi-cli library allows fetching JSON Web Key Sets (JWKS) from URLs with schemes beyond HTTP and HTTPS, including file://, ftp://, and data:. This can lead to server-side request forgery (SSRF) on local files and other protocols. An attacker who can influence the jku URL and write to a local file path can forge JWT tokens that the application accepts as valid. The vulnerability affects PyJWT versions 2.11.0 and 2.12.1 and likely earlier versions. A fix is available that restricts allowed URL schemes to HTTP and HTTPS.
The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.
Security Fix(es):
* python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens (CVE-2026-48526)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
This update for python-urllib3 fixes the following issue
- CVE-2026-44431: sensitive information disclosure due to sensitive headers being forwarded across origins in proxied
low-level redirects (bsc#1265267).
### Impact
urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.
urllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.
However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:
1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library.
2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here).
These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.
### Affected usages
Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:
1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library.
2. `HTTPResponse.drain_conn()` is called after response decompression has already started.
### Remediation
Upgrade to at least urllib3 version 2.7.0 in which the library:
1. Is more efficient for reads with Brotli.
2. Always skips decompression for `HTTPResponse.drain_conn()`.
If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:
1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.
2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important.
### Credits
The Brotli-specific issue was reported by @kimkou2024.
`HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.
Red Hat Lightspeed in Satellite analyzes system health and configuration by applying predefined rules to a small set of local data, such as installed packages, running services, and configuration settings. When you install Red Hat Lightspeed in Satellite locally, you can generate Red Hat Lightspeed recommendations without sending system data to Red Hat services.
PyJWT versions prior to certain fixed releases do not validate the 'crit' (Critical) header parameter in JSON Web Signature (JWS) tokens as required by RFC 7515 §4.1.11. This allows tokens containing unknown critical extensions to be accepted instead of rejected, violating the RFC and potentially enabling security policy bypasses. The vulnerability is similar to CVE-2025-59420 affecting Authlib and has a CVSS score of 7.5 (High).
This update for python-marshmallow fixes the following issues:
- CVE-2025-68480: Fixed possible DoS when using Schema.load(data, many=True) (bsc#1255473).
Python HTTP module with connection pooling and file POST abilities.
Security Fix(es):
* proxy-authorization request header is not stripped during cross-origin
redirects (CVE-2024-37891)
For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page listed in the References section.