CVE-2025-14819
BaseFortify
Publication date: 2026-01-08
Last updated on: 2026-01-20
Assigner: curl
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| haxx | curl | From 7.87.0 (inc) to 8.18.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-295 | The product does not validate, or incorrectly validates, a certificate. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in libcurl's OpenSSL backend occurs when TLS transfers reuse easy or multi handles and the CURLSSLOPT_NO_PARTIALCHAIN option is toggled. Libcurl caches the CA store in memory for performance, but due to this flaw, it may reuse a cached CA store with the partial chain option reversed. This causes libcurl to accept a trust chain that it normally would reject, contrary to user expectations. It affects libcurl versions 7.87.0 through 8.17.0 and only applies if CA caching is enabled. The issue is classified as improper certificate validation (CWE-295) with low severity. [1, 2]
How can this vulnerability impact me? :
The vulnerability can cause libcurl to accept TLS certificate chains that it should reject, potentially allowing connections to servers with incomplete or improperly validated certificate chains. This could undermine the security of TLS connections by trusting certificates that do not fully meet validation criteria, possibly exposing users to man-in-the-middle attacks or other security risks. However, libcurl still performs certificate verification and returns errors if verification fails, so the impact is limited to acceptance of partial trust chains that would otherwise be rejected. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
There are no specific detection commands or network/system detection methods provided for this vulnerability. The issue relates to libcurl's internal handling of TLS certificate validation when reusing handles with the CURLSSLOPT_NO_PARTIALCHAIN option and CA caching enabled. Detection would likely require auditing libcurl versions and configurations rather than network commands.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, immediately upgrade libcurl to version 8.18.0 or later where the issue is fixed. Alternatively, avoid using the CURLSSLOPT_NO_PARTIALCHAIN option and disable CA caching by setting CURLOPT_CA_CACHE_TIMEOUT to zero. These steps prevent libcurl from reusing a cached CA store with reversed partial chain options, thus maintaining proper certificate validation. [1]