n8n AI Agents Privilege Escalation: CVE-2026-65015 Patch Guide

Direct answer

If you run n8n with AI Agents and node tools enabled, upgrade before treating project-level access as a complete security boundary. CVE-2026-65015 allowed a lower-privileged Project Viewer to use an agent’s node-execution tool without the required authorization check. The affected releases are fixed in n8n 2.29.8 and 2.30.1; use one of those versions or any later release.

The practical lesson is broader than one patch: an agent tool must authorize the requesting user, the target resource, the credentials it would use, and the action it is about to perform. A model’s ability to select a tool is not proof that the caller is allowed to execute it.

What the vulnerability changed

The GitHub Advisory Database and NVD describe a privilege-escalation flaw in n8n’s AI Agents feature. A Project Viewer could chat with an agent configured with node tools, and the node-execution path did not verify that the requesting user had permission to execute the node or access the project credentials.

That distinction matters. This was not merely a prompt-injection demonstration or an LLM hallucination. The security boundary failed at application authorization: the agent could reach execution capabilities with the project’s credentials even though the user’s role was intended to be read-only.

The reported impact depends on the enabled nodes and deployment. A command- or file-capable node could increase the impact from unauthorized workflow actions to command execution on the n8n host. The advisory does not say that every n8n installation was remotely exploitable in the same way; the preconditions include the AI Agents feature, node tools, project membership, and the relevant permissions.

Affected and fixed versions

The safest operational choice is not to pin to the minimum fixed version indefinitely. Upgrade to the latest supported n8n release, test the workflows that use AI Agents, and confirm the resolved version in your deployment inventory.

The n8n release notes for 2.29.8 and 2.30.1 are useful verification points for the patched release lines. The security advisory and NVD provide the vulnerability description and affected-version boundaries; the release pages provide the project’s tagged release evidence.

Immediate response checklist

1. Inventory every n8n instance. Include self-hosted, staging, disaster-recovery, and worker installations.
2. Check the actual running version. Do not rely only on the version in a source repository or container manifest.
3. Upgrade to a fixed supported release. Use 2.29.8 or 2.30.1 as the minimum patch boundary, but prefer the current supported release.
4. Review Project Viewer membership. Identify users who could chat with agents in projects containing node tools.
5. Audit enabled agent tools. Pay special attention to Execute Command, SSH, filesystem, database-write, HTTP, and credential-bearing nodes.
6. Rotate exposed credentials when warranted. If an affected instance may have been used by an unauthorized role, treat credentials available to agent nodes as potentially exposed and follow your incident process.
7. Review execution history and audit logs. Look for unexpected node runs, credential use, external requests, file changes, and unusual activity by read-only users.
8. Temporarily reduce exposure if you cannot patch. Disable the AI Agents module or remove agents from projects accessible to untrusted or lower-privileged users. These are mitigations, not a substitute for upgrading.

Why model approval is not authorization

Agent systems commonly have several separate decisions:

• Can the model propose this tool call?
• Can this user invoke the tool?
• Can this user access the target project, workflow, record, or credential?
• Is this particular operation allowed by policy?
• Does the action require human confirmation?

A safe implementation evaluates the latter four in trusted application code. The language model can help select and explain an action, but it must not become the source of truth for authorization. The n8n issue is a concrete example of what happens when “the agent has this tool” is allowed to stand in for “this caller may use this tool here.”

This is the same boundary emphasized in the AI sandboxing guide: isolation reduces blast radius, but it does not repair a missing authorization check. For portable agent packages, the Agent Plugins 1.0 guide makes a related point: packaging and discovery do not automatically provide permissions or sandboxing.

A safer request flow

Figure 2 — Original Mermaid request-flow visual. The policy gateway is deliberately outside the model and outside the tool implementation’s assumptions.

A useful policy gateway should receive a trusted identity and an explicit action object, not just natural-language text. It should check the project and resource IDs against the authenticated principal, map the requested node to an allowlisted capability, enforce credential scope, validate parameters, and produce an auditable decision before execution.

Controls for n8n administrators

Separate read and write capabilities

Do not expose a broad “run any node” capability to an agent when the workflow only needs a narrow read operation. Split read-only data retrieval from mutations, network calls, credential use, and code execution. Grant the smallest set of nodes required for the workflow.

Treat credentials as action-scoped

A workflow’s credential availability should not automatically imply that every user who can converse with an agent may use those credentials. Prefer credentials restricted to the exact service, environment, endpoint, and operation. Keep production credentials out of development agents unless the use case genuinely requires them.

Protect dangerous nodes

Command execution, SSH, filesystem writes, database mutations, outbound webhooks, and email or payment actions deserve separate controls. Disable them for agents that do not need them. If they are necessary, add explicit confirmation, parameter validation, network restrictions, and post-action audit logging.

Keep authorization server-side

