CVE-2026-44240

What it actually does

This vulnerability is a client-side denial-of-service flaw in the Node.js basic-ftp library before version 5.3.1. When an application connects to an FTP server, the server can send a malformed or unterminated multiline FTP control-channel response during the initial banner phase, before authentication. The vulnerable parser continues appending attacker-controlled data to the partial response buffer and repeatedly reparses the growing buffer without enforcing a maximum response size. This can cause unbounded memory growth and excessive CPU usage, leaving connect() stuck and potentially crashing or restarting the Node.js process.

Why it matters to the business

Applications that automatically connect to FTP servers can be degraded or taken offline if they contact a malicious or compromised FTP endpoint. The most likely consequences are failed file transfers, worker exhaustion, queue backlogs, container out-of-memory kills, service restarts, and reduced availability of dependent business workflows. Although this issue does not directly expose data or allow code execution, it can interrupt operations that rely on scheduled or automated FTP integrations. The CVSS availability impact is high, but EPSS is currently low and there is no known CISA KEV listing or reported ransomware use, so remediation should be prioritized based on exposure to untrusted or third-party FTP servers.

How an attack unfolds

An attacker controls, compromises, or impersonates an FTP server that a vulnerable application connects to. During the initial connection banner, before any login occurs, the server sends a multiline FTP response that begins like a valid multiline response but never sends the terminating line. The vulnerable basic-ftp client keeps reading and appending the incoming control-channel data into its partial response state while repeatedly reparsing the accumulated buffer. Because there is no effective maximum control response size before version 5.3.1, memory and CPU consumption grow under attacker control. The application remains stuck in the connection flow and may eventually suffer degraded performance, worker starvation, garbage-collection pressure, an out-of-memory crash, or a container/process restart.

How to fix it

Upgrade basic-ftp to version 5.3.1 or later wherever it is used. Rebuild and redeploy applications, containers, serverless packages, and worker images that bundle the vulnerable dependency. If immediate upgrade is not possible, restrict FTP destinations to explicitly trusted hosts, block connections to untrusted FTP servers, apply network egress controls, and enforce application-level connection timeouts and process memory limits. Consider wrapping FTP connection attempts with strict deadlines and retry limits so a stuck connect() cannot indefinitely consume worker capacity. Also review dependency lockfiles to ensure transitive or pinned installations do not continue to resolve to versions earlier than 5.3.1.

How to confirm the fix worked

Confirm that package manifests and lockfiles resolve basic-ftp to version 5.3.1 or later, then verify deployed artifacts contain the updated dependency rather than only updated source files. Use package inspection commands such as npm ls basic-ftp, yarn why basic-ftp, or pnpm why basic-ftp in each application build context. Validate container images and deployed bundles if dependencies are vendored at build time. Functional testing should include connecting to a controlled FTP test server that sends an unterminated multiline banner and confirming the application terminates the connection safely without unbounded CPU or memory growth. Review runtime telemetry after deployment to ensure FTP connection attempts no longer correlate with sustained memory growth, high CPU, stuck workers, or OOM restarts.

Typical attack path

1. Identify an application, job, worker, or integration that uses the Node.js basic-ftp library to connect to FTP endpoints.
2. Gain control of an FTP server the application connects to, compromise an existing trusted FTP endpoint, or position a malicious FTP service where the application will connect.
3. Accept the inbound FTP connection and send an initial multiline banner response that is never properly terminated.
4. Continue sending attacker-controlled control-channel data so the vulnerable client appends it to the partial response buffer.
5. Cause the Node.js process to consume increasing CPU and memory while connect() remains unresolved.
6. Trigger operational impact such as failed transfers, worker restarts, container OOM kills, queue backlog, or service unavailability.

How to detect it

To determine whether exploitation may have occurred, review application logs, process telemetry, container events, and FTP connection logs for FTP connection attempts that never completed, especially before authentication or immediately after receiving a server banner. Look for Node.js processes with rising memory and CPU during connect() operations, garbage-collection pressure, out-of-memory crashes, worker restarts, and queue backlogs tied to FTP jobs. Network captures or FTP proxy logs may show a server banner using an FTP multiline response prefix such as a 3-digit code followed by a hyphen, for example 220-, without the required terminating line using the same code followed by a space. Correlate suspicious events with destination FTP servers, recent endpoint changes, partner FTP outages, DNS changes, or unexpected FTP destinations. If available, preserve packet captures and application debug logs for sessions where the FTP control channel received unusually large banner responses or did not progress to authentication.

• basic-ftp
• FtpContext._partialResponse
• connect()
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• ENOMEM
• OOMKilled
• out of memory
• Container killed due to memory usage
• 220-
• FTP multiline response
• unterminated multiline response

What your security team should do

• Inventory all Node.js applications, workers, jobs, and containers that include the basic-ftp package.
• Prioritize systems that automatically connect to external, partner-managed, user-supplied, or otherwise untrusted FTP endpoints.
• Upgrade basic-ftp to 5.3.1 or later and redeploy all affected artifacts, including containers and packaged workers.
• Add or verify egress allowlisting for FTP destinations so applications cannot be directed to arbitrary FTP servers.
• Enforce connection timeouts, retry limits, memory limits, and worker supervision for FTP-related jobs.
• Search logs and telemetry for recent FTP connection hangs, Node.js out-of-memory errors, container OOM kills, and repeated worker restarts around FTP activity.
• Monitor for unexpected or newly introduced FTP endpoints in configuration, job payloads, or integration settings.
• Because the issue is not currently KEV-listed and EPSS is low, handle as a high-availability dependency fix, escalating urgency for internet-facing services or workflows that contact untrusted FTP servers.