Description
Uploads via FTPS (implicit secure: true, passive mode) fail against FileZilla Server with:
425 Unable to build data connection: TLS session of data connection not resumed.
The transfer starts successfully (control connection authenticates, EPSV/PASV succeeds, STOR gets a 150 response, some data is even transferred), then the server aborts mid-transfer with the error above.
Environment
- basic-ftp version: [fill in — e.g. npm ls basic-ftp]
- Node.js: fails on v24.18.0, works fine on v24.13.1 and v18.20.8
- Server: FileZilla Server 1.4.1
- secureOptions: { rejectUnauthorized: false } (self-signed cert)
Root cause (as far as I can tell)
This started failing exactly at Node's June 2026 security release. Node v24.17.0 shipped a fix for CVE-2026-48934 — "tls: bind reusable sessions to authenticated host" (https://github.com/nodejs/node/releases/tag/v24.17.0). That fix makes Node refuse to treat a cached TLS session as valid for reuse unless it can confirm the new connection is against the same authenticated host as the original session.
connectForPassiveTransfer() in transfer.js reuses the control connection's session for the data connection via:
session: ftp.socket.getSession()
but doesn't pass an explicit servername/host-identity binding for that second tls.connect() call. With rejectUnauthorized: false (required for self-signed FTPS certs, which is extremely common), there's no certificate-verified host identity for Node to confirm the reuse against — so under the new hardening, the resumption silently fails, and FileZilla Server (correctly) reports it as not-resumed.
Reproduction
- Point basic-ftp at an FTPS server that enforces session-reuse on the data connection (e.g. FileZilla Server with "require session resumption" — its default behavior).
- Use rejectUnauthorized: false in secureOptions (self-signed cert).
- Run on Node v24.17.0+.
- Attempt an upload in passive mode.
Workaround
Pinning to Node v24.13.1 (pre-CVE-fix) resolves the issue, but that means missing subsequent Node security patches — not a real long-term fix.
Description
Uploads via FTPS (implicit secure: true, passive mode) fail against FileZilla Server with:
425 Unable to build data connection: TLS session of data connection not resumed.
The transfer starts successfully (control connection authenticates, EPSV/PASV succeeds, STOR gets a 150 response, some data is even transferred), then the server aborts mid-transfer with the error above.
Environment
Root cause (as far as I can tell)
This started failing exactly at Node's June 2026 security release. Node v24.17.0 shipped a fix for CVE-2026-48934 — "tls: bind reusable sessions to authenticated host" (https://github.com/nodejs/node/releases/tag/v24.17.0). That fix makes Node refuse to treat a cached TLS session as valid for reuse unless it can confirm the new connection is against the same authenticated host as the original session.
connectForPassiveTransfer() in transfer.js reuses the control connection's session for the data connection via:
session: ftp.socket.getSession()
but doesn't pass an explicit servername/host-identity binding for that second tls.connect() call. With rejectUnauthorized: false (required for self-signed FTPS certs, which is extremely common), there's no certificate-verified host identity for Node to confirm the reuse against — so under the new hardening, the resumption silently fails, and FileZilla Server (correctly) reports it as not-resumed.
Reproduction
Workaround
Pinning to Node v24.13.1 (pre-CVE-fix) resolves the issue, but that means missing subsequent Node security patches — not a real long-term fix.