CVE-2026-41324

What it actually does

Versions of the Node.js basic-ftp package before 5.3.0 process remote FTP directory listings without enforcing a safe upper bound on the amount of listing data accepted by Client.list(). A malicious or compromised FTP server can return an extremely large or never-ending directory listing, causing the consuming Node.js process to allocate memory continuously until garbage collection stalls, the process becomes unstable, or it terminates with an out-of-memory condition. The impact is availability loss only; the vulnerability does not directly enable code execution, data theft, or data modification.

Why it matters to the business

Applications, automation jobs, file-transfer integrations, and backend services that use vulnerable basic-ftp versions can be crashed by a hostile or compromised FTP server they connect to. This may interrupt scheduled transfers, ingestion pipelines, partner integrations, backups, reporting workflows, or other business processes dependent on FTP availability. The CVSS score is high for availability impact, but EPSS is currently low, exploitation maturity is listed as none, and it is not in the CISA KEV catalog, so remediation should be prioritized for internet-facing, business-critical, or untrusted-FTP workflows rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs control of, or the ability to impersonate, an FTP server that a vulnerable application connects to. When the application calls Client.list(), the attacker responds to the directory listing command with an excessively large stream of listing entries or keeps the response open and continuously sends data. Because affected basic-ftp versions do not cap the listing size, the Node.js process continues buffering or processing the response until memory usage grows beyond safe limits. The result is degraded performance, garbage-collection pressure, process termination, container restart, job failure, or service outage. In practice, this is most likely to be exploitable where applications connect to third-party FTP servers, user-supplied FTP endpoints, partner-managed servers, or any FTP server that could be compromised or spoofed.

How to fix it

Upgrade basic-ftp to version 5.3.0 or later wherever it is used. Regenerate and redeploy lockfiles and container images so the fixed dependency is actually present in runtime artifacts. If immediate upgrade is not possible, reduce exposure by allowing connections only to trusted FTP servers, blocking user-supplied or unvalidated FTP endpoints, applying strict network egress controls, setting Node.js/container memory limits, enforcing application-level timeouts for listing operations, and avoiding large recursive or unbounded listing workflows. Consider wrapping Client.list() calls with defensive limits on expected entry count, response duration, and job retry behavior so a single failed listing cannot cause repeated crashes.

How to confirm the fix worked

Confirm that package manifests, lockfiles, software composition analysis results, and deployed artifacts show basic-ftp version 5.3.0 or later. Check both direct and transitive dependency paths, including packaged serverless functions, containers, CI/CD artifacts, and long-running worker images. Run `npm ls basic-ftp` or equivalent dependency inspection in each built application. Validate operationally by connecting a test instance to a controlled FTP server that emits an oversized listing and confirming the process no longer grows memory without bound or crashes. Also verify that memory limits, request/listing timeouts, retry limits, and egress restrictions are active in production-like configurations.

Typical attack path

1. Identify an application or job that uses basic-ftp before version 5.3.0 to connect to an FTP server.
2. Gain control of the FTP server, compromise a legitimate FTP endpoint, or position a malicious FTP service where the application will connect to it.
3. Wait for or trigger application functionality that invokes Client.list() against the attacker-controlled FTP server.
4. Return an extremely large or never-ending directory listing response.
5. Force the Node.js process to consume increasing memory while processing the listing.
6. Cause the process, container, worker, or scheduled job to slow down, crash, restart, or fail.

How to detect it

Look for evidence of abnormal memory growth or crashes in Node.js processes shortly after FTP directory listing activity. Relevant sources include application logs, process supervisor logs, container runtime events, Kubernetes pod events, system logs, APM memory metrics, FTP client debug logs, network egress logs, DNS logs, and proxy/firewall records for outbound FTP connections. Investigate sequences where a service connects to an FTP server, issues a directory listing, then shows sustained memory growth, garbage-collection pressure, out-of-memory errors, container OOMKilled events, worker restarts, or repeated job failures. Pay particular attention to FTP destinations that are new, user-supplied, partner-managed, recently changed, or associated with unusually long-lived data transfers. Because this vulnerability does not create a distinctive file or payload on disk, detection is primarily behavioral: correlate outbound FTP LIST/MLSD activity with process memory exhaustion and crashes. There are no known public exploit strings, named threat actors, KEV listing, or ransomware campaign associations for this vulnerability at this time.

• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed
• Ineffective mark-compacts near heap limit
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• out of memory: Kill process
• Killed process node
• Container killed due to memory usage
• Client.list()
• node_modules/basic-ftp/package.json
• "basic-ftp"
• FTP LIST
• FTP MLSD

What your security team should do

• Inventory all applications, containers, serverless functions, and automation jobs that include the Node.js basic-ftp package.
• Prioritize upgrade to basic-ftp 5.3.0 or later for services that connect to internet-accessible, partner-managed, user-configurable, or otherwise untrusted FTP servers.
• Redeploy rebuilt artifacts after dependency updates; do not rely only on source repository changes.
• Add egress allowlisting so FTP clients can connect only to approved destinations.
• Set memory, timeout, and retry controls for FTP listing workflows to reduce blast radius from malformed or hostile servers.
• Monitor for Node.js out-of-memory crashes and repeated failed FTP listing jobs, especially after connections to new or unusual FTP servers.
• Review whether FTP is still required for critical workflows and migrate high-value transfers to protocols and integrations with stronger authentication, integrity, and operational controls where feasible.