You may never have heard of the popular open-source tool curl, but even if you know about it, you may not be aware just how widely your digital life depends on it.
The name is shorthand for client for URLs, because that’s what it is, and was originally styled cURL to reflect this fact.
These days it’s now known simply as curl, all in lower case, because that’s the name of the command-line tool that lets you use it directly.
The curl project’s leader and primary contributor is Daniel Stenberg, who started it way back in 1998, and it consists of two main parts:
curl for web downloads (HTTP and HTTPS), the project optionally supports a huge range of protocols, including FTP, IMAP, LDAP, MQTT, POP3, RTMP, SMTP, and their secure cousins (using TLS or SSH for secure transport). In fact, curl even supports the venerable GOPHER protocol, the early-1990s internet document retrieval system that was superseded by the World Wide Web.
libcurl, so you can take advantage of the product’s features in Bash or PowerShell scripts, or simply to do one-off downloads directly, for example, to fetch the latest version of a software package without using your browser.
As an example, consider this simple command, which uses the current version of curl to find and download the latest Windows release:
curl --follow "https://curl.se/windows/latest.cgi?
p=win64-mingw.zip"
Beware. Don’t try to replace curl.exe in the %SystemRoot%\System32 directory, even if it looks outdated (at the time of writing, this file identified itself as 8.16.0, while the newest release was 8.18.0). That file comes from Microsoft and is managed by Windows Update. For a self-managed curl on Windows, you’ll need to create a directory of your own in which to keep its files.
But curl is much more widespread than just being part of Windows, macOS, and most Linux/BSD distros.
Many Internet of Things (IoT) devices, such as SoHo routers (including those that are secretively locked down and managed by your service provider), include and use curl, because of its power and usefulness.
As the project’s own site points out:
[C]url is used in command lines or scripts to transfer data. [C]url is also libcurl, used in cars, television sets, routers, printers, audio equipment, mobile phones, tablets, medical devices, settop boxes, computer games, media players and is the internet transfer engine for countless software applications in over twenty billion installations.
[C]url is used daily by virtually every Internet-using human on the globe.
Like most modern software packages, curl is vulnerable to what are known in the jargon as supply-chain risks, because it doesn’t implement all the functionality it needs by itself.
Instead, it relies on hooking up with a range of other software projects to provide some of its low-level features.
Some of the dependencies of curl, which can be selected when you build the software from its own source code, include backend libraries for:
example.com to network numbers like 198.51.100.42, and handle Internationized Domain Names (IDNs) such as .δοκιμή, the Greek equivalent of .test.
As a reminder that [a] cryptography is hard, and [b] keeping track of software dependencies is vital, curl‘s latest update patches six security holes, all of which are cryptographic in nature.
And although none of the bugs were down to vulnerabilities in third-party code itself, five of then were tied to specific build-time library combinations.
In other words, how to find out which dependencies were selected when your version of curl was built is a handy thing to know.
The patches were issued to fix the following bugs:
• CVE-2025-15079: Libssh global known_hosts override.
If you had OpenSSH installed on your computer (it’s part of most Linux/BSD distros, macOS, and Windows), and had told the system version to trust specific servers automatically, curl would silently trust those known_hosts, even if you specifically told it not to. Most curl builds use libssh2, where this bug doesn’t apply.
• CVE-2025-15224: Libssh key passphrase bypass without agent set.
If you had OpenSSH running in the background already, and set it up to sidestep authentication for some logins (for example, to support specific automation purposes), curl would also sidestep authentication, even if you specifically told it not to. Most curl builds use libssh2, where this bug doesn’t apply.
• CVE-2025-14819: OpenSSL partial chain store policy bypass.
This bug meant that curl would sometimes trust cryptographic certificates that had been cached in memory for performance reasons, even when asked to verify them fresh every time. (The cache lasts 24 hours, so the unchecked certificates would nevertheless have been fully verified at some point in the past day.) Many if not most Linux builds of curl use OpenSSL, but Windows builds tend to use Schannel, Microsoft’s own cryptographic toolkit.
• CVE-2025-14524: Bearer token leak on cross-protocol redirect.
This esoteric bug caused a cryptographic authentication cookie supplied by one server (essentially a get-straight-in password) to be leaked to another, if a web download using HTTPS was redirected to IMAP, LDAP, POP3, or SMTP. Web cookies of any sort, not just security-critical authentication tokens, are only ever supposed to be submitted to the server that sent them out in the first place. This bug applied to any build that could handle both HTTPS and one or more of the four abovementioned protocols to redirect to, no matter which backend libraries were used.
• CVE-2025-14017: Broken TLS options for threaded LDAPS.
Secure LDAP queries triggered in parallel would all follow the security settings of the most recent lookup started, even if earlier queries had started off by choosing stricter options. LDAP is usually used to look up users and services on a network; indeed, Windows Active Directory is based on it. However, this bug doesn’t apply to curl builds that use Microsoft’s own WinLDAP library, or the popular OpenLDAP alternative. Only builds that stick to the legacy built-in LDAP code in curl are affected.
• CVE-2025-13034: No QUIC certificate pinning with GnuTLS.
When using HTTP/3, downloads that were supposed to be locked to a specific server security certificate (this helps to prevent unexpected “cryptographic snooping” by corporate firewalls or proxies) would accept any valid certificate instead, although invalid certificates would still be rejected. Only curl builds based on ngtcp2/nghttp3 and gnutls were affected.
Update curl as soon as you can.
Windows users who rely on the system version of curl will have to wait for Microsoft to catch up, although the current Windows verion (8.16.0 at the time of writing) appears mostly invulnerable, because it doesn’t use libssh, OpenSSL, legacy LDAP, or gnutls.
As mentioned above, it’s useful to know how to check quickly for the details of which backends any curl build uses, which you can do with the --version option, for example like this:
On Windows: C:\Users\duck> curl --version curl 8.16.0 (Windows) libcurl/8.16.0 Schannel zlib/1.3.1 WinIDN Release-Date: 2025-09-10 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets In theory, this version might be at risk of CVE- 2025-14524, which is a bug that depends on curl code only. But it doesn't seem to use any of the necessary library combinations for the other bugs listed above. On Linux: duck:~$ curl --version curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.4 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 c-ares/1.34.6 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.68.0 nghttp3/1.14.0 mit-krb5/1.22.1 OpenLDAP/2.6.10 Release-Date: 2026-01-07 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd This quickly confirms that none of libssh, legacy LDAP or gnutls are in use. However, all bugs listed above are patched anyway because this is 8.18.0, released this week.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
