n8n: Prototype Pollution via Dot-Notation Field Names Leads To Instance-Wide Denial of Service
n8n
- Severity
- High, CVSS 7.1
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- Record
- GHSA-xwx6-jjhv-84p8
- Affects
- n8n
- Known exploited
- Not listed in the CISA Known Exploited Vulnerabilities catalog
- Published
- Record first published by the source
- July 22, 2026
- Source last modified
- July 22, 2026
Description
Impact
The Edit Fields (Set) node assigned output fields through a dot-notation path setter without restricting the field name, so an authenticated user could name a field after an inherited built-in method path and corrupt a shared global in the main Node.js process. Because that global was used on the request-authentication path, the instance then failed every authenticated request, causing a instance-wide denial of service for all users until the process was restarted.
Patches
The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. 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. - Disable or restrict workflow creation and execution permissions for untrusted users. - Monitor for unexpected process-wide HTTP 500 errors and restart the process promptly if they occur.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Description quoted from the GitHub Advisory Database.
Who is affected
n8n is a tool for automating tasks by connecting apps and services into step-by-step workflows. This flaw is in the Edit Fields (Set) building block, which sets the data fields a workflow passes along. A user who can sign in could give a field a specially chosen name that breaks a shared part of the running program. After that, n8n rejects every signed-in request, so it stops working for all users until the program is restarted. This flaw is fixed in n8n versions 1.123.67, 2.31.5 and 2.32.1. This flaw is rated High.
What to do
- The person who installed or runs n8n for your organization should handle this. If an IT provider or vendor runs it for you, send them this advisory and ask when the update will be done.
- Update n8n to version
1.123.67,2.31.5or2.32.1, or a later version. - If you cannot update right away, restrict access to n8n to fully trusted users only, and disable or restrict permission to create and run workflows for untrusted users.
- Watch for unexpected server errors (error 500) affecting the whole program, and restart n8n promptly if they occur.
- These temporary steps do not fully remove the risk, so plan the update soon.
Analysis written from the source record as of July 22, 2026 and reviewed before publishing.