CVE-2026-82208: Haxx Curl Information Disclosure Flaw

CVE-2026-82208 Overview

CVE-2026-82208 affects libcurl when built with the wolfSSL backend. When certificate authority (CA) caching is enabled and an application installs a CURLOPT_SSL_CTX_FUNCTION callback to replace the trust store, libcurl silently reinstalls the cached CA store after the callback returns. This causes certificates trusted by the cached store but rejected by the callback-selected store to be incorrectly accepted, breaking the application's intended trust boundary. The flaw maps to CWE-295 Improper Certificate Validation and impacts confidentiality without affecting integrity or availability directly. Applications relying on custom trust stores for pinning, sandboxing, or per-connection trust decisions face silent bypass of their security policy.

Critical Impact
A remote attacker presenting a certificate valid under the cached CA store, but explicitly untrusted by the callback-installed store, can establish an authenticated TLS session with the affected client.

Affected Products

Haxx curl / libcurl compiled with the wolfSSL TLS backend
Deployments with CA certificate caching enabled
Applications using CURLOPT_SSL_CTX_FUNCTION to override the trust store per handle

Discovery Timeline

2026-09-06 - CVE-2026-82208 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-82208

Vulnerability Analysis

libcurl exposes CURLOPT_SSL_CTX_FUNCTION so applications can customize the underlying TLS context before a handshake. With the wolfSSL backend, developers commonly use this hook to install a narrower trust store than the system default, enforcing certificate pinning or per-endpoint trust decisions. When CA caching is enabled, libcurl caches the CA store associated with the handle to avoid reparsing certificates on subsequent transfers. The defect is an ordering flaw: after the application callback returns with a modified WOLFSSL_CTX, libcurl reapplies the cached CA store, overwriting the callback's changes. The handshake then proceeds against the original cached trust anchors, not the ones the application selected.

Root Cause

The wolfSSL backend performs its cached-store restoration step unconditionally, without recording that the application callback replaced the trust store. There is no reconciliation between callback-modified state and the cached CA data, so any narrowing performed by the callback is silently reverted. See the curl.se CVE-2026-82208 advisory for the maintainer's technical description.

Attack Vector

Exploitation requires an attacker to control a TLS endpoint that the affected client connects to, and to possess a certificate chain valid under the cached CA store. The attacker does not need to bypass the callback-installed store directly. Because the reinstall happens transparently, no protocol-level anomaly is generated. Applications enforcing certificate pinning through the callback, or sandboxing outbound TLS to a specific internal CA, will validate the attacker's chain as trusted. Refer to HackerOne Report #3973090 for reporter details.

Detection Methods for CVE-2026-82208

Indicators of Compromise

Successful TLS handshakes from libcurl-based clients to hosts presenting certificates signed by CAs the application intended to exclude.
Outbound HTTPS connections to endpoints not on the application's expected allow-list, originating from processes linked against libcurl with wolfSSL.
Absence of the expected certificate-validation failure logs from applications that rely on callback-installed pinning.

Detection Strategies

Inventory binaries and containers to identify libcurl builds linked against wolfSSL with CURL_CA_CACHE_TIMEOUT or equivalent caching enabled.
Compare TLS session logs against the application's intended trust store to identify chains that should have been rejected.
Instrument applications to log the CA store contents actually used by wolfSSL at handshake time and alert on divergence from the callback-installed set.

Monitoring Recommendations

Capture and review TLS server certificates seen by libcurl-based clients using egress inspection or endpoint telemetry.
Alert on connections to unexpected destinations from processes that should only reach a fixed set of pinned services.
Track process-to-domain baselines for services using libcurl and flag deviations for review.

How to Mitigate CVE-2026-82208

Immediate Actions Required

Upgrade libcurl to the fixed version referenced in the curl.se CVE-2026-82208 advisory as soon as it is available for your distribution.
Audit applications that use CURLOPT_SSL_CTX_FUNCTION with the wolfSSL backend and disable CA caching until patched.
Re-verify certificate pinning behavior end-to-end after applying the patch.

Patch Information

Haxx has published the vulnerability details and fix guidance in the official curl advisory and its machine-readable JSON manifest. Apply the fixed libcurl release from your distribution or rebuild from upstream sources once the patched version is available. Ensure all statically linked binaries and container images that bundle libcurl are rebuilt against the fixed version.

Workarounds

Disable CA certificate caching in libcurl by setting CURLOPT_CA_CACHE_TIMEOUT to 0 on affected handles.
Switch the TLS backend from wolfSSL to an unaffected backend where operationally feasible.
Enforce trust store restrictions outside libcurl, for example via an egress proxy that terminates TLS with the intended CA set.

bash

# Disable libcurl CA cache to prevent silent trust-store reinstall
# Apply on every easy handle that uses CURLOPT_SSL_CTX_FUNCTION
curl_easy_setopt(handle, CURLOPT_CA_CACHE_TIMEOUT, 0L);