CVE-2026-42227
Information Disclosure in n8n Workflow Automation
Publication date: 2026-05-04
Last updated on: 2026-05-06
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| n8n | n8n | to 1.123.32 (exc) |
| n8n | n8n | 2.18.0 |
| n8n | n8n | From 2.17.0 (inc) to 2.17.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects the n8n workflow automation platform in versions prior to 1.123.32, 2.17.4, and 2.18.1. An authenticated user with a valid API key scoped to variable:list could exploit the public API variables endpoint by supplying an arbitrary projectId query parameter. This allowed the user to read variables from projects they were not a member of because the system queried the variables repository directly without checking project membership, bypassing the authorization controls.
The issue only impacts licensed enterprise or team deployments that have multiple projects and the variables feature enabled. It has been fixed in the specified patched versions.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an authenticated user with a valid API key to read variables from projects they are not a member of by bypassing project membership checks. If these variables contain sensitive information such as credentials or tokens, unauthorized access could lead to data exposure.
Such unauthorized access to sensitive data could potentially impact compliance with data protection standards and regulations like GDPR and HIPAA, which require strict controls on access to personal and sensitive information.
Organizations using affected versions should rotate any sensitive credentials or tokens stored in variables to mitigate risks.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves an authenticated user with a valid API key scoped to variable:list accessing variables from projects they are not a member of by supplying an arbitrary projectId query parameter to the public API variables endpoint.
To detect exploitation attempts on your network or system, you can monitor API requests to the variables endpoint that include a projectId parameter different from the user's authorized projects.
For example, you can search your web server or application logs for requests matching the pattern: GET /variables?projectId=some_id where the projectId does not belong to the authenticated user.
A sample command to search logs (assuming logs are in access.log) could be:
- grep -i 'GET /variables?projectId=' access.log
Further analysis would be needed to correlate the projectId parameter with the authenticated user's authorized projects to confirm unauthorized access attempts.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized access to variables from projects a user does not belong to. If these variables contain sensitive information such as credentials or tokens, this could result in exposure of confidential data.
Such exposure could compromise security by allowing attackers or unauthorized users to misuse sensitive information, potentially leading to further breaches or unauthorized actions within the affected environment.
It is recommended to rotate any sensitive credentials or tokens stored in variables if they might have been exposed due to this vulnerability.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade n8n to one of the patched versions: 1.123.32, 2.17.4, or 2.18.1.
If variables were used to store sensitive information such as credentials or tokens, rotate those credentials immediately.
Ensure that only authorized users have API keys scoped to variable:list, and review project membership and access controls.