Most recent entries from pysec

PYSEC-2025-19

Mon, 03 Mar 2025 19:15:34 +0000

Affected: PyPI: picklescan

picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic.

PYSEC-2024-115

Tue, 05 Nov 2024 16:04:14 +0000

Affected: PyPI: langchain-community

A vulnerability in the GraphCypherQAChain class of langchain-ai/langchain-community version 0.2.5 allows for SQL injection through prompt injection. This vulnerability can lead to unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database.

PYSEC-2025-102

Tue, 22 Jul 2025 17:15:33 +0000

Affected: PyPI: dagster-ge

Local File Inclusion in dagster._grpc.impl.get_notebook_data in Dagster 1.10.14 allows attackers with access to the gRPC server to read arbitrary files by supplying path traversal sequences in the notebook_path field of ExternalNotebookData requests, bypassing the intended extension-based check.

PYSEC-2026-4182 — Zapros: Streaming decoders ignored the requested chunk size, allowing a single compressed response chunk to allocate un…

Thu, 01 Oct 2026 16:38:38 +0000

Affected: PyPI: zapros

### Impact

Denial of service via memory exhaustion. Affects all callers who streamed compressed responses relying on the chunk size — explicit (`iter_bytes(chunk_size=...)`) or the default — to bound memory. The decoder ignored that bound, so a chunk could be far larger than requested and a single compressed response could overflow memory.

```python import gzip, zapros

# Server returns ~1 GiB of zeros gzip-compressed to ~1 MiB, # with header: Content-Encoding: gzip bomb = gzip.compress(b"\0" * 1_000_000_000) # ~1 MiB on the wire

with zapros.stream("GET", "https://malicious.example/bomb") as response: # Caller asks for 8 KiB chunks, expecting bounded memory: for chunk in response.iter_bytes(chunk_size=8192): ... # first `chunk` is ~1 GiB, not 8 KiB -> memory exhaustion ```

### Patches

Upgrade to `0.14.0` or later. The decoders now bound the output of each decompression step to the requested `chunk_size`: gzip/deflate via `zlib`'s `max_length` + `unconsumed_tail`, brotli via `output_buffer_limit`, and zstd via a bounded `stream_writer`. Peak memory during streaming decode is now proportional to `chunk_size` for all supported encodings.

### Workarounds

