CVE-2025-65500 identifies a NULL pointer dereference vulnerability in the coap_dtls_generate_cookie() function within the src/coap_openssl.c file of OISM libcoap version 4.3.5. The vulnerability arises during the DTLS handshake process, where a crafted handshake message can cause the SSL_get_SSL_CTX() function to return a NULL pointer. This NULL pointer is then dereferenced, leading to a denial of service (DoS) condition by crashing the affected application. The flaw is classified under CWE-476 (NULL Pointer Dereference). The vulnerability can be triggered remotely without any authentication privileges, but it requires user interaction in the form of initiating a DTLS handshake. The CVSS v3.1 base score is 4.3, indicating medium severity, with attack vector network (AV:N), low attack complexity (AC:L), no privileges required (PR:N), user interaction required (UI:R), unchanged scope (S:U), no impact on confidentiality or integrity (C:N/I:N), and low impact on availability (A:L). No patches or known exploits are currently available. The vulnerability primarily affects systems using libcoap 4.3.5 with OpenSSL for DTLS communication, commonly found in IoT devices and constrained environments where CoAP protocol is used for secure communication.

The primary impact of CVE-2025-65500 is a denial of service condition caused by application crashes during DTLS handshakes. For European organizations, especially those deploying IoT devices, industrial control systems, or constrained network environments that utilize libcoap for secure communications, this vulnerability could lead to service interruptions and potential operational disruptions. While confidentiality and integrity are not directly affected, availability degradation can impact critical infrastructure, automated systems, and real-time monitoring solutions. The ease of remote exploitation without authentication increases the risk of widespread DoS attacks if exposed to untrusted networks. Organizations relying on libcoap-based DTLS implementations in sectors such as manufacturing, energy, healthcare, and smart city infrastructure may face increased operational risks. The absence of known exploits currently reduces immediate threat but does not eliminate the risk of future exploitation once the vulnerability becomes publicly known.

1. Monitor network traffic for abnormal DTLS handshake failures or repeated connection resets that may indicate exploitation attempts. 2. Implement network segmentation and firewall rules to restrict access to devices running libcoap DTLS services from untrusted or external networks. 3. Deploy intrusion detection/prevention systems (IDS/IPS) with signatures or anomaly detection tuned to DTLS handshake anomalies. 4. Once available, promptly apply official patches or updates from the libcoap project or affected vendors addressing this vulnerability. 5. For critical systems, consider temporary mitigations such as disabling DTLS if feasible or using alternative secure communication protocols until patches are applied. 6. Conduct security assessments and penetration testing focused on DTLS implementations to identify and remediate similar weaknesses. 7. Maintain an inventory of devices and software versions using libcoap to prioritize patching and risk management efforts. 8. Educate network and security teams about this vulnerability to improve detection and response capabilities.