CVE-2025-14017
BaseFortify
Publication date: 2026-01-08
Last updated on: 2026-01-16
Assigner: curl
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| curl | libcurl | to 8.17.0 (inc) |
| curl | libcurl | From 7.17.0 (inc) to 8.18.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in libcurl when performing multi-threaded LDAPS (LDAP over TLS) transfers using the legacy non-Windows LDAP backend. Changing TLS options, such as disabling certificate verification in one thread, inadvertently changes these options globally, affecting other concurrent transfers in different threads. This happens due to unsynchronized access to shared TLS configuration data, which is highly timing sensitive. The issue affects libcurl versions from 7.17.0 through 8.17.0 and was fixed in version 8.18.0. [1, 2]
How can this vulnerability impact me? :
The vulnerability can cause TLS options like certificate verification to be disabled unintentionally for other concurrent LDAP transfers in different threads. This could weaken security by allowing connections that should verify certificates to bypass this verification, potentially exposing data to man-in-the-middle attacks or other security risks during LDAPS transfers. It affects applications using libcurl with the legacy LDAP backend in multi-threaded environments. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability affects libcurl versions from 7.17.0 through 8.17.0 when using multi-threaded LDAPS transfers with the legacy non-Windows LDAP backend. Detection involves identifying if your applications use libcurl within this version range and specifically use the legacy LDAP backend for LDAPS transfers. Since the vulnerability is related to unsynchronized TLS option changes in multi-threaded contexts, there are no direct network detection commands. Instead, you can check the libcurl version used by your applications. For example, you can run commands like `ldd <application_binary> | grep curl` to find linked libcurl versions or check application logs/configurations for libcurl version info. Additionally, monitoring for unexpected TLS behavior or certificate verification being disabled across threads might indicate the issue, but no specific commands are provided for direct detection. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading libcurl to version 8.18.0 or later, where the vulnerability is fixed. Alternatively, you can rebuild libcurl to use OpenLDAP instead of the legacy LDAP backend, as the issue does not affect OpenLDAP or WinLDAP builds. Avoiding LDAP usage in your applications is another recommended mitigation. Since the vulnerability arises from unsynchronized TLS option changes in multi-threaded LDAPS transfers, ensuring your applications do not disable certificate verification or change TLS options globally in multi-threaded contexts can help reduce risk until an upgrade is performed. [1]