CVE-2026-59253: n8n: Improper Authorization Allows Authenticated Users to Assign Workflows to Folders in Other Projects

During workflow creation, a crafted request payload can name a folder that belongs to a different project (CWE-639, authorization bypass through a user-controlled key). n8n did not check that the creator has access to that folder, so the new workflow was linked to it.

The effect is small. The workflow stays in the attacker's own project, and the target project's members do not see it. Folder ownership does not change, and the advisory states that no data from the target project is exposed. What breaks is the integrity of the target project's folder structure at the database level: a foreign workflow record points at its folder. The CVSS 4.0 vector reflects that, with low integrity impact and nothing for confidentiality or availability.

The attacker needs a low-privileged account that can create workflows, and the instance must have multi-project and folder support enabled. Teams that run a single project are not affected in practice.

Affected: n8n below 2.28.0. The 1.x line is not listed in this entry. The issue applies to instances with multi-project and folder support enabled, where users have workflow create rights in one project but not another.

Check the version:

npm ls n8n

For Docker, check the image tag or the version in the UI.

Upgrade to n8n 2.28.0 or later. For an npm install, run npm install [email protected].

If you cannot upgrade yet, the only mitigation in the advisory is to restrict project membership and workflow creation permissions to fully trusted users. The advisory says this does not fully remediate the risk and is a short-term measure.

The sources give no log signature. In the n8n database, look for workflows whose project differs from the project of the folder they sit in. Any such mismatch is the footprint of this flaw. Review workflow-creation requests to the API that carry a folder identifier for a project the requesting user does not belong to.

Impact

An authenticated user with permission to create workflows in one project could bypass project/folder authorization boundaries during workflow creation. By supplying a crafted request payload, the user could associate a newly created workflow with a folder belonging to a different project they do not have access to.

The workflow itself remains in the attacker's project and is not visible to the target project's members. The target project's folder ownership is not changed, and no data from the target project is exposed. The impact is limited to a logical integrity violation of the target project's folder structure at the database level.

This issue affects instances with multi-project and folder support enabled.

Patches

The issue has been fixed in n8n version 2.28.0. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict project membership and workflow creation permissions to fully trusted users only.

This workaround does not fully remediate the risk and should only be used as a short-term mitigation measure.