curl / libcurl: FTP connection reuse applies wrong client certificate identity

Summary

A transfer with ftp:// and CURLUSESSL_NONE can reuse a pooled FTP control connection that an earlier handle upgraded with STARTTLS and authenticated with a client certificate. The server then treats the second transfer under the first certificate identity, so it can access data with the wrong identity. The flaw only occurs when an application shares a connection pool across transfers with different identities and uses FTP with client certificates. The NVD CVSS 9.1 score is contested: curl rates the issue as Low, and Vulners shows 7.5.

Affected

• curl 8.21.0 (vendor advisory; default builds of other versions are not affected)
• Unknown: the exact affected range is disputed in secondary sources (some name 8.22.0 or earlier versions)
• Distribution packages may use backported fixes; check each vendor separately

Fixed in

• curl 8.22.0 (vendor advisory)
• Some secondary sources name curl 8.23.0 as the fixed release; use 8.23.0 or later if available
• Fix commit: 72352daba01ba8072b6c1c0254cb77860ed1ab06

Workaround

• Do not use client certificates for FTP transfers (vendor recommendation)
• Keep FTP transfers with and without client certificates in separate connection pools (from the AISLE audit report; the sentence is truncated in the source, so verify it before applying)

Exploitation

• CISA SSVC lists exploitation as "poc" (proof of concept exists) and automatable as "no"
• Not listed as known exploited in the KEV catalog
• No evidence of in-the-wild exploitation found

Our recommendation

• Check whether any curl or libcurl installation uses FTP with client certificates, for example in scripts, backup jobs or custom applications
• Upgrade curl and libcurl to 8.22.0 or later, or to the backported version of your distribution; check upgrade compatibility first, because 8.23.0 removes SMB and SMBS support
• Until patched, stop using client certificates for FTP and separate connection pools by identity
• Treat this as a medium-priority patch in your own environment, not as a critical emergency, unless your use case matches the exposure described above

Public exploits iAttack code is publicly available (PoC on GitHub, Metasploit or Exploit-DB).

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

• curl security advisory CVE-2026-86411 curl.se
• curl CVE metadata JSON CVE-2026-86411 curl.se
• curl vendor announcement (lib-2026-10) curl.se
• OSV entry CURL-CVE-2026-86411 osv.dev
• HackerOne report 3973190 hackerone.com
• AISLE curl audit security report curl.se
• curl pull request 21665 (SSL-use matching in connection reuse) github.com
• Cybersecurity News: curl security update (24 vulnerabilities) cybersecuritynews.com

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 06:13.