CVE-2026-85221

MISP's CurlClient never initialized the setting that tells cURL to verify TLS peer certificates, so it passed null and effectively disabled peer verification for HTTPS connections made through affected instances unless calling code explicitly enabled it. An attacker who can intercept or manipulate network traffic between a MISP instance and a remote HTTPS service - typically an adjacent or on-path network position, per the CVSS 4.0 vector - can present an untrusted certificate, impersonate the remote endpoint, and mount a man-in-the-middle attack. A successful attack can expose authentication material and exchanged threat intelligence and lets the attacker modify responses returned to the MISP instance; CVSS 4.0 rates this 7.6 (High), and the patched code enables TLS peer verification by default while preserving configured self-signed/pinned CA support. Any MISP deployment running affected code and using the CurlClient path for outbound HTTPS is exposed - mainly SOC, CSIRT and threat-intelligence-sharing operators - with impact depending on which functionality uses the client and what data it exchanges. Exploitation is not currently known: no public proof-of-concept, not in CISA KEV, and EPSS is 0.1%.

What to do: Upgrade MISP to a release containing the patch (which initializes TLS peer verification to enabled by default and corrects SyncTool's handling so verification is only disabled when no pinned CA certificate is configured); no fixed version number is given in this advisory, so track the MISP repository or vendor advisory for the patched release. As interim mitigation, explicitly enable TLS peer verification wherever CurlClient is instantiated, configure a trusted CA bundle or pinned CA certificate, and keep inter-instance sync and other outbound HTTPS traffic on trusted network paths. Review what authentication material and threat-intelligence data MISP sends to remote HTTPS services, since an on-path attacker could read or modify it until the fix is applied.