CVE-2021-3331 is a critical remote code execution vulnerability in WinSCP versions before 5.17.10, where a crafted sftp:// (or similar) URL can load malicious session settings that cause the client to launch an arbitrary program. It carries a CVSS score of 9.8. Because WinSCP commonly registers itself as the default handler for its protocol URLs, a victim clicking a single malicious link could trigger code execution. If you deploy WinSCP on Windows fleets, confirm the version.
What WinSCP is and why the URL handler matters
WinSCP is a widely used open-source SFTP, FTP, SCP, and WebDAV client for Windows. During installation it can register itself as the handler for protocol URLs such as sftp://. When registered, clicking a link with that scheme in a browser, email client, or document opens WinSCP and passes the URL to it.
That handoff is the attack surface. WinSCP supports "raw settings" — a rich set of configuration directives that can be encoded directly into a session URL. Some of those directives can point at external programs. The idea was to make sessions portable and scriptable, but it meant the URL string could carry powerful configuration into the client.
How the vulnerability works
Before version 5.17.10, WinSCP did not adequately restrict which session settings could be loaded from a URL. An attacker could embed raw settings in a crafted URL that specify an external program to run. When WinSCP parsed the URL as a session definition, it would honor those directives and execute the attacker-specified program.
The dangerous part is the delivery. Because the client is registered as the protocol handler, the exploit doesn't require the victim to already have WinSCP open or to import a file manually. Clicking a malicious link — in a phishing email, a web page, or an embedded document — is enough to hand the crafted URL to WinSCP and trigger the behavior. That low interaction requirement, combined with arbitrary program execution, is what puts it in the critical band at CVSS 9.8.
This is a defensive write-up: the point is to recognize and remediate the exposure, not to reproduce it. There is no working payload here, and building one against real users would be an attack, not a test.
Affected versions and the fix
CVE-2021-3331 affects WinSCP prior to 5.17.10. Version 5.17.10 contains the fix, which restricts which session settings can be loaded from URLs so that malicious raw settings can no longer specify programs to execute.
The remediation is straightforward: upgrade to 5.17.10 or later. Given how far back this release is, any currently maintained WinSCP version is well past the fix, so the practical advice is to run a recent supported release rather than pinning to the exact patched build.
Check the installed version:
# PowerShell: read the version from the installed executable
(Get-Item "C:\Program Files (x86)\WinSCP\WinSCP.exe").VersionInfo.ProductVersion
For managed fleets, query your software inventory or endpoint management tooling for all WinSCP installs and their versions so you can find stragglers on unmanaged or forgotten machines.
Remediation and hardening
- Upgrade every install to a current release. Push the update through your normal software distribution channel and confirm coverage against your inventory.
- Review the protocol handler registration. If your users don't need WinSCP to open
sftp://links from browsers and email, consider not registering it as the default handler, which shrinks the click-to-execute surface. - Reinforce link hygiene. This exploit relies on a user clicking an attacker-controlled link. Standard phishing awareness and email link protection reduce the delivery odds.
- Watch privileged access management setups. Some PAM products (CyberArk PSM among them) bundle or invoke WinSCP, so check whether an embedded copy needs updating separately from user installs.
Upgrading is the real fix; the handler and hygiene steps are defense in depth for the delivery vector.
The broader lesson: desktop tools are supply chain too
CVE-2021-3331 is a useful reminder that your software supply chain is not only the libraries compiled into your services. It includes the desktop tools your developers and operators run, many of which are installed once and never updated. A three-year-old WinSCP on an engineer's laptop is exactly the kind of asset that never shows up in an application dependency scan yet holds credentials to production systems.
Keeping an inventory of installed developer and operations tooling, and checking those versions against known CVEs, closes a gap that manifest-level scanning alone will miss. Whether you do that through endpoint management or a broader asset-tracking process, the principle is the same: if it runs on a machine that touches your infrastructure, its version matters. Our security academy covers building that kind of continuous inventory habit.
FAQ
How is CVE-2021-3331 triggered?
Through a crafted protocol URL (such as sftp://) containing malicious raw session settings. When WinSCP — registered as the URL handler — parses the link, older versions honored settings that could launch an external program, resulting in code execution.
Which WinSCP version fixes it?
Version 5.17.10 and later. The fix restricts which session settings can be loaded from URLs. Any currently maintained release is well past this, so upgrading to a recent version resolves it.
Do I need user interaction for the exploit?
Yes, but very little — clicking a malicious link is enough when WinSCP is the registered protocol handler. There is no further manual import step required, which is why the severity is critical (CVSS 9.8).
How do I find vulnerable installs across my organization?
Query your software inventory or endpoint management platform for all WinSCP installations and their versions. Pay attention to unmanaged laptops and bundled copies inside other tools, such as privileged access management products, which are easy to overlook.