CVE-2026-118644 in n8n
Summary
by MITRE • 10/28/2026
n8n before 2.41.5 and 2.42.x before 2.42.2 passes a failed workflow's full execution context, including the identity of the user who started the run, to the configured error workflow. A project editor can set a colleague's workflow settings.errorWorkflow to an error workflow they own, inherit the colleague's identity when that workflow fails, and resolve the colleague's per-user dynamic credential secrets.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in n8n versions prior to 2.41.5 and version 2.42.x before 2.42.2 represents a critical flaw in how execution context is propagated during workflow error handling mechanisms. Specifically, the application fails to sanitize or restrict the data passed from a failed primary workflow to its designated error-handling workflow. This design oversight allows the full execution context of the failing run to be exposed, which includes sensitive metadata such as the identity of the user who initiated the original process. In automated integration platforms like n8n, workflows often interact with external services using credentials that are scoped to specific users or projects to enforce least-privilege access controls and maintain audit trails. By leaking this context, the system inadvertently grants downstream components visibility into identities and session states that should remain isolated within the scope of the original execution thread.
This technical flaw enables a sophisticated privilege escalation attack vector where an attacker with editor permissions on a project can manipulate workflow configurations to exploit these leaked contexts. An adversary can configure their own error workflow by setting it as the target for another colleague's workflow through the settings.errorWorkflow parameter. When the victim's workflow encounters an error, instead of failing silently or handling the exception within its own isolated context, n8n passes the entire execution state—including the victim's user identity—to the attacker-controlled error workflow. This mechanism effectively allows the attacker to inherit the victim's identity for the duration of the error processing logic, bypassing standard authentication and authorization checks that would normally apply if the action were initiated directly by the attacker.
The operational impact of this vulnerability is severe, particularly regarding data confidentiality and integrity within multi-tenant or team-based environments. The most significant consequence arises from the ability to resolve per-user dynamic credential secrets. Since n8n supports credentials tied to specific users for secure API access, an attacker leveraging this flaw can trigger the resolution of these secrets using the victim's identity. This means that sensitive authentication tokens, API keys, and other confidential connection details belonging to a colleague become accessible to the attacker through their own error workflow logic. Such exposure compromises not only the individual user's security posture but also potentially affects all external services those credentials are authorized to access, leading to potential data breaches or unauthorized actions performed under the guise of the victim.
From a classification perspective, this issue aligns with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, as well as CWE-798, involving the use of hard-coded credentials if dynamic secrets are improperly managed in memory during propagation. In terms of attack behavior, it maps to MITRE ATT&CK techniques related to Credential Access and Privilege Escalation, specifically illustrating how application logic flaws can be leveraged to bypass intended access controls. The vulnerability highlights a common risk in workflow automation tools where the separation between execution contexts is not strictly enforced during exception handling paths, allowing state leakage that undermines security boundaries.
Mitigation strategies must prioritize immediate patching of n8n instances to version 2.41.5 or later for the stable branch and version 2.42.2 or later for the development branch, as these releases address the context propagation issue in error workflows. Administrators should also review existing workflow configurations to identify any custom error handlers that might have been configured by users with editor privileges, ensuring they do not rely on leaked execution contexts for sensitive operations. Implementing stricter input validation and output sanitization for all data passed between workflow nodes is essential, particularly when handling exceptions where the context may include user-specific metadata. Furthermore, organizations should enforce principle of least privilege by limiting who can configure error workflows within projects, restricting this capability to administrators or security-focused roles rather than general editors. Regular audits of credential usage and monitoring for unusual patterns in API calls originating from error-handling logic can also help detect potential exploitation attempts before significant damage occurs.