Kexinoh

A flaw in the `PdfParser` allows an attacker to supply a malicious PDF that causes the process to hang indefinitely, consuming 100% CPU and making the application unresponsive. This occurs because the parser follows Prev pointers in PDF trailers to read cross-reference sections; if a pointer references an offset already processed, either by pointing to itself or forming a cycle, the parser enters an infinite loop.

Name of the Vulnerable Software and Affected Versions vLLM versions 0.5.5 through 0.17.999 Description vLLM, an inference and serving engine for large language models (LLMs), exhibits an inconsistency in audio processing. Versions 0.5.5 through 0.17.999 utilize numpy.mean for mono downmixing via Librosa, deviating from the ITU-R BS.775-4 weighted downmixing standard. This discrepancy causes differences in audio perception between human listeners and AI models that process audio using Librosa. Recommendations Update to version 0.18.0 or later.

Langflow's Agentic Assistant feature, prior to version 1.9.0, executes LLM-generated Python code during validation. This implementation allows for arbitrary server-side Python execution if an attacker can access the Agentic Assistant feature and influence the model output. The vulnerable code path involves processing model output through a chain that ultimately invokes `create class()`, which dynamically executes Python code using `exec()`. The affected endpoints include `/api/v1/login` and the assistant feature relies on user authentication via bearer token, cookie, or API key. Default deployment settings, such as `AUTO LOGIN=true` and the `/api/v1/auto login` endpoint, may widen exposure. The issue is an authenticated code execution vulnerability, with severity depending on the deployment model.

The software contains a race condition in concurrent `updateRegistry` and `removeRegistryEntry` operations for sandbox containers and browsers. This occurs due to unsynchronized read-modify-write operations without locking, potentially leading to data loss, resurrection of removed entries, or corruption of sandbox state. This can affect `sandbox list`, `sandbox prune`, and `sandbox recreate --all` operations. The registry writes were read-modify-write in a window with no locking and permissive fallback parsing, allowing concurrent registry updates to produce stale snapshots and overwrite each other, desynchronizing sandbox state.

OpenClaw is a personal AI assistant. Prior to version 2026.2.15, the `normalizeForHash` function in `src/agents/sandbox/config-hash.ts` recursively sorted arrays containing only primitive values. This resulted in order-sensitive sandbox configuration arrays hashing to the same value even when the order changed. In OpenClaw sandbox flows, this hash determines whether existing sandbox containers are recreated. Consequently, changes to array order in the configuration (for example, Docker `dns` and `binds` array order) could be considered unchanged, leading to the reuse of potentially stale containers. This represents a configuration integrity issue affecting sandbox recreation behavior. Starting with version 2026.2.15, array ordering is preserved during hash normalization, with only object key ordering normalized for deterministic hashing.

The software uses SHA-1 to hash sandbox identifier cache keys for Docker and browser sandbox configurations. SHA-1 is a deprecated cryptographic hash function with known collision weaknesses. A collision in this hash could allow an attacker to cause cache poisoning, potentially leading to unsafe sandbox state reuse. The software uses deterministic IDs to determine if an existing sandbox container can be safely reused. Exploiting this issue could allow one configuration to be misinterpreted as another under the same sandbox cache identity. The implementation has been updated to use SHA-256 for these hashes to restore collision resistance.

LLaMA-Factory, a tuning library for large language models, contains a Server-Side Request Forgery (SSRF) issue in the chat API. Authenticated users can make the server send arbitrary HTTP requests to internal and external networks, potentially exposing sensitive internal services, allowing network reconnaissance, or interacting with third-party services. A Local File Inclusion (LFI) issue also exists, allowing users to read arbitrary files from the server's filesystem. The issue resides in the ` process request` function within `src/llamafactory/api/chat.py`. This function processes multimodal content from URLs, and if the URL is not a base64 data URI or a local file path, it makes an HTTP GET request using `requests.get(url, stream=True).raw` without validating or sanitizing the URL.

A vulnerability exists in huggingface LeRobot up to version 0.3.3 related to missing authentication within the ZeroMQ Socket Handler functionality of the file `lerobot/common/robot devices/robots/lekiwi remote.py`. The attack can only be initiated within the local network. The vendor was contacted but did not respond.

