CVE-2026-62966 in ESPAsyncWebServer
Summary
by MITRE • 10/30/2026
ESPAsyncWebServer is an asynchronous HTTP and WebSocket server library for ESP32, ESP8266, RP2040 and RP2350. Prior to version 3.11.2, the multipart parser in `src/WebRequest.cpp` frees `_itemBuffer` and sets it to NULL when `BOUNDARY_OR_DATA` matches the closing boundary of a file part, before confirming the following terminator, while leaving `_itemIsFile` true. If the next byte is neither the final closing dashes nor a clean CRLF, the `DASH3_OR_RETURN2` or `EXPECT_FEED2` rewind branch re-injects provisionally consumed bytes through `itemWriteByte`. Because `_itemIsFile` remains true, `_itemBuffer`[`_itemBufferIndex`++] writes through a null pointer. On ESP32 this causes a `StoreProhibited` exception, panic and device reboot, producing remote denial of service. A route with a non-trivial body/upload handler, such as a file-upload or web-OTA endpoint, must be present. This issue is fixed in version 3.11.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The ESPAsyncWebServer library provides asynchronous HTTP and WebSocket capabilities for microcontroller platforms including the ESP32, ESP8266, RP2040, and RP2350. A critical vulnerability exists within the multipart form data parser located in the src/WebRequest.cpp file of versions prior to 3.11.2. This flaw stems from an improper handling of state transitions during the parsing of HTTP requests containing multiple parts, particularly those involving file uploads or web-based over-the-air updates. The issue manifests when the parser encounters a boundary marker that signifies the end of a specific part within a multipart message.
The technical root cause involves a race condition in memory management and pointer validity checks. Specifically, when the parser identifies the closing boundary of a file part while in the BOUNDARY_OR_DATA state, it immediately frees the _itemBuffer memory allocation and sets the corresponding pointer to NULL. Crucially, this action occurs before the system confirms whether the subsequent bytes constitute the proper terminator sequence for the multipart message. At this stage, the internal flag _itemIsFile remains set to true, indicating that the current data stream is still associated with a file upload operation. This creates a dangerous state where the application believes it should continue writing to a buffer that has already been deallocated and nullified.
If the byte immediately following the closing boundary does not match the expected final closing dashes or a clean carriage return line feed sequence, the parser enters one of several rewind branches such as DASH3_OR_RETURN2 or EXPECT_FEED2. These code paths are designed to handle malformed input by re-injecting provisionally consumed bytes back into the parsing stream via the itemWriteByte function. Because _itemIsFile is still true, this function attempts to write data to _itemBuffer at an incremented index position. Since _itemBuffer was previously set to NULL, this operation results in a null pointer dereference. On ESP32 devices, such memory violations trigger a StoreProhibited exception, leading to a system panic and immediate device reboot. This behavior effectively constitutes a remote denial of service attack vector that can be triggered by sending specially crafted HTTP requests with malformed multipart bodies.
The operational impact is severe for any application relying on file upload functionality or web-OTA endpoints using this library. An attacker does not need authentication to exploit this vulnerability; they merely need to send a maliciously formatted request containing a multipart body where the boundary termination sequence is slightly incorrect, such as missing characters or having unexpected whitespace. The resulting device reboot disrupts service availability and can cause data loss if critical operations were in progress during the upload process. This aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities that occur when a program dereferences a pointer that it expects to be valid but is actually null, often leading to crashes or potential code execution depending on memory layout and platform specifics.
Mitigation strategies primarily involve upgrading the ESPAsyncWebServer library to version 3.11.2 or later, where this logic error has been corrected by ensuring proper validation of boundary terminators before freeing buffers. For systems that cannot immediately upgrade, developers should implement strict input validation at a higher layer in their application code to reject malformed multipart requests before they reach the parser. Additionally, enabling watchdog timers and implementing graceful recovery mechanisms can help mitigate the impact of device reboots caused by such exceptions. From an adversarial perspective, this vulnerability maps to ATT&CK technique T1499, Endpoint Denial of Service, as it allows a remote actor to disrupt the availability of embedded network services through resource exhaustion via crash induction rather than traditional volumetric attacks.