Vultisig’s Windows wallet repository began failing its security-audit checks across pull requests after a high-severity vulnerability in the basic-ftp JavaScript package entered GitHub’s Advisory Database, forcing maintainers to update a transitive dependency before normal CI could pass again.
The Vultisig-specific issue was opened at 22:08 UTC on October 1, or 01:08 Cairo time on October 2, after maintainers found that yarn quality:audit had started rejecting the repository because its dependency tree contained basic-ftp version 5.3.1.
The affected package was not directly installed by Vultisig’s wallet application. It arrived through a longer dependency chain beginning with the project’s Markdown link-checking tools and eventually passing through get-uri to basic-ftp.
GitHub’s security advisory for basic-ftp classifies the issue as High severity with a CVSS 4.0 score of 8.2. Versions through 6.2.0 are affected, while version 6.2.1 contains the fix.
The vulnerability is a CPU denial-of-service issue in the Unix directory-listing parser used by Client.list(). A malicious FTP server can return a specially constructed directory-listing line that causes a regular expression to perform large amounts of backtracking, consuming CPU and potentially freezing the Node.js event loop.
Importantly, there is no evidence that Vultisig wallet users were exposed to that attack path.
The Vulnerable Package Was in Development Tooling, Not the Wallet Bundle
Vultisig’s initial issue explicitly said it had not been verified whether any shipped code path actually performed FTP directory listings.
The subsequent investigation went further.
Maintainers determined that basic-ftp was used only through development tooling: markdown-link-check depends on link-check, which passes through proxy-related packages before eventually reaching get-uri and basic-ftp.
According to the merged fix, the dependency is used by Vultisig’s quality:docs:links process and is not included in either the desktop or browser-extension bundles distributed to users.
That distinction is critical. The presence of a vulnerable package in a repository does not automatically mean the finished product exposes the vulnerable functionality.
For the basic-ftp flaw to matter directly, software needs to reach the affected directory-listing parser while communicating with an attacker-controlled FTP server. Vultisig’s investigation did not identify such a path in its shipped wallet applications.
The case therefore looks very different from incidents where malicious software reaches users directly, such as the fake Zano wallet that distributed remote-access malware. Here, the security tooling detected vulnerable code several layers down a development dependency tree before evidence emerged of user exposure.
The 14-Day Dependency Cooldown Turned Out Not to Block the Fix
The original Vultisig issue raised a second complication.
The repository uses a 14-day minimum-age policy for newly published packages, designed to reduce the chance that developers immediately ingest a compromised or malicious new dependency release.
Because maintainers initially believed basic-ftp 6.2.1 had been released alongside the October 1 advisory, the issue suggested two possible paths: wait until the patched version cleared the cooldown or temporarily suppress the advisory inside the CI audit.
That turned out to be unnecessary.
Further investigation found that version 6.2.1 was actually published on August 27. The vulnerability had been disclosed by the package maintainer at that time, while the advisory reached the wider GitHub Advisory Database on October 1.
That placed the patched release well beyond Vultisig’s 14-day age requirement.
Maintainers were therefore able to force basic-ftp 6.2.1 through a Yarn resolutions rule instead of weakening the security audit.
A Second CI Bug Appeared at Almost the Same Time
The dependency advisory was not the only reason Vultisig’s quality checks were failing.
On October 2, maintainers found another issue inside the project’s own audit script.
Three existing vulnerability suppressions had a review date of October 1. Once that date passed, the script printed an expiration warning while being imported by its own automated test.
That mattered because one of the tests expected no output to standard error when the module was merely imported. The warning therefore caused the audit script’s self-test to fail before the actual dependency audit even ran.
The resulting fix addressed both problems.
Vultisig pinned basic-ftp 6.2.1, removed two outdated vulnerability suppressions, retained another dependency suppression that still lacks a fixed upstream release, and changed the expiry-warning logic so it appears only when the audit script is executed directly.
Pull request #5097 was merged into the main branch on October 2. The maintainers reported that the full audit, documentation-link checks and broader project checks passed after the changes.
The Interesting Security Story Is the Control That Worked
At first glance, a high-severity vulnerability appearing inside a crypto wallet repository sounds alarming.
In this case, that framing would be misleading.
There is no evidence that private keys, wallet balances or transaction-signing functionality were affected. There is also no indication that attackers exploited Vultisig users through basic-ftp.
The more interesting story is that an indirect dependency several layers away from the application was enough to stop routine development until maintainers resolved the advisory.
That is what a strict security gate is supposed to do.
Crypto applications have unusually high stakes because software defects can sometimes lead directly to irreversible financial losses. Recent incidents such as the Relay API leak that exposed users to sandwich attacks show how a weakness outside the core blockchain itself can still create real economic consequences.
Wallet developers therefore have good reason to be more conservative than an ordinary web application when deciding how quickly to absorb new packages and how aggressively to respond to dependency advisories.
Dependency Cooldowns Solve One Risk but Create Another
Vultisig’s 14-day package rule illustrates an increasingly difficult software-security trade-off.
Automatically upgrading to the newest package as soon as it appears sounds secure because vulnerabilities get patched quickly.
But new releases can themselves be the attack.
Software supply-chain compromises often depend on developers installing a malicious package version before the ecosystem realizes something is wrong. A minimum-age requirement creates a buffer during which suspicious new releases can be identified before they enter a sensitive codebase.
The downside appears when a genuine security patch is newly published.
If the vulnerable version is already present and the fixed release is younger than the cooldown, developers must choose between temporarily carrying the known vulnerability, overriding their package-age policy or suppressing an audit failure.
That is why the corrected publication date mattered so much here.
Vultisig did not actually have to choose. The patched package was more than a month old, even though the GitHub database alert was new.
Crypto Security Increasingly Depends on Software Nobody Sees
The episode also highlights how misleading the phrase “wallet security” can be.
Users see a desktop application, browser extension or mobile interface. Behind it can sit hundreds or thousands of open-source packages covering networking, parsing, testing, documentation, builds, development servers and tooling.
Many never handle a private key.
But every dependency increases the amount of third-party code a project has to understand, update and monitor.
The same infrastructure-layer problem appears elsewhere in crypto. When Payy shut down payment functionality after a bridge exploit, the user-facing product depended on security properties buried deeper in the technical stack.
In Vultisig’s case, the dependency sat far enough away from the wallet runtime that the immediate user risk appears minimal. Yet the repository still treated the advisory seriously enough to halt its normal quality gate.
That is arguably the correct failure mode.
The Better Lesson Is Not That Vultisig Was Vulnerable
The strongest conclusion from issue #5087 is not that Vultisig wallets were vulnerable to a remote FTP denial-of-service attack.
The available evidence supports almost the opposite.
A security advisory reached the ecosystem, an automated audit detected an affected transitive version, CI began failing, maintainers traced the dependency to development-only documentation tooling, verified that the patched release could be adopted under their package-age policy and merged the fix within roughly a day of the issue being opened.
The original report also corrected itself as better information became available.
That matters. Security reporting is often messiest during the first few hours of a disclosure, when an affected version can be confirmed before anyone knows whether a product actually invokes the vulnerable code.
For crypto users, the distinction between “a repository contains an affected dependency” and “a wallet exposes an exploitable path” is enormous.
Vultisig’s October 2 investigation supports the first statement.
It does not support the second.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.