GHSA-H3JJ-5F3V-3685: Public API Execution Retry Authorization Bypass in n8n

The workflow automation platform n8n provides a Public API to manage and automate executions. In multi-tenant or team environments, n8n relies on a defined permission model to enforce boundaries between different users and projects. These boundaries ensure that users with read-only access cannot modify state or trigger actions.

A logical flaw in the Public API endpoint responsible for retrying workflow executions broke this authorization model. The endpoint allowed users to perform write/execution operations if they possessed read-only permissions. This flaw is classified under CWE-863 (Incorrect Authorization).

This vulnerability is significant for environments where workflows connect to production resources, cloud infrastructure, or databases. By abusing this endpoint, an unauthorized actor can trigger side effects in downstream integrations, leading to unintended modifications of third-party systems.

The root cause of this vulnerability lies in the incorrect mapping of permission scopes within the Public API router. n8n utilizes distinct scopes to govern user actions: workflow:read for viewing resources, workflow:write for configuration modifications, and workflow:execute for initiating runtime activities.

When a client targets the endpoint /v1/executions/{executionId}/retry, the application API gateway is responsible for verifying the caller's scope. Due to an integration oversight, the route guard applied to this endpoint verified the presence of the workflow:read scope instead of the workflow:execute scope.

Because the API key or authorization token of a read-only user naturally contains the workflow:read scope, the gateway passed the request to the execution controller. The backend then processed the execution payload as if the user possessed full execution rights, demonstrating a direct breakdown in role-based access control.

In the vulnerable version of the application, the controller responsible for execution actions implemented route protection decorators incorrectly. The following conceptual representation demonstrates how the middleware authorized the request based on the read scope:

// VULNERABLE ROUTE DEFINITION
@Post('/executions/:executionId/retry')
@Scope('workflow:read') // Bug: Validated read access instead of execute access
async retryExecution(@Param('executionId') executionId: string) {
    return await this.executionService.retry(executionId);
}

The fix applied by the n8n developers updated the decorator to reference the correct cryptographic execution scope. This change ensures that the router drops requests from read-only users before invoking the execution engine:

// PATCHED ROUTE DEFINITION
@Post('/executions/:executionId/retry')
@Scope('workflow:execute') // Fix: Enforce active execution permissions
async retryExecution(@Param('executionId') executionId: string) {
    return await this.executionService.retry(executionId);
}

This patch completely resolves the specific logical path. However, organizations should perform regression testing to ensure no other active state-changing endpoints are decorated with passive read scopes.

To exploit this vulnerability, an attacker requires a valid account or API key with read-only privileges. The attack vector is entirely network-based and can be executed via standard HTTP command-line tools.

First, the attacker identifies a target workflow to which they have read-only access. They query the execution list to discover historic execution identifiers:

curl -X GET "https://n8n.example.com/v1/executions?workflowId=10" \
     -H "X-N8N-API-KEY: n8n_api_readonly_token_abc"

Next, the attacker selects a target execution ID (e.g., 105) from the response. They issue a POST request to the retry endpoint using the same read-only credentials:

curl -X POST "https://n8n.example.com/v1/executions/105/retry" \
     -H "X-N8N-API-KEY: n8n_api_readonly_token_abc" \
     -H "Content-Type: application/json"

The server returns a successful execution response, and the engine initiates a new runtime instance of the workflow using the historical input data of execution 105.

This vulnerability carries a CVSS v3.1 score of 6.4 (Medium). The scope parameter is classified as 'Changed' (S:C) because exploiting the API allows low-privileged users to trigger backend events that execute operations on third-party integrations outside the user's immediate scope.

Integrity impact is low to medium depending on the specific nodes configured in the target workflow. If the workflow executes SQL updates, writes to a cloud CRM, or interacts with transactional systems, repeating the execution can result in duplicated transactions or data corruption.

Resource exhaustion is also an operational risk. An automated script could repeatedly call the retry endpoint, causing n8n's execution queue to fill up. This would prevent legitimate workflows from running and deplete memory or CPU resources.

The definitive remediation for GHSA-H3JJ-5F3V-3685 is to upgrade n8n to a patched release. Systems on the 2.25.x release path must upgrade to 2.25.7 or later. Systems on the 2.26.x path must upgrade to 2.26.2 or later.

If patching cannot be performed immediately, administrators should implement strict network-level controls. Restrict access to the /v1/ API paths to trusted administrative source IP addresses using an API Gateway or Web Application Firewall.

Additionally, audit all active API keys and user privileges within the n8n application. Revoke any unnecessary keys and ensure that sharing workflows across teams is limited only to instances where collaboration is strictly required.