Search: 1.2.4.4

A vulnerability in chrome-devtools-mcp component of Google Chrome on Linux versions prior to 1.5.0 allows a local attacker to perform arbitrary read and write operations via a malicious file due to insufficient policy enforcement. The issue is rated with medium severity by Chromium security.

Seroval versions 1.6.0 through 1.6.10 contain a vulnerability where typed arrays that have an own constructor property set from untrusted data can lead to code injection during serialization. This occurs because the constructor name is read from a mutable property on the typed array rather than its internal type, allowing arbitrary code to be serialized. The issue is fixed in version 1.6.11. The vulnerability requires unusual conditions where properties from untrusted objects are copied onto typed arrays.

Seroval versions before 1.0.0 and from 1.5.5 up to but not including 1.6.10 improperly serialize RegExp sources containing the '<' character without escaping it. This can allow an attacker to inject script code if the RegExp is built from untrusted input and the serialized output is placed inside an HTML <script> element. The vulnerability is fixed in version 1.6.10 by changing the serialization method to use the RegExp constructor with an escaped string source.

The Seroval library versions prior to 1.6.8 contain a denial-of-service vulnerability in the fromJSON and fromCrossJSON deserialization functions. These functions trust node-supplied array lengths and sequence doneAt indices without validation, allowing crafted inputs to cause infinite loops or prolonged blocking of the event loop. This can be triggered by unauthenticated requests passing untrusted input, resulting in service unavailability. The issue is fixed in version 1.6.8 by enforcing strict validation of array elements and sequence indices, throwing errors on malformed input.

Seroval versions from 1.4.1 up to but not including 1.6.8 contain a denial of service vulnerability in the fromJSON and fromCrossJSON functions. These functions fail to validate that an array node's element list is actually an array, allowing crafted payloads to control memory allocation and processing loops. This can cause the service to become unavailable due to excessive memory use or prolonged thread blocking. The issue bypasses a previous fix and affects any framework using these functions to decode untrusted request bodies before validation. The vulnerability is fixed in version 1.6.8.

A vulnerability in mem0ai's session key construction allows cross-tenant data leakage and corruption. The function _build_session_scope() concatenates user_id, agent_id, and run_id with unescaped '&' and '=' delimiters, enabling an attacker controlling only run_id or agent_id to craft values that collide with another tenant's session key. This leads to unauthorized reading and overwriting of another tenant's conversation history. The flaw affects both Python and TypeScript SDKs and is fixed in versions 2.0.18 and 3.1.6.

A vulnerability in ONNX ConvTranspose shape inference causes an out-of-bounds read when the weight tensor has fewer than three dimensions and no kernel_shape attribute is provided. This leads to a process crash (denial of service) during shape inference on a crafted model. The issue affects ONNX versions 1.2.1 through 1.21.0 and is fixed in version 1.22.0. No confidentiality or integrity impact is reported.

ONNX versions prior to 1.22.0 contain a vulnerability in their Python tensor-materialization helpers where packed sub-byte tensors are expanded without verifying that the payload contains the declared number of elements. This can cause excessive memory allocation when processing maliciously crafted models, leading to denial of service via memory exhaustion. The issue affects specific tensor types stored in raw_data or packed int32_data. The vulnerability is fixed in ONNX 1.22.0 and later.

A vulnerability in ONNX shape inference (versions 1.4.0 through 1.21.0) allows denial of service via null pointer dereference or excessive allocation caused by improper validation of the required Scan attribute 'num_scan_inputs'. This can cause application termination or exceptions when processing malformed models. The issue is fixed in ONNX 1.22.0.

ONNX versions through 1.21.0 have a vulnerability in shape inference for RNN, GRU, and LSTM nodes from opsets 1–6 where an out-of-bounds read occurs if the first input's rank is not three. This can cause a process using onnx.shape_inference.infer_shapes() to crash, resulting in denial of service. The issue is fixed in ONNX 1.22.0 by validating the input rank before accessing dimensions.

vLLM deployments serving DeepSeek-OCR family models are vulnerable to a denial of service caused by a crafted PNG image. A legitimate half-black/half-white 1024×1024 image triggers a zero-sum pixel value condition that causes the model's input validation to return None. This leads to an assertion failure in the engine worker process, crashing the entire service and requiring manual restart. The issue affects versions from 0.11.1 up to but not including 0.32.0 and is fixed in version 0.32.0.

