CVE-2026-56778: 
NixOS 취약성 분석 및 완화

CVE-2026-56778 is an authorization bypass vulnerability in n8n's Public API execution retry endpoint, where the endpoint incorrectly uses the workflow:read scope for authorization instead of the required workflow:execute scope. This allows an authenticated user with read-only access to a shared workflow to trigger workflow re-executions via the Public API, bypassing the intended permission boundary. Affected versions include n8n before 2.25.7 and 2.26.x before 2.26.2 (Node.js package). The vulnerability was published on July 8, 2026, with patches available the same day. It carries a CVSS v4.0 base score of 5.3 (Medium) and a CVSS v3.1 base score of 6.4 (Medium) (n8n Advisory, Github Advisory).

The root cause is classified as CWE-863 (Incorrect Authorization): the Public API handler for the execution retry endpoint performs an authorization check against the workflow:read scope rather than the workflow:execute scope, meaning any user who can read a shared workflow is implicitly authorized to retry its executions. Exploitation requires only a valid authenticated session and read-level access to a workflow shared with the attacker's account or project — no elevated privileges or user interaction are needed. The attack is conducted over the network via a standard API call to the retry endpoint, making it straightforward to exploit in multi-user or multi-project n8n deployments (n8n Advisory, Github Advisory).

Successful exploitation allows an authenticated attacker with only read-only access to trigger re-execution of shared workflows, violating the intended separation between read and execute permissions. This can result in unauthorized actions performed by the workflow (e.g., sending data, modifying external systems, or consuming resources), with low confidentiality and integrity impact on both the vulnerable and subsequent systems. Availability is not directly impacted, but repeated unauthorized executions could cause unintended side effects in integrated services or data pipelines (n8n Advisory, Github Advisory).

1. Reconnaissance: Identify an n8n instance running a vulnerable version (before 2.25.7 or 2.26.x before 2.26.2) that has workflow sharing enabled across users or projects.
2. Obtain read-only access: Authenticate to the n8n instance using an account that has been granted read-only (workflow:read) access to one or more shared workflows.
3. Identify a target execution: Use the Public API or n8n UI to enumerate past executions of the shared workflow, noting a valid execution ID to retry.
4. Send retry request: Issue an authenticated HTTP POST request to the Public API execution retry endpoint (e.g., POST /api/v1/executions/{executionId}/retry) using the read-only account's API key or session token.
5. Bypass authorization: Because the endpoint checks only workflow:read scope, the request is accepted and the workflow execution is triggered, despite the account lacking workflow:execute permission.
6. Achieve unauthorized execution: The workflow runs again, potentially performing actions (data writes, external API calls, notifications) that the attacker was not authorized to initiate (n8n Advisory).

• Logs: n8n API access logs showing POST requests to the execution retry endpoint (e.g., /api/v1/executions/{id}/retry) from accounts with only read-level permissions; repeated retry requests from the same user account in a short timeframe.
• Application Behavior: Workflow executions appearing in the execution history that were not triggered by users with execute permissions; unexpected workflow runs outside of normal scheduling or trigger patterns.
• Network: API calls to the n8n Public API retry endpoint originating from unusual source IPs or at unusual times, particularly from accounts not expected to trigger executions.

Upgrade n8n to version 2.25.7 (for the 2.25.x branch) or 2.26.2 (for the 2.26.x branch) or later, as these releases contain the fix for the incorrect authorization check. If immediate upgrade is not possible, administrators should restrict workflow sharing to fully trusted users only and limit network access to the n8n Public API to trusted users or IP ranges. These workarounds do not fully remediate the risk and should only be used as short-term measures pending upgrade (n8n Advisory).