CVE-2025-61917: n8n Workflow Information Disclosure Flaw

CVE-2025-61917 Overview

CVE-2025-61917 is a memory information disclosure vulnerability affecting n8n, an open source workflow automation platform. The vulnerability exists in versions 1.65.0 through 1.114.2, where the use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allows untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process, including sensitive information from prior requests, tasks, secrets, or authentication tokens.

Critical Impact
Untrusted code execution within n8n workflows can access sensitive residual data from uninitialized memory buffers, potentially exposing secrets, tokens, and data from prior requests within the Node.js process.

Affected Products

n8n versions 1.65.0 through 1.114.2
n8n self-hosted deployments running vulnerable versions
n8n cloud instances prior to version 1.114.3

Discovery Timeline

2026-02-04 - CVE CVE-2025-61917 published to NVD
2026-02-05 - Last updated in NVD database

Technical Details for CVE-2025-61917

Vulnerability Analysis

This vulnerability stems from the improper use of Node.js buffer allocation methods within n8n's task runner component. The Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() methods are designed for performance-critical applications where developers explicitly manage buffer initialization. However, when used in an environment where untrusted code can execute, these methods create a significant security risk.

When a buffer is allocated using Buffer.allocUnsafe(), Node.js returns a buffer pointing to uninitialized memory. This memory may contain residual data from previous allocations within the same process, including sensitive information such as API keys, authentication tokens, session data, or workflow secrets that were previously processed by n8n.

The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), as it enables unauthorized access to potentially sensitive data through uninitialized memory exposure.

Root Cause

The root cause of this vulnerability is the use of unsafe buffer allocation methods (Buffer.allocUnsafe() and Buffer.allocUnsafeSlow()) in n8n's task runner without proper memory initialization. These methods skip the memory zeroing step that Buffer.alloc() performs, creating an opportunity for information leakage when the allocated buffers are accessible to untrusted code executed within workflows.

In the context of n8n's workflow automation platform, users can execute custom code through various nodes and integrations. When this untrusted code gains access to uninitialized buffers, it can read residual memory contents that may contain sensitive data from previous operations within the same Node.js process.

Attack Vector

The attack vector for this vulnerability requires network access with low-privilege authentication to the n8n platform. An attacker with the ability to create or execute workflows can craft malicious code that:

Triggers the allocation of uninitialized buffers through the task runner
Reads the contents of these buffers before they are properly initialized
Extracts sensitive information such as secrets, tokens, or data from prior workflow executions

The attack does not require user interaction and can be executed remotely against vulnerable n8n instances. The scope is changed, meaning the vulnerability can affect resources beyond the vulnerable component's security boundary, potentially exposing data from other workflows or users sharing the same n8n process.

Detection Methods for CVE-2025-61917

Indicators of Compromise

Unusual workflow executions attempting to allocate large buffers or perform repeated buffer operations
Workflows containing code that reads raw buffer contents without explicit data assignment
Abnormal data exfiltration patterns from n8n workflow outputs
Unexpected API calls or network requests containing base64-encoded or binary data from workflow executions

Detection Strategies

Monitor n8n workflow logs for suspicious code execution patterns involving buffer operations
Implement network monitoring for unusual data transfers originating from n8n instances
Review workflow definitions for code that accesses buffer contents immediately after allocation
Enable audit logging for all workflow creations and modifications to track potentially malicious changes

Monitoring Recommendations

Deploy application-level monitoring to track buffer allocation patterns within n8n processes
Configure alerting for workflows that attempt to access memory-related APIs
Implement data loss prevention (DLP) rules to detect sensitive data exfiltration through workflow outputs
Regularly audit workflow permissions to ensure principle of least privilege

How to Mitigate CVE-2025-61917

Immediate Actions Required

Upgrade n8n to version 1.114.3 or later immediately
Review existing workflows for potentially malicious code that could exploit this vulnerability
Audit recent workflow execution logs for suspicious buffer-related operations
Consider temporarily restricting workflow creation permissions until patching is complete

Patch Information

n8n has addressed this vulnerability in version 1.114.3. The fix replaces the use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() with safe alternatives that properly initialize memory before use. Users should upgrade to version 1.114.3 or later to remediate this issue. Additional details are available in the GitHub Security Advisory and the commit implementing the fix.

Workarounds

Restrict workflow creation and execution permissions to trusted users only until patching is complete
Implement network segmentation to isolate n8n instances from sensitive internal resources
Monitor and review all custom code within workflows for suspicious buffer operations
Consider disabling or limiting code execution nodes if not required for business operations
Deploy application firewalls to monitor and filter potentially malicious workflow traffic

bash

# Upgrade n8n to patched version
npm update n8n@1.114.3

# For Docker deployments
docker pull n8nio/n8n:1.114.3
docker stop n8n-container
docker run -d --name n8n-container n8nio/n8n:1.114.3