Advisories
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
3,134 items
IBM Financial Transaction Manager (FTM) for RedHat OpenShift is affected by CVE-2026-18875, a RAG poisoning flaw (CWE-74) caused by an unauthenticated runbook upsert in the FTM AI agent server at api.vectordb.runbooks.js:51. An unauthenticated attacker can insert malicious runbook content into the agent's vector database. This can steer AI-driven MCP tool calls, potentially triggering unauthorized payment actions or exfiltrating payment data.
The LightRAG WebUI renders assistant answer content as raw HTML, using react-markdown with rehypeRaw, skipHtml set to false, and no sanitizer or allow-list. Because answers are derived from ingested documents, an attacker who can add one document can store a payload that runs in the browser of any user who later retrieves it, such as an administrator. The source says this can lead to authentication token theft from localStorage and full API takeover, and no authentication is required in the default configuration.
The upload_attachment method in confluence/attachments.py of mcp-atlassian reads and uploads arbitrary local files to Confluence without calling validate_safe_path(), although the download methods do call it. An MCP-connected AI agent, or an attacker influencing it through prompt injection, can read any file the server process can access, such as SSH keys, AWS credentials or .env files, and exfiltrate it as a Confluence page attachment. The issue was reproduced with mcp-atlassian 0.21.1 on Python 3.11.
Add validate_safe_path(file_path) before the os.path.exists() check in upload_attachment, matching the existing pattern in the download methods. The function is already imported in that file.
The Jira and Confluence attachment upload tools in MCP Atlassian accept caller-controlled file_path parameters and read those paths from the MCP server's local filesystem before uploading them as Atlassian attachments. In local stdio deployments this exposes files readable by the user's MCP process, while in HTTP/SSE or streamable-http deployments any MCP client permitted to invoke upload tools can make the server read a server-local file and upload it to Jira or Confluence. The flaw is deterministic and does not depend on prompt injection or model behavior.
The mcp-atlassian server's confluence_upload_attachment MCP tool passes its file_path argument straight to open(file_path, "rb") with no path validation, so a caller can read arbitrary files the server process can read and upload them to an attacker-controlled Confluence host. With the default streamable-http transport binding 0.0.0.0 without authentication, this is remotely exploitable without credentials. It is the read-side counterpart of GHSA-xjgw-4wvw-rgm4 / CVE-2026-27825, whose fix in v0.17.0 covered only the download path.
The upload_attachment methods in MCP Atlassian's Confluence and Jira integrations accept arbitrary file paths without path traversal validation. The validate_safe_path utility is used in the download paths but never called in the upload paths, so an authenticated MCP client, or an AI assistant manipulated via prompt injection, can read any file the server process can access and upload it to an attacker-chosen Confluence page or Jira issue.
CVE-2026-95660 is a flaw in Moonshot AI Kimi Code up to 0.31.0, in an unknown function of agent-core-v2/src/agent/mcp/config-loader.ts within the MCP Configuration Loader component. Manipulating it results in OS command injection, and the attack may be launched remotely. The exploit has been released publicly and may be used for attacks.
Fix: Upgrade to version 0.31.1. The fix also resolves fd and stty binaries to absolute paths so untrusted workspaces cannot plant bare-name executables before confirmation, addressing a secondary $PATH path-planting vector alongside the primary untrusted-.mcp.json auto-spawn.
LightRAG's API server, before version 1.5.5, returns raw Python exception text from error handlers in document_routes.py, graph_routes.py, query_routes.py, ollama_api.py and lightrag_server.py. A network client that triggers an error can read server filesystem paths, database host, port, user and database names, language-model provider diagnostics, configuration details and library internals, and with URI-configured backends possibly connection strings containing credentials. The default unauthenticated configuration makes these responses reachable without credentials.
9router decides whether a request is local by trusting the client-supplied X-9r-Real-Ip header in isLocalRequest() within src/dashboardGuard.js. When the app runs without custom-server.js, which normally strips and regenerates that header, an unauthenticated remote attacker can send X-9r-Real-Ip: 127.0.0.1 to reach /api/v1/* without an API key. The reported impact includes unauthorized use of the owner's configured LLM provider connections and consumption of paid API credits. The issue was verified on 9router-app 0.5.4 (Next.js 16.2.9) using GET /api/v1/models.
The vault_batch MCP tool and the POST /batch-to-vault HTTP endpoint in @roomi-fields/notebooklm-mcp passed a caller-supplied vault_dir directly to path.resolve() and fs.mkdir() with no containment check, and slug_prefix was concatenated into filenames without sanitization. Affected versions run from v1.6.0 through v2.0.2, and an attacker, or a prompt-injected LLM driving the MCP, could write .md and .json files to any location the server process can write, such as autostart folders or shell startup files.
The PixelPlay plugin for WordPress lacks authorization checks in all versions up to and including 1.0.2, tracked as CVE-2025-14486. Unauthenticated attackers can delete arbitrary API keys for Pixabay, Unsplash, Pixels and OpenAI that site administrators configured, using the 'clear_api_type' parameter.
The vLLM Mooncake connector through 0.29.0 does not properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. An attacker can submit completion requests with multiple prompts to trigger GPU memory exhaustion, as orphaned KV cache blocks accumulate until the process restarts and legitimate requests can no longer execute.
vLLM through 0.29.0 does not validate the tp_size parameter in kv_transfer_params on its OpenAI-compatible completion endpoints. Attackers can supply arbitrary tp_size values in prefill/decode disaggregated deployments, allocating unbounded memory and exhausting it, which triggers a kernel OOM-kill of the decode worker process.
CVE-2026-94625 affects vLLM through 0.29.0 in MooncakeConnector. Rejected prefill requests leave ownerless transfer placeholders that are never reclaimed, so an attacker can send such requests to exhaust sender task pools. Valid requests can then be delayed by up to 480 seconds while health checks keep returning success.
vLLM through 0.29.0 has a denial of service flaw in peer-to-peer KV offloading when OffloadingConnector uses TieringOffloadingSpec with a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions, which retain ZeroMQ sockets until the context quota is exhausted. The resulting uncaught ZMQError crashes EngineCore and halts all inference.
CVE-2026-94623 affects vLLM through 0.29.0, specifically the NIXL connector's prefix caching implementation in prefill/decode disaggregated deployments. Completion requests containing multiple prompts of varying lengths trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching, because block counts are not properly validated. The resulting crash makes the decode worker unavailable until it is restarted.
vLLM versions through 0.29.0 contain a denial of service flaw in the NIXL connector's metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, which terminates the decode engine and makes all routed requests fail until a manual restart.
MaxKB, an open-source enterprise AI assistant, from version 2.0.0 through 2.9.2 lets a lowest-role workspace member bind and execute a tool they are denied by WorkspaceUserResourcePermission, using tool_ids, skill_tool_ids, or mcp_tool_ids through the agent or workflow dispatch path. Dispatch does not reapply the per-tool grant enforced by dedicated tool routes, so the caller can receive credentials in the denied tool's server-side init_params.
Hatchet, a platform for orchestrating background tasks, AI agents, and durable workflows, has a flaw in versions before 0.106.1. The WorkerStatus gRPC polling path in pkg/repository/durable_events.go passes caller-supplied durable task, node, and branch identifiers to ListSatisfiedEntries without a tenant filter. An authenticated tenant worker that knows another tenant's durable-task UUID can retrieve matching durable event-log records. The source notes that the UUIDv4 requirement makes exploitation unlikely and that single-tenant deployments are unaffected in practice.
CVE-2026-84298 affects Hatchet versions before 0.95.3. The V1 DurableTask stream handler stores worker-supplied task_external_id values in the durableInvocations routing map before verifying tenant ownership, and callback delivery looks up that map by task UUID without tenant identity. An authenticated tenant worker that knows another tenant's durable task UUID, and keeps a stream open on the same dispatcher process, can receive that task's durable callback result payload. UUIDv4 values are not enumerable, and single-tenant deployments are unaffected in practice.
Fix: Recommend trust: false for KaTeX. The source does not state a fix for the stored XSS itself.
Fix: Server-local file uploads should be denied by default in HTTP/SSE or multi-user deployments, or uploads should be constrained to an explicit allowlisted upload directory after realpath resolution, and dangerous path forms such as remote UNC paths and file:// URLs should be rejected before filesystem checks.
Fix: Fixed in 1.5.5.
Fix: Do not trust X-9r-Real-Ip (or any X-9r-* header) received directly from clients. Derive the client address for authorization from a trusted transport-level source, such as req.socket.remoteAddress. If custom-server.js is required for the security model, fail closed when its trusted marker is absent and strip or reject inbound client-supplied X-9r-* headers at the edge. Document supported secure startup modes so the header cannot be attacker-controlled.
Fix: Fixed in v2.0.3: set the NOTEBOOKLM_VAULT_ROOT environment variable to a directory that bounds all vault writes, which enables realpath-based containment, since it is unset by default and the legacy unrestricted behaviour remains when it is unset. slug_prefix is now always sanitized regardless of that variable. Users who cannot upgrade should run the server under a dedicated unprivileged user with write access only to the intended vault directory, keep the HTTP endpoint off non-localhost interfaces, and validate vault_dir arguments before forwarding them.
Fix: This issue is fixed in version 0.106.1.
Fix: This issue is fixed in version 0.95.3.