CVE-2026-85221 in MISP
Summary
by MITRE • 09/03/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
MISP, a widely deployed open-source platform for sharing threat intelligence and cybersecurity data, contains a critical security flaw within its CurlClient component related to Transport Layer Security (TLS) implementation. The vulnerability stems from the improper initialization of the verifyPeer property in the CurlClient class. In PHP environments utilizing cURL extensions, this specific configuration parameter dictates whether the client verifies that the remote server's SSL certificate is signed by a trusted Certificate Authority. Due to a coding oversight, this property was not explicitly initialized with a boolean true value during object instantiation or default configuration. Consequently, it defaulted to null, which cURL interprets as an instruction to disable peer verification entirely unless overridden by subsequent code logic that might be absent in many operational contexts. This design flaw effectively strips the TLS handshake of its primary mechanism for authenticating server identity, leaving the communication channel vulnerable to interception and manipulation.
The technical consequence of this misconfiguration is a severe degradation of transport security. When CurlClient instances are instantiated without explicit verification settings, any HTTPS connection established through them will accept certificates that have not been issued by a trusted root CA or self-signed certificates presented as valid trust anchors. This behavior violates fundamental principles of secure network communication defined in industry standards such as CWE-295 Improper Certificate Validation and aligns with the MITM (Man-in-the-Middle) attack vectors described in the ATT&CK framework under techniques like T1078 Valid Accounts or more broadly under interception tactics where trust is established through compromised or spoofed identities. An attacker positioned within the network path between a MISP instance and an external threat intelligence feed, API endpoint, or synchronization partner can exploit this lack of verification to perform active man-in-the-middle attacks. By presenting a fraudulent certificate signed by their own CA or exploiting wildcard certificates with mismatched domains if validation is lax, the attacker can intercept traffic without triggering standard browser or client warnings that would otherwise alert users to security anomalies in non-programmatic interfaces.
The operational impact of this vulnerability is significant given MISP's role as a central hub for sensitive cybersecurity data. Successful exploitation allows an adversary to observe all unencrypted-looking TLS traffic passing through the affected CurlClient instances. This includes highly sensitive authentication credentials, API keys used to access external intelligence sources, and the actual threat indicators such as IP addresses, domain names, file hashes, or malware samples being shared or synchronized. Beyond passive eavesdropping, an attacker with this level of control can modify responses returned by remote services before they reach MISP. This capability enables data injection attacks where false threat intelligence is introduced into the platform, potentially leading to incorrect security decisions across all connected organizations that consume feeds from the compromised instance. It also allows for credential harvesting if login forms or API authentication exchanges are intercepted and replayed later. The severity of the impact varies depending on which specific MISP functionality utilizes CurlClient at the time of exploitation, but the potential for both data exfiltration and integrity compromise remains high across most integration points.
To mitigate this vulnerability, immediate action is required to enforce strict TLS verification policies within the application codebase. The primary remediation involves ensuring that the verifyPeer property in CurlClient is explicitly set to true by default during initialization or configuration loading processes. This ensures that every HTTPS connection validates the server's certificate against a trusted list of Certificate Authorities before establishing communication. Furthermore, organizations relying on internal infrastructure with self-signed certificates must implement proper CA pinning practices rather than disabling verification entirely. The provided patch addresses these issues by enabling TLS peer verification as the default state while preserving necessary functionality for environments that require explicit configuration of custom or self-signed certificate authorities through pinned CA certificates. Administrators should update their MISP instances to include this fix and verify that any custom integrations or scripts utilizing CurlClient explicitly enforce certificate validation settings. Regular audits of network configurations and TLS implementations are recommended to ensure compliance with security best practices and prevent similar misconfigurations in future development cycles.