Threat Library
Agent-to-agent threats first — conventional coverage one click away.
Browse by hub: AI agent threats · Conventional watchlist · OWASP Agentic Top 10
Showing 20 of 249 threats
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.
The @n8n/computer-use file-search tool used by AI agent workflows in n8n failed to properly confine search patterns to a designated base directory, allowing crafted inputs to escape the sandbox and read arbitrary files accessible to the daemon's OS user. This affects any deployment where an untrusted actor or agent-driven input could influence the search query, resulting in local file disclosure outside the intended scope. The issue has been patched in n8n 2.31.5 and 2.32.1.
A validation/runtime mismatch in n8n's workflow automation platform lets an authenticated user without the `externalSecret:list` permission smuggle external secret references into credential fields that bypass static checks but still resolve at execution time. This allows unauthorized users to indirectly exfiltrate secret values they should not have access to, undermining the platform's Advanced Permissions model. Severity is moderate since it requires authenticated access with credential-editing rights and a specific configuration (external secrets provider plus Advanced Permissions enabled).
A legacy MySQL node in the n8n workflow automation platform builds raw SQL queries by directly interpolating expression-evaluated values instead of using parameterized queries. When such a workflow is triggered by an externally reachable input like a webhook, an attacker can inject SQL to read, modify, or delete data via the configured database credentials.
A vulnerability in n8n allows authenticated users with only project editor access to read plaintext external secrets by referencing them directly in node expressions, bypassing the intended secrets access permission model. This affects instances that have the external secrets feature configured, potentially exposing sensitive credentials to users who should not have access to them. The issue has been patched in n8n 2.27.4 and 2.28.1.
A logic flaw in n8n's workflow automation platform allows an authenticated user to craft a request that associates their newly created workflow with a folder belonging to a different, unauthorized project. The workflow itself stays private to the attacker's project and no cross-project data is exposed, limiting the impact to a database-level integrity issue in folder structure. This is a traditional web application IDOR/authorization bug rather than an AI-agent-specific exploit, though n8n is increasingly used to orchestrate AI agent workflows.
An authenticated n8n user can repeatedly abuse the data-table file upload endpoint to bypass per-request quota checks, causing temporary files to accumulate on disk faster than cleanup can remove them. This can exhaust host disk space, leading to a denial-of-service condition affecting the n8n instance and potentially other services on the same host. This is a genuine, moderate-severity resource exhaustion flaw rather than a novel agentic-AI attack, but it is directly relevant to n8n's growing role as an orchestration layer for AI agent workflows.
Researchers found that over 42% of apps on LG's webOS smart TV store secretly embed residential proxy SDKs, allowing unknown third parties to route their internet traffic through consumers' TVs without clear consent. LG has announced it will ban apps that turn smart TVs into always-on residential proxy nodes. This practice exposes users' home IP addresses and bandwidth to potentially malicious or anonymized traffic routed by unknown actors.
Upbound Group, the parent company of fintech lease-to-own provider Acima, disclosed that attackers who stole customer data from its systems used that information to fraudulently generate $13 million in Acima lease agreements. The incident highlights how stolen PII and account data can be weaponized for downstream financial fraud beyond the initial breach.
Multiple Siemens industrial and engineering software products bundling the IAM Client SDK are affected by an untrusted/unquoted search path vulnerability that could allow an authenticated local attacker to escalate privileges. Siemens has released patched versions for most affected products and recommends updating as soon as possible, with fixes pending for remaining products.
The n8n computer-use package's shell tool was supposed to restrict filesystem and network access via a sandbox, but this enforcement only worked on macOS. On Linux and Windows, any command executed by the agent's shell tool ran with full, unrestricted access to the host filesystem and network, defeating the intended containment. This is only relevant to deployments that explicitly enable the computer-use package.
n8n's GraphQL node failed to enforce the 'Allowed HTTP Request Domains' restriction that is applied to HTTP-based credentials, unlike its HTTP Request node counterpart. An authenticated user with workflow editing rights could exploit this gap to point the GraphQL node at an attacker-controlled server and exfiltrate credentials that were supposed to be domain-restricted. This is a moderate-severity authorization bypass affecting multi-tenant or shared-credential n8n deployments, fixed in recent releases.
A REST endpoint in the n8n workflow automation platform is registered before authentication middleware is applied, letting any unauthenticated network caller cancel another user's active test webhook if they know the workflow ID. The impact is limited to disrupting in-progress test sessions; production webhooks and stored data are unaffected. This is a low-complexity availability/harassment issue rather than a data breach or compromise vector.
n8n workflows using LLM sub-nodes (OpenAI, Anthropic, Lemonade) with custom HTTP header credentials write those header values in plaintext into stored execution data, even though the n8n UI masks them. Any user with access to execution logs or exports can recover API keys and secrets, which may persist in the database well after the workflow run completes.
n8n's JavaScript task runner shared a single module cache across all users' Code-node executions on the same instance, allowing one user to poison a cached module and affect other users' automations. This is a multi-tenant isolation failure rather than a sandbox escape or remote code execution, but it can compromise confidentiality, integrity, or availability of other tenants' workflow logic.
The n8n PostgresTrigger node, commonly used by AI agent and automation workflows to connect to PostgreSQL databases, failed to properly escape user-supplied identifier fields (channel, function, trigger names) before embedding them in SQL statements. This allowed authenticated n8n users to inject arbitrary SQL, gaining full read/write access to the connected database using the workflow's configured credentials. The issue has been patched; the main risk is privilege escalation by low-trust authenticated users within multi-tenant or shared n8n deployments.
The n8n Snowflake node's Execute Query operation directly interpolates workflow expression values into raw SQL strings instead of using parameterized queries, creating a classic SQL injection risk. Exploitation requires a workflow author to have already wired untrusted external data (e.g., from a webhook) into the raw query, so it is a secondary/contributing weakness rather than a directly remotely exploitable flaw on its own. This is a traditional application security bug in an automation tool that is increasingly used as an agentic tool-calling backend, not an AI-specific attack technique.
LiteLLM's Skills feature fails to validate file paths when extracting uploaded ZIP archives, allowing an authenticated user with access to the Skills API to write files outside the intended directory. This 'zip-slip' style vulnerability could lead to arbitrary file write and potentially remote code execution depending on server configuration. The issue is fixed in version 1.83.7-stable.
This advisory is a withdrawn duplicate of GHSA-9r8p-h6cc-6qhm, describing an n8n bug where the full Google Service Account PEM private key was mistakenly written into the JWT header's 'kid' field instead of a key identifier. Since JWT headers are only Base64-encoded (not encrypted), anything that logs or inspects the token could recover the private key, allowing impersonation of the associated Google Cloud service account. Impact is limited to n8n instances configured with Google Service Account credentials, and the issue is fixed in versions 1.123.64, 2.29.8, and 2.30.1.