n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, an authenticated user with permission to create or modify workflows could pollute the sandbox used by the Merge nodes SQL Query mode. Because the sandbox context was cached and reused across all workflow executions on the instance, prototype mutations introduced by one users workflow persist into subsequent Merge SQL executions belonging to other users or projects. This allowed a low-privileged attacker to intercept workflow data processed by other users on the same instance. This issue only affects multi-user n8n instances where more than one user has permission to create and execute workflows containing the Merge node in SQL Query mode. This vulnerability is fixed in 2.25.7 and 2.26.2.
Weakness
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| N8n | N8n | * | 2.25.7 (excluding) |
| N8n | N8n | 2.26.0 (including) | 2.26.2 (excluding) |
Extended Description
Data can “bleed” from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. In the case of Servlets, developers sometimes do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result is that developers use Servlet member fields in such a way that one user may inadvertently see another user’s data. In other words, storing user data in Servlet member fields introduces a data access race condition.