Repository navigation
Conversation
Addresses CVE-2026-102990 (GHSA-c475-qrg2-pj4r), a quadratic-time CPU denial of service in the Client.list() directory-listing parser. The advisory affects basic-ftp <= 6.2.0 and there is no patched 5.x release. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 5d954f5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
martinfrancois
added a commit
to martinfrancois/testing-toolbox
that referenced
this pull request
Oct 5, 2026
basic-ftp 5.3.1 is affected by GHSA-c475-qrg2-pj4r (high, fixed in 6.2.1) and GHSA-5rfr-xx34-2xxv (moderate, fixed in 6.2.2), and no 5.x release carries either fix. @wdio/utils reaches it through @puppeteer/browsers, proxy-agent, pac-proxy-agent and get-uri 6.0.5, and get-uri asks for ^5.3.1 even in its newest release, 8.0.1, so no parent update gets out of the 5.x line. An override scoped to basic-ftp@5 is the only way to the fix. TooTallNate/proxy-agents#500 makes the same bump upstream. basic-ftp 6.0 has one break: a passive data connection to a host other than the control host now needs allowSeparateTransferHost. get-uri calls access, lastMod, list and downloadTo, which did not change, and get-uri 6.0.5 with 6.2.2 fetched a PAC file from a local FTP server. 6.2.2 was published on 2026-10-04 and is younger than pnpm's built-in one-day minimumReleaseAge. That default is not strict, so pnpm wrote basic-ftp@6.2.2 into minimumReleaseAgeExclude on its own. The entry is kept with a comment that says when it can go. A plain pnpm install --lockfile-only also deduplicated @types/node 22.7.8 onto 24.13.4. The lockfile here changes only basic-ftp; pnpm 12.4.1 leaves it byte-identical on install --lockfile-only and installs it with --frozen-lockfile.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps
basic-ftpinget-urifrom^5.3.1to^6.2.1to pick up the fix for GHSA-c475-qrg2-pj4r / CVE-2026-102990 (high severity): quadratic-time CPU denial of service in theClient.list()Unix directory-listing parser.Why a major bump
The advisory affects
basic-ftp <= 6.2.0and the only patched release is 6.2.1. There is no fixed release in the 5.x line, so the current^5.3.1range can't resolve to a patched version.npm auditnow flags everything downstream ofget-uri(pac-proxy-agent,proxy-agent), and its only suggested fix is downgrading toproxy-agent@5.get-urireaches the affected code:ftp.tsfalls back toclient.list()when the server doesn't supportMDTM.Compatibility
The only breaking change between 5.3.1 and 6.2.1 is in 6.0.0:
Two things worth knowing about that:
Clientmethodsget-uriuses (access,lastMod,list,downloadTo,close) are unchanged, so no source changes are needed.get-uricallsnew Client()with no arguments and passes its options toclient.access(), so there is currently no way for aget-uricaller to opt back in to separate transfer hosts. Anftp:URI served by a server that sends PASV responses pointing at a different host would stop working. I've left that as is, since the new default is the safer one, but I'm happy to add a pass-through option if you'd prefer.I've marked the changeset as
patch, in line with the earlierbasic-ftpsecurity bumps (#401, #413, #425). Let me know if you'd rather treat the behavior change above asminorormajor.basic-ftp@6.2.1declaresengines.node >= 10, so it fits withinget-uri'snode >= 20.Testing
With the bump applied, on Node 24.21.0:
pnpm --filter get-uri... buildsucceedsvitest runinpackages/get-uripasses: 7 test files, 22 tests, includingftp.test.tsRelease request
Once this lands, could you cut releases of
get-uri,pac-proxy-agent, andproxy-agent?pac-proxy-agentdepends on an exactget-uriversion, so consumers ofproxy-agentwon't get the fix until all three are published.🤖 Generated with Claude Code