Do not place a role check only in the prompt, system message, skill file, or tool description. Those are useful instructions, not an authorization boundary. Every execution request should be checked by trusted server-side code using the authenticated identity and current policy.

Log denied and successful calls

Record the actor, project, agent, tool, target resource, credential identity, parameters after redaction, policy decision, timestamp, and result. A denied request is still valuable evidence: repeated denials can indicate probing, a compromised account, or a workflow that has been configured with the wrong capabilities.

OWASP’s AI Agent Security Cheat Sheet recommends least-privilege tool scopes, explicit authorization for sensitive operations, high-impact action confirmation, and audit trails. Its guidance is a useful control checklist after the n8n-specific patch is applied. OWASP’s Top 10 for Agentic Applications 2026 provides a broader risk taxonomy for teams formalizing agent security.

A small policy-gateway example

The following Python sketch shows the shape of a pre-execution check. It is intentionally framework-neutral: adapt it to your identity provider, n8n deployment, and policy engine. It does not call n8n and should not be copied as a complete authorization system.

1from dataclasses import dataclass
2
3@dataclass(frozen=True)
4class Action:
5    project_id: str
6    tool: str
7    resource_id: str
8    operation: str
9
10READ_ONLY_TOOLS = {"get_customer", "list_records"}
11
12
13def authorize(user, action: Action) -> bool:
14    if action.tool not in READ_ONLY_TOOLS:
15        return False
16    if action.operation != "read":
17        return False
18    if action.project_id not in user.visible_projects:
19        return False
20    return action.resource_id in user.visible_resources

In production, the policy decision also needs tenant isolation, credential scope, parameter validation, rate limits, an explicit treatment of inherited roles, and tests for every high-impact node. The important property is ordering: authorization happens before the side effect, not after the node reports a result.

How to verify the patch

After upgrading, verify the following in a staging project before reopening access:

• The running version is at or above the fixed boundary.
• A Project Viewer cannot execute a node through an agent when the project policy denies execution.
• A permitted role can execute the intended low-risk node without receiving broader credential access.
• Command, SSH, filesystem, and database-write nodes remain disabled or separately approved where required.
• Denied calls create audit events without leaking secrets into logs.
• Existing workflows still complete with their expected credentials and project scope.
• A regression test covers the exact authorization path, including a lower-privileged user and an agent-enabled project.

Do not validate only by asking the model to refuse. Test the server-side path with a crafted tool call and a real lower-privileged identity in a disposable environment. The security property is that the action cannot execute when policy denies it, regardless of what the model says.

Common mistakes

“We only use internal users”

Internal accounts can be compromised, misconfigured, or granted broader project access than intended. Authorization bugs still matter inside a trusted network.

“The agent is read-only”

A natural-language instruction is not a capability boundary. Inspect the actual nodes, credentials, and execution routes exposed to the agent.

“A sandbox makes this safe”

A sandbox can limit host impact, but it may still expose project data, service credentials, or tenant resources. Combine isolation with identity-aware authorization.

“The patch is installed, so the incident is over”

Patching closes the known code path. It does not answer whether an affected instance was accessed or whether credentials and workflows need review.

FAQ

What is CVE-2026-65015?

It is a high-severity n8n AI Agents privilege-escalation vulnerability involving missing authorization checks around the node-execution tool. NVD lists affected versions below the fixed boundaries and identifies CWE-863, incorrect authorization.

Which n8n versions fix the issue?

The GitHub advisory identifies 2.29.8 and 2.30.1 as fixed releases for the affected version branches. Upgrade to the latest supported release rather than stopping at an old patch if possible.

Can prompt injection exploit this vulnerability?

Prompt injection can be one way to induce an agent to request an action, but the core defect described by the advisory is authorization failure. A correctly enforced server-side policy must deny an unauthorized tool call even when the model requests it.

Should I disable all n8n AI Agents?

Not necessarily. Patch first, inventory tools and credentials, reduce permissions, and test the policy boundary. Disable the feature temporarily when you cannot patch or cannot establish which lower-privileged users can reach dangerous agents.

Conclusion

CVE-2026-65015 is a reminder that agent security is application security with a new execution surface. The model may plan the work, but trusted code must decide whether the authenticated caller may perform the requested action. Patch n8n, review agent-enabled projects, narrow node and credential scope, and test denial paths before restoring broad access.

Sources and visual credits

• GitHub Advisory Database: CVE-2026-65015 / GHSA-x5vx-c2c8-m3w9 — primary advisory record.
• NVD: CVE-2026-65015 — independent government vulnerability record.
• n8n 2.29.8 release — fixed release branch evidence.
• n8n 2.30.1 release — fixed release branch evidence.
• OWASP AI Agent Security Cheat Sheet — least privilege and approval guidance.
• OWASP Top 10 for Agentic Applications 2026 — independent security framework.
• Visual credit: the Mermaid request-flow diagram and version comparison table are original editorial visuals created for this article. No official product screenshot is implied.