AI Threat AlertCVE-2026-110844: n8n: credential authorization bypass via inline sub-workflows
UNKNOWNn8n before 1.123.83 has an authorization flaw (CWE-863) that lets a user with edit rights on a shared workflow use credentials they have no access to. The user does this by embedding those credentials in nested or inline sub-workflows, such as Workflow Tool or Workflow Retriever definitions. Those definitions run with the workflow owner's credential values. This matters for AI agent deployments because n8n credentials often hold LLM API keys, vector database tokens and SaaS integrations. A low-privileged collaborator can effectively borrow the owner's access, which breaks the separation of duties that credential sharing is meant to enforce. There is no CVSS or EPSS score yet, the CVE is not in CISA KEV, and no public exploit or Nuclei template is known, so the immediate risk is moderate and limited to insiders or compromised editor accounts. Upgrade to n8n 1.123.83 or later, and meanwhile review who holds editor rights on shared workflows and audit workflows that use inline sub-workflow tools.
What is the risk?
Moderate, with the score not yet assigned. Exploitation needs an authenticated account with edit rights on a shared workflow, so it is mostly an insider or compromised-account threat. Attack complexity looks low, because the attacker only has to save a workflow that references a restricted credential. The impact is confidentiality and integrity of whatever systems the credential reaches, such as LLM providers, databases, email, cloud APIs and code repositories. The CVE is not in KEV, EPSS is unavailable and no public exploit is known. Risk rises sharply in multi-user or multi-team n8n instances where credentials are deliberately compartmentalized.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
6 stepsUpgrade n8n to 1.123.83 or later.
Until patched, limit editor rights on shared workflows to trusted users and remove unneeded sharing.
Audit existing workflows for Workflow Tool or Workflow Retriever nodes with inline sub-workflow definitions that reference credentials the editor should not have.
Review execution logs and workflow version history for unexpected credential use by non-owner editors.
Rotate high-value credentials (LLM API keys, database and cloud tokens) if misuse is suspected.
Apply least-privilege scopes to the credentials n8n holds, and monitor the downstream services for anomalous activity.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-110844?
n8n before 1.123.83 has an authorization flaw (CWE-863) that lets a user with edit rights on a shared workflow use credentials they have no access to. The user does this by embedding those credentials in nested or inline sub-workflows, such as Workflow Tool or Workflow Retriever definitions. Those definitions run with the workflow owner's credential values. This matters for AI agent deployments because n8n credentials often hold LLM API keys, vector database tokens and SaaS integrations. A low-privileged collaborator can effectively borrow the owner's access, which breaks the separation of duties that credential sharing is meant to enforce. There is no CVSS or EPSS score yet, the CVE is not in CISA KEV, and no public exploit or Nuclei template is known, so the immediate risk is moderate and limited to insiders or compromised editor accounts. Upgrade to n8n 1.123.83 or later, and meanwhile review who holds editor rights on shared workflows and audit workflows that use inline sub-workflow tools.
Is CVE-2026-110844 actively exploited?
No confirmed active exploitation of CVE-2026-110844 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-110844?
1. Upgrade n8n to 1.123.83 or later. 2. Until patched, limit editor rights on shared workflows to trusted users and remove unneeded sharing. 3. Audit existing workflows for Workflow Tool or Workflow Retriever nodes with inline sub-workflow definitions that reference credentials the editor should not have. 4. Review execution logs and workflow version history for unexpected credential use by non-owner editors. 5. Rotate high-value credentials (LLM API keys, database and cloud tokens) if misuse is suspected. 6. Apply least-privilege scopes to the credentials n8n holds, and monitor the downstream services for anomalous activity.
What systems are affected by CVE-2026-110844?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation platforms, RAG pipelines, LLM tool-calling integrations.
What is the CVSS score for CVE-2026-110844?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsAML.T0053AI Agent Tool InvocationAML.T0083Credentials from AI Agent ConfigurationAML.T0098AI Agent Tool Credential HarvestingCompliance Controls Affected
What are the technical details?
Original Advisory
n8n before 1.123.83 contains an authorization bypass vulnerability that allows shared-workflow editors to use credentials they cannot access by embedding them in nested or tool inline sub-workflows. Attackers can save workflows with Workflow Tool or Workflow Retriever inline definitions referencing restricted credentials, which execute using the workflow owner's credential values.
Exploitation Scenario
A contractor has editor access to a shared n8n workflow that powers an internal AI agent. They cannot use the production CRM and LLM provider credentials owned by another team. They add a Workflow Tool node with an inline sub-workflow that references those credentials and save it. When the agent runs, the sub-workflow executes with the owner's credential values. The contractor uses it to query the CRM, send customer records to an external endpoint, and burn LLM API quota, all without ever being granted access to those credentials.
Weaknesses (CWE)
CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2026-275779.9n8n: Code Injection enables RCE
Same package: n8nCVE-2026-274949.9n8n: security flaw enables exploitation
Same package: n8n