Skip to main content
Vulnerability Database/CVE-2025-52554

CVE-2025-52554: N8n Workflow Authorization Bypass Vulnerability

CVE-2025-52554 is an authorization bypass flaw in N8n workflow automation platform allowing authenticated users to stop executions they don't own. This article covers the technical details, affected versions, and mitigation strategies.

Published:

CVE-2025-52554 Overview

CVE-2025-52554 is a broken access control vulnerability in n8n, an open-source workflow automation platform. The flaw affects the /rest/executions/:id/stop REST endpoint in versions prior to 1.99.1. An authenticated user can invoke this endpoint to stop workflow executions they do not own and that have not been shared with them. The vulnerability stems from missing authorization checks [CWE-862] in the execution service layer. Successful exploitation causes business disruption by terminating in-progress automations owned by other users. The issue is patched in n8n version 1.99.1.

Critical Impact

Any authenticated n8n user can terminate arbitrary workflow executions across tenants, disrupting automation pipelines and dependent business processes.

Affected Products

  • n8n workflow automation platform (Node.js package)
  • All n8n deployments prior to version 1.99.1
  • Self-hosted and container-based n8n installations

Discovery Timeline

  • 2025-07-03 - CVE-2025-52554 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-52554

Vulnerability Analysis

The vulnerability resides in the stop() method of execution.service.ts within the n8n CLI package. Before the patch, the stop() method accepted only an executionId parameter and retrieved the execution using findSingleExecution() without validating ownership. The executions.controller.ts route handler determined the caller's accessible workflow IDs but never passed them to the service layer. As a result, any authenticated user could stop any execution by knowing or guessing its ID.

The root cause is a missing authorization check on a state-changing API endpoint. The controller performed workflow discovery to satisfy a NotFoundError, but the downstream stop() call bypassed that scope entirely. This is a classic broken access control pattern where the presentation layer collects authorization context that the business logic ignores.

Root Cause

The executionService.stop(req.params.id) invocation queried the database for the target execution without filtering on workflows shared with the requesting user. The repository method findSingleExecution() performs no ownership scoping. This design allowed cross-tenant execution termination whenever a valid execution ID was supplied.

Attack Vector

An attacker with valid n8n credentials sends an authenticated HTTP POST request to /rest/executions/:id/stop with an execution ID belonging to another user. The server terminates the execution without verifying that the caller owns or shares the parent workflow. Execution IDs are sequential integers in default deployments, enabling trivial enumeration.

typescript
// Patch: packages/cli/src/executions/execution.service.ts
-	async stop(executionId: string): Promise<StopResult> {
-		const execution = await this.executionRepository.findSingleExecution(executionId, {
-			includeData: true,
-			unflattenData: true,
-		});
+	async stop(executionId: string, sharedWorkflowIds: string[]): Promise<StopResult> {
+		const execution = await this.executionRepository.findWithUnflattenedData(
+			executionId,
+			sharedWorkflowIds,
+		);

-		if (!execution) throw new MissingExecutionStopError(executionId);
+		if (!execution) {
+			this.logger.info(`Unable to stop execution "${executionId}" as it was not found`, {
+				executionId,
+			});
+			throw new MissingExecutionStopError(executionId);
+		}

 		this.assertStoppable(execution);

Source: n8n commit e5edc60

The controller now forwards the caller's authorized workflow IDs to the service layer:

typescript
// Patch: packages/cli/src/executions/executions.controller.ts
 		if (workflowIds.length === 0) throw new NotFoundError('Execution not found');

-		return await this.executionService.stop(req.params.id);
+		const executionId = req.params.id;
+
+		return await this.executionService.stop(executionId, workflowIds);
 	}

Source: n8n Pull Request #16405

Detection Methods for CVE-2025-52554

Indicators of Compromise

  • HTTP POST requests to /rest/executions/:id/stop originating from user sessions that do not own the referenced workflow.
  • Unexpected MissingExecutionStopError log entries following the patch, indicating probing for foreign execution IDs.
  • Workflow executions transitioning to a stopped state without user-initiated action from the workflow owner.

Detection Strategies

  • Correlate n8n audit logs of stop requests with workflow ownership tables to identify cross-user termination attempts.
  • Alert on sequential enumeration patterns against /rest/executions/:id/stop from a single authenticated session.
  • Monitor n8n application logs for unusual spikes in execution termination events outside normal operational windows.

Monitoring Recommendations

  • Enable verbose logging on the n8n /rest/executions/* endpoints and forward logs to a centralized SIEM.
  • Track the ratio of stopped versus completed executions per user account to detect anomalies.
  • Review reverse proxy or API gateway access logs for authenticated users invoking stop operations against IDs outside their workflow scope.

How to Mitigate CVE-2025-52554

Immediate Actions Required

  • Upgrade n8n to version 1.99.1 or later, which contains the authorization fix from pull request #16405.
  • Audit historical execution logs for unauthorized stop actions by comparing initiating users against workflow ownership records.
  • Rotate n8n user credentials and API tokens if evidence of enumeration or abuse is discovered.

Patch Information

The fix is delivered in n8n 1.99.1. The upstream commit e5edc60 modifies execution.service.ts and executions.controller.ts to pass the caller's sharedWorkflowIds into the execution lookup, ensuring the repository returns a record only when the user has legitimate access. Full details are published in GitHub Security Advisory GHSA-gq57-v332-7666.

Workarounds

  • Restrict access to the /rest/executions/:id/stop endpoint at a reverse proxy such as nginx, Traefik, or Caddy until the upgrade is applied.
  • Enforce endpoint access rules at an API gateway that validates the caller's workflow ownership before proxying the request.
  • Limit n8n user account provisioning to trusted operators to reduce the pool of authenticated actors capable of triggering the flaw.
bash
# Example nginx configuration to block the vulnerable endpoint
location ~ ^/rest/executions/[^/]+/stop$ {
    deny all;
    return 403;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.