GHSA-cqr2-h44g-v75v: Npm/n8n vulnerability
Impact
The endpoints /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members checked only that the caller could manage the role type, not that they could see the project named in the request. A user holding role-management permission could therefore name any project on the instance and read back its members' names and email addresses. The patch adds a project-access check to both routes, hiding projects the caller cannot see and returning not-found for a project it cannot list.
Patches
The issue has been fixed in n8n versions 2.38.2 and 2.37.7. 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 and revoke any custom global roles that carry the role:manageProject scope, limiting that scope to fully trusted users only.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/n8nto a version that resolves this vulnerability.Fixed in 2.37.7 - Upgrade
Upgrade
npm/n8nto a version that resolves this vulnerability.Fixed in 2.38.2 - Upgrade
Upgrade
n8nto a version that resolves this vulnerability.Fixed in 2.38.2 - Upgrade
Upgrade
n8nto a version that resolves this vulnerability.Fixed in 2.37.7 - Compensating control
Audit and revoke any custom global roles that carry the `role:manageProject` scope, limiting that scope to fully trusted users only.
- Compensating control
Restrict n8n instance access to fully trusted users only.
Event History
Frequently Asked Questions
Who can exploit this issue, and what information can they obtain?
A user with permission to manage the relevant role type, including a custom global role carrying the role:manageProject scope, can exploit it. They can name projects they cannot access and retrieve those projects' members' names and email addresses.
Which versions contain the fix?
The issue is fixed in n8n 2.38.2 and 2.37.7. Upgrade to one of those versions or later.
What can administrators do if they cannot upgrade immediately?
Restrict instance access to fully trusted users and audit custom global roles for the role:manageProject scope. Revoke that scope from users who are not fully trusted; these measures are temporary and do not fully remediate the issue.
How does the patched behavior prevent unauthorized project-member lookup?
The patched routes check whether the caller has access to the requested project. Projects the caller cannot see are hidden, and requests for projects they cannot list return not found.