CVE-2026-85221: MISP CurlClient TLS Peer Verification Disabled by Default Enables Man-in-the-Middle Attacks
MISP contains an improper TLS certificate validation vulnerability in CurlClient. The CurlClient::$verifyPeer property was not explicitly initialized and therefore defaulted to null. When passed to cURL, this value effectively disabled TLS peer verification unless the calling code explicitly enabled it.
As a result, HTTPS connections made through affected CurlClient instances could accept certificates that were not issued by a trusted certificate authority. An attacker capable of intercepting or manipulating network traffic between a MISP instance and a remote HTTPS service could impersonate the remote endpoint and perform a man-in-the-middle attack.
Successful exploitation could allow an attacker to observe sensitive information transmitted by MISP, including authentication material or exchanged threat intelligence, and to modify responses returned to the MISP instance. The impact depends on the functionality using CurlClient and the data exchanged with the remote service.
The patch enables TLS peer verification by default while preserving explicit support for configured self-signed certificates. It also corrects the self-signed certificate handling in SyncTool so that peer verification is disabled only when no pinned CA certificate is configured.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure CurlClient TLS peer verification is enabled by default (initialize CurlClient::$verifyPeer so it enables TLS peer verification when passed to cURL). This prevents impersonation/man-in-the-middle where untrusted certificates were accepted.
MISP CurlClient CurlClient::$verifyPeer = enabled (TLS peer verification on by default) - Configuration
Correct SyncTool so that peer verification is disabled only when no pinned CA certificate is configured; otherwise keep peer verification enabled to prevent MITM with untrusted certificates.
MISP SyncTool self-signed certificate handling / peer verification = disable peer verification only when no pinned CA certificate is configured
Event History
Frequently Asked Questions
Which deployments are exposed?
MISP deployments that make HTTPS connections through affected CurlClient instances are exposed unless the calling code explicitly enables TLS peer verification. The practical impact depends on which CurlClient-backed functions are used and the sensitivity of data exchanged with remote services.
What does an attacker need to exploit this issue?
An attacker must be able to intercept or manipulate network traffic between the MISP instance and a remote HTTPS service. This position would let them impersonate the remote endpoint with a certificate not issued by a trusted certificate authority.
What can an attacker do through a successful interception?
The attacker may observe sensitive data sent by MISP, including authentication material and exchanged threat intelligence. They may also modify responses returned to the MISP instance.
What is the relevant remediation behavior for environments using self-signed certificates?
The patch enables TLS peer verification by default while retaining explicit support for configured self-signed certificates. It also corrects self-signed certificate handling in SyncTool so peer verification remains enabled.
How can an administrator assess whether a specific integration is affected?
Identify HTTPS functionality that uses CurlClient and determine whether its calling code explicitly enables TLS peer verification. If verification is not explicitly enabled, the affected default null value could disable peer verification.