ESPAsyncWebServer CVE-2026-62966

Exploitation requires the target firmware to have registered a route with a non-trivial body/upload handler - specifically a file-upload or web-OTA endpoint - so the multipart parser path in src/WebRequest.cpp is reachable; devices without such an endpoint are not exploitable. Given that endpoint, no authentication, privileges, or user interaction are needed (PR:N/UI:N): the attacker sends a multipart/form-data request where the closing '--<boundary>' appears after a \r\n in the file body and is followed by a byte that is neither the final '--' nor a clean '\r\n' (e.g. a tab), forcing the DASH3_OR_RETURN2/EXPECT_FEED2 rewind branch to write through the freed NULL _itemBuffer. Limiting factors: impact is confirmed as a StoreProhibited panic/reboot on ESP32 (availability only, no code execution or data access), and the only complete fix per the vendor is upgrading to 3.11.2.

All exploitability signals point the same way: the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N is a remote, low-complexity, unauthenticated path, and PR:N confirms no authentication is required. The GHSA advisory calls the trigger 'deterministic' and supplies a single curl command, so attack complexity is genuinely low. However, impact is strictly availability (C:N/I:N/A:H) - a null-pointer write (CWE-476, with CWE-672 use-after-free as the design root cause) causing a StoreProhibited panic and reboot on ESP32; there is no data disclosure or code execution, so the 7.5 'High' is driven entirely by device crash/DoS. No EPSS score was provided and this CVE is NOT in CISA KEV, so there is no evidence of active exploitation; the vuln.today decision label is 'this_week', not act_now or emergency. The one real constraint is deployment-dependent: exploitation requires the target firmware to register a non-trivial body/upload handler (file-upload or web-OTA endpoint), which is an application design choice, not a default. Net: a credible, easy-to-trigger remote DoS worth patching promptly on affected IoT fleets that expose upload/OTA routes, but it is availability-only and not an emergency given no KEV and no EPSS signal.

An attacker with network reachability to an ESP32 device running a vulnerable firmware upload or web-OTA endpoint sends a multipart/form-data POST whose file part is closed with the boundary followed by a non-terminator byte (e.g. '...hello\r\n--X\tjunk'). The parser has already freed and nulled the item buffer while leaving _itemIsFile true, so the rewind logic writes through the null pointer and panics the device into a reboot. A public PoC reference exists (a deterministic curl command in the GHSA advisory and a regression test in the fix commit); it is not labeled as confirmed working exploit code in the input.