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
# 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
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
