Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
LMDeploy versions 0.9.2 through 0.15.x have a remote code execution vulnerability in their DistServe feature, which uses pickle deserialization (a Python method that can accidentally run malicious code while unpacking data) on messages from untrusted ZeroMQ sockets. An attacker who can send requests to the `/distserve/p2p_connect` endpoint can trick the server into connecting to a malicious endpoint and executing arbitrary code with the privileges of the LMDeploy process, especially if API-key authentication is not enabled.
Fix: Upgrade to LMDeploy version 0.16.0 or later, which fixes the issue by replacing pickle deserialization with JSON serialization and validating received objects using the `DistServeCacheFreeRequest` Pydantic schema. If immediate upgrade is not possible, the source recommends these temporary mitigations: prevent untrusted clients from reaching `/distserve/*` endpoints, restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks, configure API-key authentication, and block arbitrary outbound ZeroMQ connections from serving nodes (though these measures do not make pickle deserialization safe).
GitHub Advisory DatabaseLiteLLM is a proxy server (a middleman that forwards requests to AI language model services) that had a security flaw before version 1.83.9. An authenticated user could sneak an api_base parameter (which controls where requests are sent) inside a user_config section of their request to bypass safety checks, allowing them to redirect the server's requests to internal systems or external servers they shouldn't normally access.
vLLM, a system that runs large language models, had a vulnerability before version 0.28.0 where attackers could request video processing using a specific decoder (PyNvVideoCodec) that wasn't properly accounted for in GPU memory budgets. This could cause the shared GPU memory to fill up, leading to crashed requests, crashed worker processes, or denial of service (making the system unavailable).
LMDeploy versions 0.9.1 through 0.10.1 contain a remote code execution vulnerability (RCE, where an attacker can run commands on a system they don't own) in its RPC server (a service that handles requests from other computers). The vulnerability exists because the server uses pickle.loads() (a Python function that converts serialized data back into code) directly on incoming messages without checking if they're safe, allowing attackers to execute malicious code.
The @zereight/mcp-gitlab package, which connects GitLab to an AI agent, has five security flaws that bypass its safety controls (read-only mode, project allow-lists, and authentication). These flaws let attackers execute write operations through GraphQL, access the tool without credentials, perform DNS rebinding attacks, exhaust sessions with fake tokens, and inject malicious instructions through CI job logs.
MCPVault (a tool that lets AI safely access files in Obsidian vaults, which are note-taking systems) has a security flaw in versions before 0.11.4 where it checks restricted directories in a way that doesn't account for how modern operating systems treat uppercase and lowercase letters the same. An attacker can trick an AI into accessing or modifying sensitive files by using different letter cases (like '.GIT' instead of '.git') or adding trailing spaces on Windows, bypassing the safety checks.
Flowise (a workflow automation tool) versions before 3.1.4 have a security flaw where it doesn't properly check if users have permission to access different workspaces (isolated project areas) in its OpenAI real-time endpoints. An authenticated user (someone with valid login credentials) can trick the system into letting them view and run tools from other users' workspaces by providing an unscoped chatflowid (a reference number without proper access restrictions), potentially exposing sensitive information and triggering unwanted actions.
CodeRAG, a tool that helps AI coding agents search through code, has a security flaw in versions before 1.3.1 where it automatically runs build files from repositories without checking if they're safe. An attacker can hide malicious code in a fake Gradle repository (a build system for Java projects), and when someone uses CodeRAG to index that repository, the hidden code runs with the user's full system permissions, potentially allowing the attacker to steal data, change files, install backdoors, or crash the system.
IBM Langflow OSS versions 1.0.0 through 1.10.0 have a critical vulnerability where attackers can run arbitrary Python code (code that does whatever the attacker wants) with root privileges (the highest access level) by uploading components that import socket or urllib libraries. This allows attackers to steal AWS credentials, steal files from the server, or attack other services like PostgreSQL and Redis running on the same network, while a faulty security check incorrectly marks these malicious components as safe.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a server-side request forgery vulnerability (SSRF, a flaw that lets attackers trick the server into making unauthorized requests on their behalf). An attacker without authentication could exploit this to probe the network or launch further attacks.
IBM Langflow OSS versions 1.0.0 through 1.11.2 contain a server-side request forgery vulnerability (SSRF, a flaw where an attacker tricks the server into making unwanted network requests). An authenticated attacker (someone with valid login credentials) could exploit this to send unauthorized requests from the system, potentially discovering network information or launching further attacks.
IBM Langflow OSS versions 1.0.0 through 1.10.2 have a server-side request forgery (SSRF, a vulnerability where an attacker tricks the server into making unintended requests to other systems) vulnerability that lets unauthenticated attackers send unauthorized requests from the affected system. This could be used to scan networks or set up follow-on attacks.
IBM Langflow OSS versions 1.0.0 through 1.11.5 has a security flaw where a logged-in attacker can view another user's MCP (Model Context Protocol, a system for connecting AI tools to external services) server settings because the cache key isolation (the method that keeps different users' data separate in temporary storage) is not working properly in the MCP Tools component.
IBM Langflow OSS (an open-source tool for building AI applications) versions 1.0.0 through 1.10.2 has a security flaw where an attacker who is already logged into an account can change another user's password because the system doesn't properly verify who should be allowed to make that change. This allows unauthorized account takeovers for authenticated users.
PraisonAI, a system that coordinates multiple AI agents working together, had a vulnerability in versions before 4.6.59 where an attacker could send commands to an unprotected API endpoint and trick the system into running arbitrary operating system commands without needing a password or approval. The vulnerability existed because the approve field could mark commands as safe before proper security checks happened.
CrewAI before commit fb2323b has a security flaw in how it tries to block dangerous code: it only blocks imports (the statements that load Python modules) but misses other ways to access dangerous functions, like using ctypes.CDLL(None) to directly load the C library without any import statements. This means the sandbox (an isolated environment meant to restrict what code can do) is incomplete because it doesn't account for all the ways Python can access powerful system functions at runtime.
vLLM versions 0.10.2 through 0.27.x have a vulnerability where audio extraction from video files lacks size and duration limits, allowing attackers to upload specially crafted compressed videos that force the server to use massive amounts of memory during decoding (a denial of service attack, where legitimate users can't access the service). This only affects NanoNemotronVL models when video audio processing is enabled.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.10.3 has a security flaw that allows an authenticated attacker (someone with login access) to run harmful code on the system. The problem occurs because the software does not properly restrict file paths (the locations where files are stored), which lets attackers access directories they shouldn't be able to.
IBM Langflow OSS versions 1.0.0 through 1.11.5 have a vulnerability where logged-in non-admin users can run arbitrary operating system commands (OS commands, or instructions executed directly on a computer) on the server by creating a flow that uses an MCP Tools component with local stdio subprocess transport, bypassing security controls meant to prevent this. This could allow attackers to access sensitive information, modify files, or move laterally (gain access to other connected systems) within the network.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability where an authenticated attacker (someone with login access) can execute arbitrary code (run any commands they want) by exploiting improper handling of special characters in flow display names (the text labels users give to workflows).
Fix: Update LiteLLM to version 1.83.9 or later, which fixes this issue.
NVD/CVE DatabaseFix: Update vLLM to version 0.28.0 or later, which contains the fix for this vulnerability.
NVD/CVE DatabaseFix: Update to version 0.10.2, which contains a patch for this vulnerability.
NVD/CVE DatabaseFix: Update MCPVault to version 0.11.4, which fixes this issue.
NVD/CVE DatabaseFix: Upgrade Flowise to version 3.1.4 or later.
NVD/CVE DatabaseFix: Update CodeRAG to version 1.3.1 or later, which fixes this issue.
NVD/CVE DatabaseFix: Update to praisonai 4.6.59 or praisonaiagents 1.6.59, which are the fixed versions that address this vulnerability.
NVD/CVE DatabaseFix: Fixed in vLLM 0.28.0. Users should upgrade to version 0.28.0 or later.
NVD/CVE Database