Threat Library

Flowise, a popular low-code LLM/agent orchestration platform, returns decrypted credential secrets in plaintext via its credentials API because its redaction logic only masks fields explicitly typed as 'password', missing string-typed fields that commonly hold database URLs, private keys, and API keys. Any authenticated user with 'credentials:view' permission can retrieve full secrets for connection strings, cloud service accounts, and other integrations configured in the workspace, enabling lateral movement into downstream systems the agent platform connects to.

This is an academic research paper (not an active exploit) that systematically demonstrates how prompt injection—both direct (task instructions) and indirect (via perception modules)—can manipulate LLM-based multi-agent robotic systems into unsafe or adversarial actions. The study's key contribution is showing that injected instructions can propagate from one compromised agent to others through shared prompt structures, expanding the blast radius beyond the initially targeted agent. Because it is a controlled research evaluation rather than an in-the-wild attack, real-world severity depends heavily on deployment specifics, but the findings are directly actionable for adversaries and defenders alike.

This item is a blog quote describing a practice of running a nightly cron job that instructs an AI coding agent to autonomously fetch upstream changes, rebase local modifications, verify functionality, and replace the running software version. This is not itself an attack or exploit report, but it describes a risky operational pattern: unattended, unsupervised agentic code modification and deployment. Severity is medium because the described practice creates a plausible attack surface (supply-chain and prompt-injection risk) even though no actual exploit is documented here.

The gemini-bridge MCP server, which connects AI agents to Google's Gemini CLI, failed to restrict file paths passed to its consult_gemini_with_files tool in inline mode. This allowed any file on the host filesystem to be read and forwarded through the Gemini round-trip, effectively exfiltrating local file contents to an external third party (Google) via a trusted tool call. The issue is fixed in version 1.3.1.

IBM Langflow, an open-source framework used to build AI agent/LLM workflows, contains two broken access control flaws in its file handling API. One endpoint allows completely unauthenticated retrieval of image files tied to any flow, while another allows authenticated users to access other users' files via an IDOR, breaking tenant isolation in multi-user deployments. This can expose sensitive data stored within private agent flows.

Pydantic AI's UI adapters (AG-UI and Vercel AI) had a message-sanitization bug where a stale index calculation allowed a crafted client message history to reintroduce an unresolved, client-controlled tool call as if it were the model's own output. This let a remote client trigger execution of registered server tools with attacker-chosen arguments, bypassing model-request guardrail hooks, though approval-gated tools were not affected. The vendor has patched this in 1.107.1 and 2.5.0.

Pydantic AI's protection against SSRF to cloud metadata endpoints can be bypassed when an application allows local/private URL downloads, because the IP blocklist fails to recognize IPv6-encoded forms (IPv4-mapped, 6to4, NAT64) of metadata service addresses. On dual-stack or NAT64-translated networks, this lets an attacker-controlled URL reach the cloud metadata service and potentially steal short-lived IAM credentials. This only affects apps that explicitly opt into 'force_download=allow-local' on URLs influenced by untrusted input; the issue has been patched in version 1.99.0.

The official MCP Ruby SDK fails to expire sessions in its StreamableHTTPTransport, allowing an attacker to repeatedly send initialize requests and accumulate ServerSession objects indefinitely. This can exhaust server memory and cause a denial of service against any MCP server built on this SDK. The issue is fixed in version 0.23.0.

The official MCP Ruby SDK (versions prior to 0.23.0) contains a denial-of-service vulnerability where its stdio transport reads input without a byte limit. A malicious peer (client or server) connected over stdio can send data without a newline terminator to exhaust the host process's memory, crashing or degrading the MCP server or client. This is a straightforward availability issue, not a code-execution or data-exfiltration flaw, and is fixed in 0.23.0.

This is an academic research paper proposing a defensive runtime-verification framework, not a live exploit or observed attack. It identifies a real class of risk: LLM-controlled robot swarms can be manipulated via indirect prompt injection to split a prohibited task across multiple platforms so that no single per-platform guardrail detects the violation. The paper's contribution is a detection/assurance system, not new attack tooling, so this should be tracked as a defensive research reference rather than an active threat.

