AI & LLM Vulnerabilities

IBM Financial Transaction Manager for RedHat OpenShift has a security flaw where unauthenticated attackers can inject malicious content into the AI agent's runbook database without needing a password or login credentials, allowing them to manipulate the AI into making unauthorized payments or stealing payment information through RAG poisoning (corrupting the external documents that an AI uses to answer questions).

The `upload_attachment` method in MCP Atlassian (a tool that connects AI agents to Atlassian software) reads and uploads any file from the server without checking if the file path is safe, while the download methods correctly use a safety check called `validate_safe_path()`. This means an AI agent or attacker could read sensitive files like SSH keys, passwords, or credentials and steal them by uploading them to Confluence.

The MCP Atlassian tool for Jira and Confluence has a vulnerability where the file upload functions accept file paths controlled by the caller and read those files from the server's local filesystem before uploading them as attachments. This means an attacker using the tool can trick the server into reading and uploading any file the server process can access, especially in HTTP or multi-user deployments where the caller and server are separate security boundaries.

The `mcp-atlassian` tool has a path traversal vulnerability (CWE-22, a weakness that lets attackers access files outside intended directories) in its `confluence_upload_attachment` function. An attacker can read any file the server can access by passing an arbitrary file path, then upload that file to an attacker-controlled server. This is especially dangerous because the default setup exposes the tool over the network without authentication, making it remotely exploitable.

9Router has an authentication bypass vulnerability where attackers can fake being a local client by adding a spoofed X-9r-Real-Ip header (a custom HTTP header that tells the server where a request came from). The app trusts this header to decide whether to require an API key, but when deployed without its protective wrapper layer, attackers can send X-9r-Real-Ip: 127.0.0.1 to bypass authentication and gain unauthorized access to the LLM API and the owner's provider resources.

A path traversal vulnerability (a security flaw where an attacker can access files outside an intended directory using paths like `../`) existed in the @roomi-fields/notebooklm-mcp tool, allowing attackers or prompt-injected LLMs (large language models controlled through manipulated input) to write files anywhere the server could access. This affected versions 1.6.0 through 2.0.2, and while the written files themselves couldn't execute code, they could be placed in sensitive locations for later exploitation.

A vulnerability in vLLM Mooncake connector (a component that helps distribute AI model processing across systems) through version 0.29.0 fails to properly track ownership of GPU KV cache blocks (temporary storage on graphics processors for speeding up AI responses) when multiple child requests share the same transfer ID. Attackers can exploit this by sending completion requests with multiple prompts, causing orphaned cache blocks to build up until the system restarts, eventually blocking legitimate user requests from running.

vLLM (a popular open-source LLM serving framework) versions up to 0.29.0 don't properly check the tp_size parameter (a setting that controls how a model is split across multiple processors) when handling requests through its OpenAI-compatible API endpoints. This allows attackers to submit extremely large tp_size values that cause the system to use unlimited memory, crashing the decode worker (the part that generates responses) through an out-of-memory error.

vLLM (a system for running large language models) versions up to 0.29.0 have a denial of service vulnerability (a bug that lets attackers crash the system) in its P2P KV offloading feature (a method where the system transfers memory data between computers in a peer-to-peer network). Attackers can provide fake network addresses that cause the system to create broken connections that waste memory resources until the system crashes and stops responding to user requests.

vLLM versions up to 0.29.0 have a denial of service vulnerability in its NIXL connector's prefix caching (a feature that reuses parts of previously processed text to speed up responses) that doesn't properly check block counts when handling multiple prompts of different lengths in certain deployment setups. An attacker can crash the decode worker (the part that generates responses) by sending specially crafted requests, forcing a restart to restore service.

vLLM (a system for running large language models) versions up to 0.29.0 have a denial of service vulnerability (a flaw that lets attackers crash a service) in how the NIXL connector handles metadata for split deployments. An attacker can send specially crafted requests that cause an uncaught KeyError (a programming error where the code tries to access a dictionary key that doesn't exist) in the scheduling system, crashing the decode engine and forcing a manual restart to recover.