CVE-2025-65499
BaseFortify
Publication date: 2025-11-24
Last updated on: 2025-12-01
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| libcoap | libcoap | 4.3.5 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-129 | The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is an array index error in the tls_verify_call_back() function within libcoap version 4.3.5. It occurs because libcoap fails to properly check the return value of the OpenSSL function SSL_get_ex_data_X509_STORE_CTX_idx(). When this function returns -1, indicating an error or initialization failure, libcoap uses this invalid index as an argument to another function, leading to a null pointer dereference and a segmentation fault. This can be triggered remotely via a crafted DTLS handshake, causing the application to crash. [2]
How can this vulnerability impact me? :
The vulnerability can cause a denial of service by crashing applications using libcoap with OpenSSL support during TLS certificate verification. Specifically, a remote attacker can trigger a segmentation fault through a crafted DTLS handshake, leading to a null pointer dereference and application crash. This impacts the stability and availability of affected systems. [2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or segmentation faults (SEGV) in applications using libcoap 4.3.5 with OpenSSL during TLS certificate verification, especially in the tls_verify_call_back() function. AddressSanitizer logs showing crashes inside CRYPTO_get_ex_data() with null pointer dereference are indicative. Additionally, reviewing application logs for DTLS handshake failures or abnormal termination may help. Specific commands to detect this include running the vulnerable application under AddressSanitizer or similar memory error detectors, for example: `ASAN_OPTIONS=detect_stack_use_after_return=1 ./your_libcoap_app` or using `gdb` to catch segmentation faults during DTLS handshakes. Network-level detection is difficult as the issue is triggered by crafted DTLS handshakes causing internal crashes rather than observable network anomalies. [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating libcoap to a version that includes the patch fixing this vulnerability, which adds proper validation of the SSL_get_ex_data_X509_STORE_CTX_idx() return value to prevent null pointer dereference. If updating is not immediately possible, consider disabling or restricting DTLS handshake processing in libcoap-based applications to reduce exposure. Monitoring and restarting affected services upon crash can reduce downtime. Applying the patch from the pull request #1750 (merged September 22, 2025) that adds comprehensive return value checks in coap_openssl.c is recommended to fully address the issue. [1, 2]