n8n before 1.123.64, 2.29.8, and 2.30.1 contains a stored DOM cross-site scripting vulnerability in the Resource Locator component, which passes the workflow-persisted cachedResultUrl parameter to window.open() without scheme validation. An attacker with workflow creation/editing privileges can craft a workflow with a malicious (e.g., javascript:) scheme in cachedResultUrl; when a victim opens the crafted workflow and interacts with external links, the payload executes in the victim's browser.

n8n versions before 2.30.1 contain a privilege escalation vulnerability in the AI Agents feature where the node-execution tool lacks proper authorization checks. A Project Viewer user can escalate privileges by chatting with an agent that has node tools enabled, executing arbitrary nodes and accessing credential secrets without proper authorization verification.

n8n versions before 1.123.64 contain a server-side request forgery vulnerability in the dynamic-node-parameters endpoints that lack authorization scopes. Authenticated attackers can supply absolute URLs in routing configuration to override baseURL restrictions and make the n8n server issue HTTP requests to arbitrary internal targets when SSRF protection is disabled.

n8n versions before 1.123.64, 2.29.8, and 2.30.1 contain a privilege escalation vulnerability in Enterprise SSO instance-role provisioning. The provisioning path maps an IdP-asserted role claim to an n8n global role but does not prevent assignment of the global:owner role (unlike the token-exchange identity path, which rejects it). An SSO-authenticated user whose instance-role claim resolves to global:owner is provisioned as instance owner, gaining full administrative control over workflows, credentials, users, and instance configuration. Exploitation requires that Enterprise SSO is configured, instance-role provisioning is enabled via N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE (disabled by default), and the attacker controls the instance-role claim value issued by the IdP.

n8n versions before 1.123.64 fail to properly mask custom HTTP header credentials in LLM sub-node execution data, writing plaintext API keys and secrets to workflow execution records. Authenticated users with access to execution data can read exposed header values and credentials that persist in the database and can be exported.

n8n contains a sanitizer bypass vulnerability in the legacy expression evaluator's computed-member handler. An authenticated user with workflow create or modify permissions can craft a malicious expression to bypass the sanitizer and achieve host-level code execution as the n8n process. The legacy expression engine is the default in affected versions. Fixed in n8n 1.123.64, 2.29.8, and 2.30.1.

n8n before 2.29.8 and 2.30.x before 2.30.1 does not enforce shell sandbox restrictions on Linux and Windows in the @n8n/computer-use package (sandboxing was applied only on macOS). Shell commands executed by the tool run without any filesystem or network restrictions, allowing unrestricted access to the host filesystem and network from within the computer-use agent process. This issue only affects deployments where the @n8n/computer-use package is explicitly installed and running; standard n8n installations are not affected.

n8n before 2.28.0 (and before 2.27.4 on the 2.27.x branch) registers the DELETE /${restEndpoint}/test-webhook/:id endpoint before authentication middleware is applied, allowing any unauthenticated network caller who knows a workflow ID to cancel that workflow's active test webhook registration. The impact is limited to disrupting in-progress test sessions; production webhooks, persistent workflow state, and stored data are not affected.

n8n before 2.28.1 contains an information disclosure vulnerability where external secrets are incorrectly resolved in workflow node expressions outside credentials scope. Authenticated project editors can read plaintext external secret values by referencing them in node expressions without requiring explicit secrets access permissions.

n8n before versions 1.123.61, 2.27.4, and 2.28.1 contains a permission bypass vulnerability in external secrets handling caused by a mismatch between the static validation check and the runtime expression engine. An authenticated user with credential create or update permissions but without the externalSecret:list scope can embed external secret references into credentials in forms the static validation does not detect; these references resolve at workflow execution time, exposing secret values the user is not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.