GHSA-h3jj-5f3v-3685

What it actually does

n8n’s public API does not correctly enforce authorization on workflow execution retry. An authenticated API caller can retry executions they are not permitted to control, causing those workflows to run again with the original connections, credentials, and input data.

Why it matters to the business

Unauthorized retries can re-fire automated business processes (notifications, data syncs, tickets, payments, or other integrations), mutate or expose data in connected systems, burn third-party API quota, and break segregation of duties on a shared automation platform. The issue is not in CISA KEV, has no reported exploit maturity, and is not tied to ransomware, but it has been public for over four months (published 2026-06-16). Any multi-user or internet-reachable n8n instance should still treat patching as overdue.

How an attack unfolds

An attacker who already has valid n8n public API credentials—such as a low-privilege user, a leaked API key, or an over-scoped token—identifies execution IDs outside their intended scope and submits retry requests through the public API. Because authorization on retry is not enforced correctly, n8n re-runs the target workflow using stored credentials and integrations. No named threat actors or in-the-wild campaigns are associated with this advisory; the realistic scenario is opportunistic abuse by insiders or holders of stolen API tokens rather than unauthenticated mass exploitation.

How to fix it

Upgrade the n8n npm package to a fixed release: 2.25.7 or later on the 2.25 line, or 2.26.2 or later on the 2.26 line (or any subsequent patched release). After upgrading, rotate public API keys and personal access tokens, restrict who can create API credentials, and limit public API exposure with network controls and least-privilege credential scopes. Do not rely on hiding execution IDs as a control.

How to confirm the fix worked

Confirm the running n8n version is 2.25.7+, 2.26.2+, or a later patched release. In a non-production check, verify that an authenticated API principal without rights on a given execution receives a denial on retry and that no new execution is created. Review API credential inventory and workflow execution history for retries performed by unexpected users or keys.

Typical attack path

1. Obtain valid n8n public API credentials with some ability to interact with executions
2. Discover execution identifiers belonging to other users, projects, or workflows
3. Call the public API execution-retry operation against those identifiers
4. Benefit from the unauthorized re-run (side effects in connected apps, data movement, or process disruption)

How to detect it

This advisory has no reported in-the-wild exploitation, so look for suspicious use of the retry API rather than a known implant. Review n8n and reverse-proxy access logs for authenticated calls to execution-retry endpoints, especially where the caller does not own the workflow or project. In n8n’s execution history and audit trail, flag retries of another user’s executions, bursts of retries across many execution IDs, or retries immediately after credential creation or key use from unusual source IPs. Correlate with downstream app logs (email, ticketing, ERP, payment, or SaaS connectors) for unexpected re-runs of the same workflow.

• POST /api/v1/executions/
• /retry
• POST /rest/executions/
• n8n public API execution retry

What your security team should do

• Patch n8n to 2.25.7, 2.26.2, or later immediately on all instances, especially shared or internet-facing ones
• Inventory and rotate n8n public API keys and tokens; remove unused credentials
• Restrict public API access (network allowlists, SSO, least-privilege scopes) until and after the upgrade
• Hunt execution-retry activity by unexpected principals over the period this instance was unpatched
• Treat this as a standard authorization-bypass patch, not a KEV emergency, but close the 122-day exposure window