vLLM versions prior to 0.32.0 contain a vulnerability where an out-of-vocabulary token ID equal to the vocabulary size can bypass input validation and cause a CUDA device-side assert, crashing the engine. This affects models whose vocabulary size is an exact multiple of the embedding padding size (64), such as Llama-2-family models with a vocab size of 32000. The issue occurs specifically when using a single GPU (tensor parallel size 1) configuration. The flaw was fixed in vLLM version 0.32.0 by correcting the maximum accepted token ID validation.

A denial of service vulnerability exists in github.com/go-jose/go-jose/v4 where parsing deeply nested JSON structures can cause the Go runtime to hit its stack limit and crash the application. This affects versions prior to 4.1.5 and up to 3.0.5. The issue is fixed in version 4.1.5. Applications parsing untrusted JSON with affected versions are exposed to crashes.

A denial of service vulnerability exists in github.com/go-jose/go-jose/v4 when decrypting ciphertexts using the CBC-HMAC content encryption algorithms A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512. Insufficient validation of parameters can cause a panic due to indexing into an empty buffer on untrusted input. This affects versions prior to 4.1.5 and up to 3.0.5. A fix is available in version 4.1.5.

The graphql-scalars package's PhoneNumber scalar is vulnerable to a regular expression denial of service (ReDoS) due to an exponential backtracking flaw introduced in version 1.24.1. This flaw allows specially crafted inputs of digits followed by a failing character to stall the JavaScript thread for seconds, with processing time doubling for each additional digit. The vulnerability affects all versions from 1.24.1 up to and including 2.0.0. The regex runs during GraphQL document validation and variable coercion, before any authentication or authorization, enabling unauthenticated requests to cause denial of service. A fix is available in version 2.0.1.

LangGraph API versions from 0.1.2 up to but not including 0.15.0 that use JavaScript or TypeScript custom authentication with namespace rewriting for Store authorization may allow authenticated users to access or modify data outside their authorized namespace. This vulnerability does not affect Python custom authentication or handlers that reject unauthorized namespaces. The issue is fixed in version 0.15.0.

filelock versions 4.1.0 through 4.2.0 contain a vulnerability in SoftReadWriteLock where a local user with write access to the lock's parent directory can replace the lock directory tree with symbolic links after the first lock acquire. This causes the lock user process to write lock records through the symbolic links, potentially corrupting files such as a git repository's HEAD file. The vulnerability requires local access and specific directory conditions but does not expose confidentiality or availability impacts. It has a low CVSS score of 3.3 and is fixed in version 4.2.1.

The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in StrictSoftFileLock and AsyncStrictSoftFileLock where claim directories are created without applying the caller's restrictive mode, resulting in directories with permissions influenced by the process umask or parent directory ACLs. This can allow another local user with write access to these directories to unlink claim files, causing multiple holders to believe they hold the lock simultaneously, leading to integrity issues. The vulnerability requires a local attacker with low privileges and specific environment conditions such as a permissive umask or default ACLs. The issue is fixed in version 4.2.1.

filelock versions 3.30.0 through 4.2.0 have a vulnerability where StrictSoftFileLock and SoftReadWriteLock classes adopt a protocol directory created by another local user if it exists before the lock user's first acquire. This allows the other user to manipulate lock state files, causing integrity and availability issues such as multiple writers entering critical sections simultaneously and denial of service via spinning locks or memory exhaustion. The vulnerability requires local access and the ability to create directories in shared sticky-bit directories like /tmp before the lock user. It has no confidentiality impact but high integrity and availability impact. A fix is available in version 4.2.1.

The filelock library on Windows ignores the 'mode' argument when creating lock files, causing files intended to have restrictive permissions (0o600) to inherit the directory's ACL instead. This allows other local accounts with read or modify access to the directory to read or write the lock files and interfere with the locking mechanism. The issue affects filelock versions 3.10.0 through 4.2.0 on Windows and is confirmed by the maintainers. Unix systems are not affected. A fix is available in version 4.2.1.