mediumCVE-2026-56775

CVE-2026-56775 n8n vulnerability

n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization vulnerability in three mutating evaluation test-run endpoints that authorize state-changing actions using the workflow:read scope instead of the action-appropriate workflow:execute scope. On instances using Advanced Permissions (Enterprise/Cloud) with projects and viewer roles, an authenticated user with the project:viewer role can start new evaluation test runs, cancel in-flight runs, and delete run records for workflows they only have read access to.

Productn8n
CVSS5.3
EPSS0.00176
UpdatedJuly 11, 2026

Quick answer

n8n should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.

Who is affected

Affected versions

  • Review vendor advisory for affected versions.

Fixed versions

  • Apply the latest vendor-supported patched version.

How to fix it

CVE-2026-56775 affects n8n deployments that match the vulnerable version ranges in the official advisory. The risky area is evaluation test-run create, cancel, and delete endpoints, so priority should increase when the affected workflow is internet-facing, shared across projects, or connected to production credentials, databases, webhooks, or downstream APIs. Treat this as a medium-priority remediation item for exposed or multi-user instances because abuse can cross intended workflow, credential, or execution boundaries. The official remediation is to upgrade to n8n 1.123.55, 2.25.7, 2.26.2, or a later vendor-supported release; if an immediate upgrade is not possible, restrict the affected feature and limit access to trusted users until the upgrade is complete.

  1. Inventory all self-hosted n8n instances, containers, and managed environments, including staging systems with shared workflows or public triggers.
  2. Identify whether the installed n8n version is in scope for CVE-2026-56775 and whether evaluation test-run create, cancel, and delete endpoints is enabled or reachable.
  3. Upgrade affected deployments to n8n 1.123.55, 2.25.7, 2.26.2, or a later vendor-supported release, then redeploy workers and restart queue or webhook processes as needed.
  4. If patching must wait, restrict n8n admin, Public API, webhook, and project access to trusted networks and trusted users only.
  5. Review affected workflows for untrusted input paths, shared project permissions, credential sharing, and downstream database or API privileges.
  6. Review n8n audit logs, workflow execution history, webhook access logs, and downstream service logs for unexpected executions or changes.
  7. Rotate credentials, tokens, webhook URLs, or database passwords if logs suggest abuse or if an exposed workflow used privileged secrets.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm every affected n8n deployment reports n8n 1.123.55, 2.25.7, 2.26.2, or a later vendor-supported release or a later supported version.
  • Confirm evaluation test-run create, cancel, and delete endpoints is no longer reachable by users or inputs that should not have that permission.
  • Retest the affected workflow path with a low-privilege account or controlled webhook payload and confirm the previous behavior cannot be reproduced.
  • Rerun a Fixnx scan for public endpoints where webhook, API, or login exposure is relevant.
  • Document the patched version, workflow review outcome, logs checked, and any credential rotations performed.

Trusted references

FAQ

What is affected by CVE-2026-56775?

n8n should be checked against the vendor advisory and trusted references linked on this page.

What should I fix first?

Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.

How do I confirm the fix worked?

Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.

How are Fixnx security risk categories chosen?

Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.