CVE-2026-45541: 
Espressif ESP-IDF Tools vulnerability analysis and mitigation

CVE-2026-45541 is a NULL pointer dereference vulnerability in the WebSocket subprotocol-negotiation path of the esp_http_server component within Espressif's ESP-IDF (IoT Development Framework). A remote, unauthenticated attacker can crash the HTTP server by sending a malformed Sec-WebSocket-Protocol request header during the WebSocket handshake, before any application-level authentication runs. Affected versions are ESP-IDF 5.2.6, 5.3.5, 5.4.4, 5.5.4, and 6.0; patched versions are 5.2.7, 5.3.6, 5.4.5, 5.5.5, and 6.0.1. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is a CWE-476 (NULL Pointer Dereference) in the httpd_ws_get_response_subprotocol() function located in components/esp_http_server/src/httpd_ws.c. The vulnerable code used a do...while loop that called strtok_r() to tokenize the client-supplied Sec-WebSocket-Protocol header, then immediately dereferenced the result with strncmp() without first checking whether the tokenization returned NULL — which occurs when the header value is empty or malformed. An attacker with network access to the HTTP(S) server endpoint can trigger this crash by sending a crafted WebSocket upgrade request with a malformed Sec-WebSocket-Protocol header value; notably, server-side TLS does not mitigate the issue because the vulnerable parser executes during the WebSocket handshake before TLS-level authentication completes. The flaw is only reachable when the application is built with WebSocket support enabled and registers at least one WebSocket URI handler with a non-NULL supported_subprotocol field (GitHub Advisory, Patch Commit).

Successful exploitation results in a denial-of-service condition — the target ESP device's HTTP server crashes (faults), rendering it unresponsive. There is no confidentiality or integrity impact; no data is disclosed and no write side-effects occur. Because ESP-IDF targets embedded IoT devices (e.g., ESP32 microcontrollers), a crash can disrupt physical systems or services dependent on the device, and recovery typically requires a device reboot (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is exploitable by any unauthenticated network attacker who can reach the HTTP server endpoint, requiring no privileges or user interaction, which lowers the practical barrier to exploitation. The EPSS score is approximately 0.121%, indicating a low (but non-zero) probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify ESP-IDF-based IoT devices running an HTTP server with WebSocket support enabled (e.g., via network scanning for open HTTP/HTTPS ports on embedded devices, or by inspecting device firmware/documentation for ESP-IDF version and WebSocket handler configuration).
2. Confirm precondition: Verify the target application registers at least one WebSocket URI handler with a non-NULL supported_subprotocol field — this is required for the vulnerable code path to be reached.
3. Craft malicious WebSocket upgrade request: Construct an HTTP upgrade request to a WebSocket endpoint on the target device, including a malformed or empty Sec-WebSocket-Protocol header (e.g., Sec-WebSocket-Protocol: with no value, or a value that causes strtok_r() to return NULL on the first call).
4. Send the request: Transmit the crafted HTTP upgrade request to the target device's HTTP server port (typically port 80 or 443) using any standard HTTP client or custom socket code.
5. Trigger crash: The server's httpd_ws_get_response_subprotocol() function dereferences the NULL result from strtok_r() without a NULL check, causing a fault and crashing the HTTP server process, resulting in a denial-of-service condition (GitHub Advisory).

• Network: Repeated WebSocket upgrade requests (HTTP GET with Upgrade: websocket and Connection: Upgrade headers) to WebSocket-enabled endpoints on ESP-IDF devices, particularly with malformed, empty, or unusual Sec-WebSocket-Protocol header values.
• Logs: ESP-IDF system logs showing unexpected fault/crash events or watchdog resets correlated with incoming WebSocket connection attempts; log entries from esp_http_server component indicating errors during WebSocket handshake processing.
• Device Behavior: Sudden unresponsiveness or reboot of ESP-IDF-based devices following network activity on HTTP/HTTPS ports, especially if the device restarts without a user-initiated action (GitHub Advisory).

Espressif has released patched versions addressing this vulnerability: upgrade ESP-IDF to 5.2.7, 5.3.6, 5.4.5, 5.5.5, or 6.0.1 depending on your current branch. If an immediate upgrade is not possible, two interim workarounds are available: (1) register WebSocket URI handlers without subprotocol negotiation by leaving supported_subprotocol as NULL, which prevents the vulnerable code path from being entered; or (2) enable mutual TLS authentication on the HTTPS server so untrusted clients are rejected during the TLS handshake before the WebSocket parser is reached. Network-level controls restricting access to the HTTP server endpoint can also reduce exposure (GitHub Advisory, Feedly).

The vulnerability was reported by security researcher Eun0us / Espilon Worker through responsible disclosure, and Espressif credited them in the official GitHub Security Advisory (GitHub Advisory). The advisory was published on May 15, 2026, with patches committed on June 11, 2026. The vulnerability received routine coverage from vulnerability tracking services (CVEFeed, VulnDB, CIRCL) and was included in a CISA vulnerability bulletin (SB26-166), but no significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.