For unpatched versions: - Read the still-compressed body with `Response.iter_raw()` / `Response.async_iter_raw()`, which bypass the built-in decoders, and decompress it yourself with an explicit output-size bound (e.g. `zlib`'s `max_length`), aborting once a configured limit is exceeded. - Where feasible…

PYSEC-2026-4181 — Zapros has an Unbounded Content-Encoding decompression chain that allows denial of service

Thu, 01 Oct 2026 16:38:38 +0000

Affected: PyPI: zapros

### Impact

**Who is impacted**: - Any application using Zapros to make HTTP requests to untrusted servers - Applications that follow redirects to attacker-controlled hosts

**Attack vector**: - A malicious HTTP server returns a response with many chained content encodings. When the client attempts to decode, it creates a deeply nested decompression chain consuming excessive resources.

### Patches

Fixed in version 0.14.0.

The fix adds a hardcoded limit of **5** `Content-Encoding` layers. Responses exceeding this limit raise `DecodingError`.

### Workarounds

Add middleware that checks for a malicious Content-Encoding header.

```python from typing import cast

from zapros import ( AsyncBaseHandler, AsyncBaseMiddleware, BaseHandler, BaseMiddleware, Client, DecodingError, Request, Response, )

MAX_DECODE_LAYERS = 5

class ContentEncodingCheckMiddleware(BaseMiddleware, AsyncBaseMiddleware): def __init__( self, next_handler: BaseHandler | AsyncBaseHandler, *, max_layers: int = MAX_DECODE_LAYERS, ) -> None: self.next = cast(BaseHandler, next_handler) self.async_next = cast(AsyncBaseHandler, next_handler) self._max_layers = max_layers

def _check(self, response: Response) -> None: encoding_header = response.headers.get("Content-Encoding") if not encoding_header: return

layers = [enc.strip().lower() for enc in encoding_header.split(","…

PYSEC-2026-4180 — wlc may disclose API tokens to project-configured URLs

Thu, 01 Oct 2026 16:38:34 +0000

Affected: PyPI: wlc

### Impact

wlc could send an unscoped API token to an unintended server when run inside a directory tree containing attacker-controlled project configuration.

If `.weblate`, `.weblate.ini`, or `weblate.ini` defines an API url, and the user supplies a token with `WLC_KEY` or `--key` without also pinning the URL, wlc would send the token to the project-configured URL.

Impacted users are those running wlc in untrusted repositories, pull request checkouts, or directories with untrusted ancestor configuration while using `WLC_KEY` or `--key`.

### Patches

The issue is patched in wlc 2.0.1 via https://github.com/WeblateOrg/wlc/pull/1500.

The fix rejects unscoped keys when the API URL comes from automatically discovered project configuration:

- `WLC_KEY` now requires `WLC_URL`. - `--key` now requires `--url`. - URL-scoped keys in the `[keys]` configuration section remain supported.

Users should upgrade to wlc 2.0.1 or newer.

### Workarounds

Without upgrading, users can avoid the issue by explicitly pinning the API URL whenever using an unscoped key:

`WLC_URL=https://hosted.weblate.org/api/ WLC_KEY=... wlc ...`

or:

`wlc --url https://hosted.weblate.org/api/ --key ... ...`

Alternatively, use URL-scoped keys in the [keys] section instead of WLC_KEY or --key, and avoid running wlc with secrets in untrusted checkouts.

- The issue was independently reported by [type5afe](https://hackerone.com/type5afe) and [visionx7](https://hackerone.com/visionx7) using HackerOne.

PYSEC-2026-4179 — vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions

Thu, 01 Oct 2026 16:38:32 +0000

Affected: PyPI: vllm

### Summary The audio decode-duration guard (`max_duration_s`, env `VLLM_MAX_AUDIO_DECODE_DURATION_S`, default 600s) that protects against audio decompression-bomb DoS is wired into **only** the speech-to-text path (`/v1/audio/transcriptions`). The **chat** audio path (`/v1/chat/completions`, `input_audio` content parts) calls the same decoder with **no** limit, so an **unauthenticated** client can submit a few-KB compressed audio file that expands to multiple GB of float32 PCM at decode time, OOM-killing the worker. This is a distinct sibling of **CVE-2026-5497** (video frame-count bomb, `VideoMediaIO.load_base64`) and **GHSA-pq5c-rjhq-qp7p** (image) in the same media subsystem.

Verified against `main` at HEAD `d78650c` (2026-06-16); applicable to the latest release v0.23.0.

### Details The guard rejects long audio *during* decode (before allocation), implemented in `vllm/multimodal/media/audio.py`: - `load_audio_pyav` — metadata reject (~82-98) and live sample-count reject (~129-136) - `load_audio_soundfile` — frames reject (~165-174)

All are gated on `if max_duration_s is not None`.

It is passed in exactly **one** place — the transcription serving layer: ```python # .../speech_to_text/base/serving.py:~170-174 load_audio(buf, sr=..., max_duration_s=self.max_audio_decode_duration_s) # self.max_audio_decode_duration_s = envs.VLLM_MAX_AUDIO_DECODE_DURATION_S (default 600) ```

The chat path never threads it: ```python # vllm/multimodal/media/audio.py:237-238 def load_b…

PYSEC-2026-4178 — vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation

Thu, 01 Oct 2026 16:38:32 +0000

Affected: PyPI: vllm

## Summary

Current vLLM `main` lets an inference request choose the PyNvVideoCodec GPU video decoder through `media_io_kwargs.video.video_backend`, but engine GPU memory reservation is computed only from static startup configuration and `VLLM_VIDEO_LOADER_BACKEND`. If the server starts with the default OpenCV/software backend and no `--mm-ipc-gpu-memory-gb` budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget.

## Technical Details

The vulnerable boundary is the split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker. Request bodies for Chat Completions and Responses expose `media_io_kwargs`, and those values are forwarded to the shared media connector. For video inputs, `MediaConnector.fetch_video()` copies `self.media_io_kwargs["video"]` into `video_io_kwargs`, only setting a model-derived backend when `video_backend` is absent. `VideoMediaIO.__init__()` then consumes `video_backend` from those kwargs and loads that backend from `VIDEO_LOADER_REGISTRY`.

The relevant request-side source path is:

```python video_io_kwargs = dict(self.media_io_kwargs.get("video", {})) if "video_backend" not in video_io_kwargs and ( video_backend := get_video_loader_backend_for_processor(video_processor) ): video_io_kwargs["video_backend"] =…

PYSEC-2026-4177 — urllib3: HTTPResponse.stream()/read_chunked() buffers an unbounded chunk-size line into memory

Thu, 01 Oct 2026 16:38:41 +0000

Affected: PyPI: urllib3

## Impact

urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for efficiently handling large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When decoding a [chunked-transfer-encoded response](https://httpwg.org/specs/rfc9112.html#chunked.encoding), this API reads each chunk's size field by buffering until it sees `\n` or EOF.

A malicious HTTP server can return `Transfer-Encoding: chunked` and then send a very long run of bytes without any newline, causing the streaming client to buffer that entire run before urllib3 can reject the chunk size as invalid and allocate more memory than intended.

To fix the issue, we'll reject chunk-size fields larger than 65536 bytes, as already done in the non-streaming case, which is currently handled by the Python standard library. Note that this only applies to reading the chunk-size field, not the chunk data, which is already handled correctly. Thus, there shouldn't be any impact for non-malicious servers.

## Affected usages

Applications and libraries using urllib3 versions earlier than 2.8.0 may be affected when streaming a chunked response from untrusted sources. Specifically, this affects the [read_chunked()](https://urllib3.readthedocs.io/en/stable/reference/urllib3.response.html#urllib3.response.BaseHTTPResponse.read_chunked) and [stream()](https://urllib3.readthedocs.io/en/stable/reference/urllib3.r…

PYSEC-2026-4176 — urllib3: Chunked Deflate streaming can enter an infinite loop

Thu, 01 Oct 2026 16:38:41 +0000

Affected: PyPI: urllib3

### Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading content in chunks instead of loading the entire response body into memory at once.

urllib3 can decompress response bodies according to the HTTP `Content-Encoding` header. When streaming a compressed, chunked response, urllib3 first consumes data already buffered by the decoder before reading the next HTTP chunk.

However, urllib3 versions from 2.6.2 through 2.7.0 could enter an infinite loop when a chunked response contained bytes after the end of the Deflate stream. If the decompressed body exceeded the requested streaming chunk size, Python's zlib implementation could retain the trailing bytes as unconsumed input after reaching the end of the compressed stream. urllib3 would repeatedly attempt to decode those same bytes without making progress or reading more data from the network.

A malicious server could exploit this behavior to cause excessive CPU usage and prevent the affected request from completing on the client. Network read timeouts would not interrupt the loop because no further socket operation was required.

### Affected usages

Applications and libraries using urllib3 versions 2.6.2 through 2.7.0 may be affected when all of the following conditions are met:

1. Compressed responses from an untrusted source are streamed using `HTTPResponse.stream(amt=N)` or `HTTPResponse.read_chunked(amt=N)` with a positive, finite chunk size. 2. Content decoding is en…