This is a research paper (not an active exploit) describing an LLM-based agent that automates cloud intrusion investigation using decoy infrastructure. The authors themselves identify, but explicitly do not mitigate in their prototype, a genuine indirect prompt injection risk: attacker-controlled fields in cloud logs (like object keys and user-agent strings) are fed verbatim into agent prompts, creating a log-to-prompt injection channel. Since this is a disclosed, unpatched design gap in a research prototype rather than a live attack, severity is medium.

This is an academic research paper (not an active exploit) demonstrating that LLMs used in Security Operations Centers to interpret system logs can be manipulated via injected text within the logs themselves, causing malicious log entries to be misclassified as benign. The researchers also propose a mitigation: analyzing the LLM's generated explanations for signs of adversarial manipulation. Since this is disclosed research with defensive countermeasures included, it represents a real but currently theoretical/lab-demonstrated risk rather than an in-the-wild threat.

The alibabacloud-rds-openapi-mcp-server binds its MCP endpoint to all network interfaces by default, allowing any network-adjacent attacker to reach and invoke its exposed tools without proper access restriction. This is a configuration/deployment flaw rather than a novel exploit technique, but it can let unauthorized parties trigger RDS-related MCP tools if the server is reachable. Severity is moderate given the CVSS score of 5.8 and the dependency on network exposure and lack of authentication for actual exploitation.

A vulnerability in NanoClaw's MCP Server Approval component allows a local attacker to bypass authorization checks in the createChatSdkBridge.setup function, potentially approving or manipulating MCP server connections without proper consent. The flaw requires local access and has a public exploit available, but the vendor has not yet responded to the disclosure. Severity is moderate due to the local attack vector constraint, though the improper authorization could undermine trust in MCP server approval workflows.

Jan's local API server (through v0.8.4) mishandles trusted host configuration, replacing user-defined allowed origins with a wildcard that reflects any origin while still allowing credentials. This lets a network-adjacent or DNS-rebinding attacker reach the unauthenticated OpenAI-compatible API to run inference, enumerate models, invoke MCP tools, and read cross-origin responses. Fixed in commit 3e1c1e7; upgrade is the primary remediation.

A vulnerability in APIFold's auto-generated MCP server allows unauthenticated attackers to inject arbitrary JSON payloads via a webhook endpoint due to a missing signature validation configuration. These attacker-controlled payloads are stored and later served as trusted resource state to legitimate MCP clients, enabling a form of tool/data poisoning against downstream AI agents. The issue is fixed in a subsequent commit and requires no special access beyond knowledge of a server slug.

AgentGPT versions up to 1.0.0 fail to verify ownership of an agent run before attaching a task to it, letting any authenticated user who guesses or obtains another user's run_id inject tasks into that run. This can corrupt the victim's task history and exhaust their per-run task budget, indirectly driving up their LLM usage costs. It is a classic insecure direct object reference / broken object-level authorization bug rather than a novel agentic attack technique.

This is a research paper (not an active exploit) demonstrating that multi-agent LLM pipelines composed of individually safe models are not safe by default, because the hops between planner, worker, verifier, and synthesizer agents are unmonitored channels an adversary can use to smuggle instructions. The authors show that apparent 'zero attack success' in undefended pipelines was largely an artifact of cloud-provider server-side filtering rather than genuine architectural safety, and propose a training-free gating defense (ChannelGuard) that meaningfully reduces tool-poisoning and prompt-injection success. Severity is moderate: this is a measurement/defense study highlighting a real but already partially-known class of risk, not a novel zero-day.

This is an academic research paper describing a defensive/offensive-research framework (KYA) that automates reconnaissance of AI agents to build target profiles and craft stronger indirect prompt injection attacks. It is not an active exploit or in-the-wild threat, but it formalizes a methodology that could be repurposed by attackers to more efficiently discover and exploit agent weaknesses. Severity is medium because it is a dual-use research contribution rather than a confirmed live attack campaign.

An authenticated n8n user can craft a workflow expression that escapes the VM expression engine's sandbox by abusing array-element access to reach a host built-in object, then pollute its prototype in the main process. This causes a denial of service affecting the entire n8n instance, impacting both self-hosted and cloud deployments. n8n has patched the issue and users should upgrade immediately.