## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
Update n8n-mcp to 2.57.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scann8n-MCP: Incorrect authorization can expose default-scope workflow version backups in multi-tenant HTTP mode affects n8n-mcp (npm). Severity is medium. ## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| n8n-mcpnpm | <=2.57.3 | 2.57.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate n8n-mcp to 2.57.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scann8n-MCP: Incorrect authorization can expose default-scope workflow version backups in multi-tenant HTTP mode affects n8n-mcp (npm). Severity is medium. ## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| n8n-mcpnpm | <=2.57.3 | 2.57.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard