How severe is CVE-2025-61917?

CVE-2025-61917 has a CVSS score of 7.7/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2025-61917?

CVE-2025-61917 affects the following packages: n8n (npm). Ecosystems affected: npm.

How do I fix CVE-2025-61917?

Update n8n to 1.114.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-61917 is resolved across your whole dependency graph.

How do I detect CVE-2025-61917 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for n8n, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2025-61917 if there is no patch (or I can't update yet)?

Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Is CVE-2025-61917 actively exploited in the wild?

No public exploit code has been indexed for CVE-2025-61917 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2025-61917?

CVE-2025-61917 has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 34th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2025-61917?

CVE-2025-61917 is classified as Information Exposure (CWE-200), CWE-668 (CWE-668). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2025-61917 published, and has it been updated?

CVE-2025-61917 was published on February 4, 2026 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

HIGH severity

CVE-2025-61917 — n8n

HIGHFix: n8n-io/n8n@2c4c295

CVE-2025-61917 is a high-severity (CVSS 7.7) Information Exposure vulnerability in n8n. A fix is available for n8n — see the affected versions and patch details below.

n8n Unsafe Buffer Allocation Allows In-Process Memory Disclosure in Task Runner

Also known asGHSA-49mx-fj45-q3p6

Published

Feb 4, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2025-61917.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk-0.00%

Lower risk than most CVEs34th percentile — riskier than 34% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

36other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

n8nnpm

138Kdownloads / week

Description

Impact

The use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure.

Only authenticated users are able to execute code through Task Runners.

This issue affected any deployment in which both of the following conditions were met:

Task Runners were enabled using N8N_RUNNERS_ENABLED=true (default: false)
Code Node was enabled (default: true)

Patches

Access to unsafe Buffer functions has been removed from the task runner sandbox. All buffer allocations are now zero-filled by default.

Fixed in: 1.114.3 & 1.115.0
Action: It is strongly recommended to upgrade to version ≥ 1.114.3 as soon as possible.

Changes introduced in this patch include:

Routing all buffer allocations through Buffer.alloc (which zero-fills) operations where applicable
Adding regression tests to ensure continued enforcement of safe allocation practices

Workarounds

If an immediate upgrade cannot be applied, the following hardening steps are recommended:

Disable the Code Node by adding n8n-nodes-base.code to the NODES_EXCLUDE environment variable
Prefer external mode for isolation: run Task Runners in external mode so that untrusted task code executes in a separate sidecar container rather than within the main n8n process. This configuration significantly reduces the risk of in-process memory disclosure caused by unsafe buffer allocations.
In external mode, a launcher manages Task Runner processes in a dedicated sidecar environment, separate from the primary n8n instance.
See the n8n documentation for configuration details and required environment variables.

Resources

Node.js documentation: Buffer.alloc() vs Buffer.allocUnsafe() — background on zero-filled vs uninitialized allocations
n8n Documentation — Task Runners — external mode, setup guide, and environment configuration details
n8n Documentation — Blocking nodes — how to globally disable specific nodes

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`n8n`	≥ 1.65.0&&< 1.114.3	1.114.3`npm install n8n@1.114.3`

Affected Products

1 product · 1 configurations

Application

n8nn8n

≥ 1.65.0 && < 1.114.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for n8n, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update n8n to 1.114.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-61917 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Frequently Asked Questions

### Impact The use of `Buffer.allocUnsafe()` and `Buffer.allocUnsafeSlow()` in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure. Only authenticated users are able to execute code through Task Runners. This issue affected any deployment in which both of the following conditions were met: - Task Runners were enabled using `N8N_RUNNERS_ENABLED=true` (default: false)