CVE-2025-14819: 
cURL vulnerability analysis and mitigation

CVE-2025-14819 is an OpenSSL partial chain store policy bypass vulnerability in libcurl, classified as CWE-295 (Improper Certificate Validation). It affects libcurl versions 7.87.0 through 8.17.0 (inclusive) when using the OpenSSL backend. The flaw was reported on December 16, 2025 by Stanislav Fort of Aisle Research, and publicly disclosed alongside the release of curl 8.18.0 on January 7, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (curl Advisory, Openwall).

The root cause (CWE-295) lies in libcurl's OpenSSL backend CA store caching mechanism, which holds loaded CA stores in memory for up to 24 hours as a performance optimization. When an application reuses easy or multi handles across transfers and toggles the CURLSSLOPT_NO_PARTIALCHAIN option (which controls whether the OpenSSL store flag X509_V_FLAG_PARTIAL_CHAIN is set), libcurl may incorrectly reuse a cached CA store that has the partial chain setting reversed from what the current transfer expects. This causes libcurl to accept certificate trust chains it would otherwise reject. The flaw only manifests when: (1) libcurl is compiled against OpenSSL or an OpenSSL fork, (2) CA caching is enabled (i.e., CURLOPT_CA_CACHE_TIMEOUT is not set to zero), and (3) the CURLSSLOPT_NO_PARTIALCHAIN option is altered between transfers on reused handles. The curl command-line tool is not affected; only applications using libcurl programmatically are at risk (curl Advisory, Openwall).

Exploitation could allow a network-positioned attacker performing a man-in-the-middle attack to present a partial or otherwise invalid certificate chain that libcurl would normally reject, causing the library to accept it as trusted. This results in high confidentiality impact — sensitive data such as credentials or session tokens transmitted over what the application believes is a verified HTTPS connection could be intercepted. Integrity and availability are not directly impacted. The vulnerability is limited to applications that programmatically toggle CURLSSLOPT_NO_PARTIALCHAIN across reused handles, which is described as rare in practice (curl Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure; the curl security team explicitly confirmed this (curl Advisory). The EPSS score is approximately 0.015% (0.000150), reflecting very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires network-level positioning (man-in-the-middle), user interaction, and high attack complexity, further limiting practical exploitability (Feedly).

The primary remediation is to upgrade libcurl to version 8.18.0 or later, which contains the fix committed by Daniel Stenberg (curl Advisory). If immediate upgrade is not feasible, three workarounds are available:

• A: Upgrade to curl/libcurl 8.18.0 or later.
• B: Avoid using the CURLSSLOPT_NO_PARTIALCHAIN option, particularly when toggling it across different transfers on reused handles.
• C: Disable CA store caching by setting CURLOPT_CA_CACHE_TIMEOUT to zero, which prevents the stale cached store from being reused.

Additionally, auditing code that modifies CURLSSLOPT_NO_PARTIALCHAIN across multiple transfers using reused handles is recommended. Downstream distributions including SUSE, Slackware, Mageia, Ubuntu, Amazon Linux 2, and FreeBSD have released updated packages (Openwall).

The curl project's lead developer Daniel Stenberg announced the release of curl 8.18.0 and the advisory on his blog, coordinating disclosure with the fix (Daniel Stenberg Blog). The vulnerability received coverage from Linux security news outlets and was picked up by Tenable's Nessus and Qualys scanners shortly after disclosure. Community discussion on Reddit noted the impact on applications like Notepad++ (which subsequently released v8.9.3 to address the bundled libcurl), and the vulnerability was referenced in a Hacker News-style weekly security recap (The Hacker News). Overall community sentiment treated this as a low-severity but noteworthy supply-chain concern given libcurl's ubiquitous use across software ecosystems.