Per-User Credential Theft via Error-Workflow Execution Context Inheritance
Summary
Impact
When a workflow fails, n8n runs the workflow named in its error-workflow setting and hands it the failed run's execution context, including the carrier that binds the run to the user who started it. A project editor could point a colleague's workflow at an error workflow they own, inherit...
Affected packages
| Ecosystem | Package | Affected | Fixed |
|---|---|---|---|
| npm | n8n |
< 2.42.2 |
>= 2.42.2 |
| npm | n8n |
< 2.41.5 |
>= 2.41.5 |
Original description The description as published by the source.
Impact
When a workflow fails, n8n runs the workflow named in its error-workflow setting and hands it the failed run's execution context, including the carrier that binds the run to the user who started it. A project editor could point a colleague's workflow at an error workflow they own, inherit the colleague's identity in their own execution, and resolve that user's per-user credential secrets. The error workflow now receives only non-identity fields.
Patches
The issue has been fixed in n8n versions 2.42.2 and 2.41.5. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict n8n instance access to fully trusted users only.
- Audit team project memberships and remove editor access from any users who are not fully trusted.
- Review all active workflows and audit the
settings.errorWorkflowfield for unexpected values. - Disable the dynamic credentials feature if it is not required.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Source: GitHub Repository Security Advisories (Game のスタック) GitHub Advisory OSV
References
- GITHUB_REPO_ADVISORY n8n-io/n8n