Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Void versions up to 1.3.4 have a path traversal vulnerability (a flaw where attackers can access files outside the intended directory by using special path tricks like absolute paths or file:// URIs) in its AI agent file-reading tools. Network-adjacent attackers (those on the same local network) can inject malicious instructions to read sensitive files like SSH private keys or cloud credentials without needing approval, potentially exposing them to unauthorized access.
The AWS API MCP Server (a tool that lets AI assistants run AWS commands on a user's account) has a security flaw where if the startup process fails to load its security policy rules, the server keeps running but stops checking those rules for the rest of its lifetime. This means an attacker could trick the startup into failing and then execute AWS operations that the policy was supposed to block. The underlying AWS account permissions still apply, but the policy-based restrictions are bypassed.
The AI Copilot – Content Generator plugin for WordPress has a SQL injection vulnerability (a weakness that lets attackers insert malicious database commands) in versions up to 1.5.4 through the 'order[0][dir]' parameter. Authenticated attackers with subscriber-level access or higher can exploit this to extract sensitive information from the database because the plugin fails to properly filter user input before using it in database queries.
n8n's Snowflake node had a SQL injection vulnerability (a type of attack where malicious SQL code is inserted into queries) because it directly inserted expression values into SQL strings instead of using safer methods. This only affects workflows where untrusted data is embedded directly in raw SQL queries.
The PostgresTrigger node in n8n had a SQL injection vulnerability (a type of attack where an attacker tricks an application into running unintended database commands) that allowed authenticated users to execute arbitrary SQL commands on connected PostgreSQL databases. An attacker could exploit this to read or modify all data in the database.
n8n's JavaScript task runner had a vulnerability where all users' Code nodes (executable code blocks within n8n workflows) shared the same module cache (a storage area for reusable code libraries), allowing one user to poison it (corrupt or modify cached code) and affect other users' executions. This is a cross-tenant isolation break (where data from different users isn't properly separated) but not a sandbox escape (breaking out of a restricted environment) or RCE (remote code execution, where attackers run commands on systems they don't own).
n8n, a workflow automation tool, had a security flaw where custom HTTP headers (additional data sent with web requests) in LLM node credentials were hidden in the user interface but were actually saved in plaintext into execution data (the record of what happened when a workflow ran). This meant any authenticated user who could view that execution data could see API keys and other secrets stored in those headers. Since execution data can be saved to a database and exported, these secrets could remain exposed long after the workflow finished running.
A vulnerability in n8n (a workflow automation tool) allows anyone on the network to cancel another user's active test webhook without logging in, because an endpoint wasn't protected by authentication checks. The impact is limited to disrupting testing sessions, not production systems or stored data.
The GraphQL node in n8n (a workflow automation tool) had a security flaw where it didn't properly enforce "Allowed HTTP Request Domains" restrictions on certain types of credentials (authentication methods like API keys and passwords), even though the regular HTTP Request node did. This meant that someone with permission to create workflows could potentially steal these restricted credentials by sending them to a server they control.
The shell tool in n8n's computer-use package failed to enforce sandbox restrictions (security boundaries that limit what a program can access) on Linux and Windows, allowing shell commands to run without limits on filesystem and network access. This vulnerability only affects deployments that explicitly install the computer-use package, not standard n8n installations. An attacker with access to the system could potentially read files, modify data, or communicate over the network from within the agent process.
In n8n (a workflow automation tool), authenticated users can upload files repeatedly to bypass upload limits, causing temporary files to pile up on the server's disk until the automatic cleanup runs, potentially filling the disk completely. This happens because the system doesn't properly track files already stored in the shared temporary directory.
An authenticated user with workflow creation permissions in one project could bypass authorization checks to assign workflows to folders in other projects they don't have access to. The workflow stays in the attacker's project and isn't visible elsewhere, but the target project's folder structure is logically corrupted at the database level. This vulnerability only affects n8n instances that have multi-project and folder support enabled.
A security flaw in n8n allowed authenticated users with editor access to read external secrets (sensitive configuration values stored outside the main system) through workflow node expressions (code blocks in automation workflows), even though they shouldn't have had permission to do so. This only affected n8n instances that had the external secrets feature enabled.
n8n's legacy MySQL v1 node has a SQL injection vulnerability (a type of attack where malicious SQL code is inserted into a query) in its executeQuery operation because it directly inserts user input into SQL queries without parameterization (a safer method that treats input as data, not code). If a workflow receives input from an external source like a webhook and uses that input in a MySQL v1 query, an attacker could execute arbitrary SQL commands and access or modify the database.
n8n had a security flaw where the system that checks permissions (static validation) didn't match the system that runs code (runtime expression engine), allowing authenticated users to sneak external secret references into credentials they weren't supposed to access. This could expose secret values at workflow execution time to users who lacked the proper authorization, but only affects instances with an external secrets provider configured and Advanced Permissions enabled.
A security flaw in n8n's computer-use component allowed attackers to bypass path confinement (a security boundary that restricts file searches to a specific directory) by using specially crafted search patterns, potentially exposing file names and contents from anywhere on the system. This affected any deployment where an attacker could control the search input to the file-search tool.
n8n, a workflow automation tool, has a vulnerability where authenticated users can exploit the VM expression engine (a system that processes custom code in workflows) through prototype pollution (a technique that modifies how objects behave by changing their base templates) to crash the application, affecting both self-hosted and cloud versions.
A vulnerability in n8n's Edit Fields (Set) node allowed authenticated users to create fields with names matching inherited methods, which corrupted shared global data in the Node.js process (prototype pollution, a technique where an attacker modifies object prototypes to affect all instances). This broke the authentication system and caused the entire n8n instance to reject all authenticated requests until restarted, affecting all users.
The n8n Edit Image node failed to validate its output format parameter before passing it to an image library, allowing an authenticated user to write arbitrary files anywhere on the n8n instance (a vulnerability called format injection, where unvalidated input to a file operation bypasses normal restrictions). This could let someone with workflow access overwrite or create files they shouldn't be able to touch.
n8n, a workflow automation tool, had a security flaw where someone with editor access to a shared workflow could steal credentials (login information) they weren't supposed to access by hiding them inside an Execute Sub-workflow node's inline JSON (a way to embed workflow code as data). The vulnerability only worked if workflow sharing was enabled and the attacker knew the credential's ID.
Fix: The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later. The fix introduces an optional "Query Parameters" field that allows values to be bound via positional placeholders rather than interpolated into the query string. If upgrading is not immediately possible, temporary mitigations include: restrict workflow creation and editing permissions to fully trusted users only; audit existing workflows using the Snowflake executeQuery operation to ensure no expression resolving to externally-controlled data is embedded directly in a raw SQL query string; and restrict network access to any webhook or trigger endpoints that feed data into Snowflake executeQuery nodes. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.67, 2.31.5 and 2.32.1. Users should upgrade to these versions or later. If upgrading is not immediately possible, temporary mitigations include: restricting n8n instance access to fully trusted users only, disabling the PostgresTrigger node by adding `n8n-nodes-base.postgresTrigger` to the `NODES_EXCLUDE` environment variable, and ensuring PostgreSQL credentials are configured with minimum required privileges and do not use SUPERUSER roles. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Upgrade to n8n version 1.123.67, 2.31.5, or 2.32.1 or later. If upgrading is not immediately possible, administrators can temporarily: restrict instance access to fully trusted users only; disable built-in and external module access in Code nodes by unsetting `NODE_FUNCTION_ALLOW_BUILTIN` and `NODE_FUNCTION_ALLOW_EXTERNAL` environment variables; or use external runner mode with a dedicated runner per user or project. The source notes these workarounds do not fully remediate the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can: restrict access to execution data to fully trusted users only; avoid configuring custom headers in LLM node credentials and use alternative authentication mechanisms instead; and rotate any API keys or secrets that may have been stored as custom header values in affected credentials. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Users should upgrade to the patched version once available. As temporary workarounds if upgrading isn't possible: restrict network access to n8n to trusted users only, or place n8n behind a reverse proxy or firewall (a security layer that filters traffic) requiring authentication before API access. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can temporarily: restrict workflow creation and editing permissions to fully trusted users only, restrict credential sharing to fully trusted users only, and audit credentials with domain restrictions for unexpected sharing relationships. However, these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.29.8 and 2.30.1. Users should upgrade to one of these versions or later. The fix adds sandbox enforcement on Linux via bubblewrap and disables the shell tool entirely when a working sandbox cannot be established. An explicit opt-out flag (`--dangerously-disable-shell-sandbox`) is available for deployments that require unsandboxed shell access. As temporary workarounds if upgrading is not immediately possible, administrators should disable or avoid deploying the computer-use package on Linux or Windows hosts, and restrict access to the n8n instance to fully trusted users only.
GitHub Advisory DatabaseFix: Users should upgrade to the patched version once available. If upgrading immediately is not possible, administrators can temporarily: restrict n8n access to fully trusted users only, set `uploadMaxFileSize` to a low value to limit individual upload size, and monitor and alert on disk usage in the n8n temporary upload directory. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n version 2.28.0. Users should upgrade to this version or later to remediate the vulnerability. As a temporary workaround, administrators should restrict project membership and workflow creation permissions to fully trusted users only, though this does not fully remediate the risk and should only be used as a short-term measure.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.27.4 and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict project membership to fully trusted users only and avoid granting editor access to projects on instances where external secrets are configured, though these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can disable the MySQL node by adding `n8n-nodes-base.mySql` to the `NODES_EXCLUDE` environment variable, restrict access to workflows using the MySQL v1 node with the executeQuery operation, ensure webhook endpoints require authentication, or migrate affected workflows to use the MySQL v2 node which uses parameterized queries. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict credential creation and update permissions to fully trusted users only and audit existing credentials for unexpected external secret references, though these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later. If immediate upgrading is not possible, the source mentions temporary workarounds: restrict n8n access to fully trusted users only, disable or remove AI agent workflows using the computer-use package until patching, and ensure the n8n process runs under a dedicated low-privilege user account (a restricted account with minimal permissions) to limit accessible files. The source notes these workarounds do not fully fix the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. As temporary workarounds if upgrading is not immediately possible, administrators should restrict n8n instance access to fully trusted users only, or disable the VM expression engine if an alternative is available for your deployment. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n instance access to fully trusted users only, disable or restrict workflow creation and execution permissions for untrusted users, and monitor for unexpected process-wide HTTP 500 errors and restart the process promptly if they occur. However, these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n instance access to fully trusted users only, or disable the Edit Image node by adding `n8n-nodes-base.editImage` to the `NODES_EXCLUDE` environment variable. The source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can temporarily: restrict workflow sharing to trusted users only and avoid giving Editor access on workflows using sensitive credentials; audit shared workflows for Execute Sub-workflow nodes with Source = "Parameter" and review their inline workflow definitions for unexpected credential references; and restrict network egress from the n8n instance to prevent connections to attacker-controlled endpoints. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory Database