A vulnerability exists due to the use of hard-coded cryptographic keys. The issue is located in an unknown function within the `backend/domain/plugin/encrypt/aes.go` file. Manipulation of the `AuthSecretKey`, `StateSecretKey`, and `OAuthTokenSecretKey` arguments can trigger this issue. The attack can be initiated remotely and is considered difficult to exploit.

Multiple regular expression denial of service (ReDoS) issues exist where several regex patterns are susceptible to catastrophic backtracking—a condition where a complex regex takes an exponential amount of time to process certain inputs. This can be triggered by an attacker submitting crafted input with nested or repeated structures, leading to severe CPU consumption and performance degradation. The affected components include the OpenAI-compatible serving chat endpoint, the phi4mini tool parser, and the `vllm/lora/utils.py` file.

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the vLLM project, specifically in the file `vllm/entrypoints/openai/tool parsers/pythonic tool parser.py`. The root cause is the use of a highly complex and nested regular expression for tool call detection, which can be exploited by an attacker to cause severe performance degradation or make the service unavailable. The pattern contains multiple nested quantifiers, optional groups, and inner repetitions, making it vulnerable to catastrophic backtracking. This can lead to Denial of Service (DoS), resource exhaustion, and potential broader system instability.

The issue concerns a critical performance vulnerability in the input preprocessing logic of the multimodal tokenizer. It is caused by inefficient list concatenation operations, resulting in quadratic time complexity (O(n²)), which allows malicious actors to trigger resource exhaustion via specially crafted inputs.

The issue affects vLLM, a high-throughput and memory-efficient inference and serving engine for LLMs. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes, opening an XPUB ZeroMQ socket and binding it to all interfaces. This allows any client with network access to connect to the socket, unless its port is blocked by a firewall, and receive internal vLLM state information. Although this data is not useful to an attacker, connecting to the socket multiple times without reading the published data can cause a denial of service by slowing down or potentially blocking the publisher.

The issue concerns a security and data integrity problem in the image hashing method of the MultiModalHasher class. Specifically, the method serializes PIL.Image.Image objects using only obj.tobytes(), which returns the raw pixel data without including metadata such as the image's shape. This can lead to hash collisions, incorrect cache hits, and potential data leakage or security risks. The problem arises because two images with the same pixel byte sequence but different sizes could generate the same hash value.

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. The issue concerns the use of pickle-based serialization over unsecured ZeroMQ sockets when vLLM is integrated with mooncake, leading to remote code execution. The vulnerable sockets were set to listen on all network interfaces, increasing the likelihood of an attack. vLLM instances without mooncake integration are not vulnerable. This issue has been patched in version 0.8.5.

A vulnerability has been found in the Prefix Caching component, specifically in the file `pkg/plugins/gateway/prefixcacheindexer/hash.go`. This issue leads to insufficiently random values. The complexity of an attack is rather high, and the exploitation appears to be difficult.

Maliciously constructed statements can lead to hash collisions, resulting in cache reuse, which can interfere with subsequent responses and cause unintended behavior. The issue arises from the use of Python's built-in `hash()` function, which as of Python 3.12, returns a predictable constant value for `hash(None)`. This makes it more feasible for someone to exploit hash collisions. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use. The impact of a collision would be using cache that was generated using different content.

The issue concerns the use of MD5, a cryptographically broken hashing algorithm, to hash passwords before sending them to the backend. This makes it vulnerable to collision attacks and can be easily cracked using modern hardware, exposing user credentials to potential compromise. The free-one-api allows users to access large language model reverse engineering libraries through the standard OpenAI API format.

The issue concerns the use of MD5 as a hashing algorithm in beego, which is no longer considered secure due to its vulnerability to collision attacks. This vulnerability can lead to data integrity risks, security vulnerabilities, and unpredictable behavior in cache systems. A collision in hashing occurs when two different inputs produce the same hash output, allowing attackers to potentially exploit collisions and manipulate cache data.

The algorithm used for parsing HTTP cookies in Tornado sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests, potentially allowing a remote attacker to cause a denial of service.