GHSA-2XGM-WC4G-5JVG
Vulnerability from github – Published: 2026-07-22 22:24 – Updated: 2026-07-22 22:24Impact
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.28.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59253"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:24:43Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\nAn 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.\n\nThe workflow itself remains in the attacker\u0027s project and is not visible to the target project\u0027s members. The target project\u0027s 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\u0027s folder structure at the database level.\n\nThis issue affects instances with multi-project and folder support enabled.\n\n## Patches\nThe issue has been fixed in n8n version 2.28.0. Users should upgrade to this version or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict project membership and workflow creation permissions to fully trusted users only.\n\nThis workaround does not fully remediate the risk and should only be used as a short-term mitigation measure.",
"id": "GHSA-2xgm-wc4g-5jvg",
"modified": "2026-07-22T22:24:43Z",
"published": "2026-07-22T22:24:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-2xgm-wc4g-5jvg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59253"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.28.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/n8n-improper-authorization-in-workflow-assignment-to-folders"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "n8n: Improper Authorization Allows Authenticated Users to Assign Workflows to Folders in Other Projects"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.