The CVE claims arbitrary code execution with CVSS 7.8, but treat that with skepticism. This is a bitstream parser underflow in the ESP32-audioI2S library's GetBits() function — when the caller requests more bits than exist in the internal buffer, the subtraction wraps (unsigned) or goes negative (signed), poisoning every subsequent bit read. The decoder walks off the stream, returns garbage, and typically crashes.
The ACE claim ignores ESP32's structural barriers. Xtensa LX6 cores have no traditional DEP — code can execute from RAM under certain conditions, and the memory map is relatively flat. But exploiting a bitstream underflow here requires chaining through decoder state corruption into a function pointer overwrite or heap spray on a device running FreeRTOS without heap hardening. That's a high bar. The more realistic risk is denial of service: malformed MP3 frames reliably crash the device, which matters in industrial or IoT audio contexts.
What actually matters for prioritisation is the trust boundary. Ask: does this decoder process untrusted network streams (DLNA/UPnP, streaming servers) or only locally stored, curated files? If untrusted data reaches the decoder, even a crash vector becomes significant — a device that can be bricked by malicious input in a speaker, alarm, or industrial audio system is a real operational risk. If it's only local playback, the attack requires attacker's-code-already-on-device, which dramatically changes the risk profile. The CVE description is silent on this, and that's the gap you should fill in your assessment.
On ESP32, assume this vulnerability exists in any prior version where GetBits() was present — firmware images in the field almost never get updated, especially in commercial IoT products that have moved past active support. Even when a patch lands, the remediation gap to deployed hardware is measured in quarters, not days.