Kexinoh

**Name of the Vulnerable Software and Affected Versions** Pillow versions 4.2.0 through 12.1.x **Description** 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. **Recommendations** Update to version 12.2.0.

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.

**Name of the Vulnerable Software and Affected Versions** Langflow versions prior to 1.9.0 **Description** 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. **Recommendations** Versions prior to 1.9.0 should be updated to version 1.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenClaw versions prior to 2026.2.19 **Description** 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. **Recommendations** Update to version 2026.2.18 or later. Update to version 2026.2.19 or later. For versions prior to 2026.2.18, consider temporarily restricting concurrent access to the registry update and removal operations.

**Name of the Vulnerable Software and Affected Versions** OpenClaw versions prior to 2026.2.15 **Description** 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. **Recommendations** Update OpenClaw to version 2026.2.15 or later.

**Name of the Vulnerable Software and Affected Versions** OpenClaw versions prior to 2026.2.15 **Description** 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. **Recommendations** Update to version 2026.2.15 or later.

**Name of the Vulnerable Software and Affected Versions** LLaMA-Factory versions prior to 0.9.4 **Description** 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. **Recommendations** Update LLaMA-Factory to version 0.9.4 or later.

**Name of the Vulnerable Software and Affected Versions** huggingface LeRobot versions up to 0.3.3 **Description** 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. **Recommendations** Update to a version beyond 0.3.3.

**Name of the Vulnerable Software and Affected Versions** coze-studio versions up to 0.2.4 **Description** 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. **Recommendations** Deploy a patch to address this issue.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.6.4 through 0.9.0 **Description** 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. **Recommendations** For versions 0.6.4 through 0.9.0, update to version 0.9.0 or later, which contains a patch for the issue. As a temporary workaround, consider restricting access to the vulnerable `pythonic tool parser.py` file until the update is applied. Avoid using the vulnerable regular expression pattern in the `vllm/entrypoints/openai/tool parsers/pythonic tool parser.py` file until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.7.0 through 0.8.x **Description** 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. **Recommendations** For versions 0.7.0 through 0.8.x, update to version 0.9.0, which includes a patch for this issue. As a temporary workaround, consider modifying the serialize item method in the MultiModalHasher class to include all critical metadata, such as dimensions, color mode, format, and the info dictionary, in the hash calculation to prevent collisions.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.8.0 through 0.8.4 **Description** 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. **Recommendations** For versions 0.8.0 through 0.8.4, update to version 0.8.5 to resolve the issue. As a temporary workaround, consider restricting the use of the multimodal tokenizer to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.5.2 through 0.8.5 **Description** 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. **Recommendations** For versions 0.5.2 through 0.8.5, update to version 0.8.5 to resolve the issue. As a temporary workaround, consider blocking the port used by the XPUB ZeroMQ socket to prevent unauthorized access. Restrict access to the ZeroMQ socket to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.6.5 through 0.8.4 **Description** 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. **Recommendations** To resolve the issue, update to version 0.8.5 or later. As a temporary workaround, consider disabling the mooncake integration until a patch is applied. Restrict access to the vulnerable ZeroMQ sockets to minimize the risk of exploitation. Avoid using pickle-based serialization over unsecured sockets in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** vLLM AIBrix version 0.2.0 **Description** 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. **Recommendations** For vLLM AIBrix version 0.2.0, upgrade to version 0.3.0 to address this issue. It is recommended to upgrade the affected Prefix Caching component.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.7.2 **Description** 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. **Recommendations** For versions prior to 0.7.2, upgrade to version 0.7.2 or later to address the issue. As a temporary workaround, consider initializing hashes in vllm with a value that is no longer constant and predictable, or using a hashing algorithm that is less prone to collision, such as `sha256`, although this may have an impact on performance and memory footprint. Avoid using prompts that are known to collide with other prompts in use until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** free-one-api versions up to and including 1.0.1 **Description** 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. **Recommendations** For versions up to and including 1.0.1, consider disabling password hashing using MD5 until a secure replacement is implemented. As a temporary workaround, restrict access to sensitive areas of the application to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** beego versions prior to 2.3.4 **Description** 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. **Recommendations** For versions prior to 2.3.4, update to version 2.3.4 or later, which replaces MD5 with SHA256, a more secure hash function resistant to known attack vectors. As a temporary workaround, consider using a more secure hash function like SHA-256 in place of MD5 for hashing cache keys. Restrict access to sensitive cached information to minimize the risk of exploitation. Avoid using MD5 for generating filenames for cache keys until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Tornado versions prior to 6.4.2 **Description** 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. **Recommendations** For versions prior to 6.4.2, update to version 6.4.2 to fix the issue. As a temporary workaround, consider restricting the size of HTTP cookie headers to minimize the risk of exploitation.