CVE-2026-51266

This is a heap buffer overflow in ESP32 audio library HTTP header construction. The vulnerable code allocates a fixed-size heap buffer (ps_ptr) and then splices variable-length inputs—hostname, path, query string, and HTTP headers—into it without bounds checking. When these concatenated inputs exceed the allocated buffer size, the overflow occurs on the heap, potentially allowing remote code execution if an attacker controls the incoming data stream. The practical risk profile is narrower than the CVSS 9.8 suggests, but not because the vulnerability is hard to exploit. It is specifically exploitable when an ESP32 device using this library makes an outbound HTTP request to attacker-controlled infrastructure—a common pattern in audio streaming applications that fetch streams from remote URLs. The attacker does not need to reach the device; the device reaches the attacker, providing the controlled input needed to overflow the buffer. For defenders, the critical question is whether any deployed firmware contains this library. Unlike conventional software vulnerabilities, this one cannot be patched without potentially breaking the audio streaming functionality itself—the vulnerable code path is not a separate utility, it is the feature. If your product uses an ESP32 audio library to fetch streams from external URLs, you need to identify whether the specific library version is affected and whether a patched version maintains compatibility with your audio source infrastructure. The EPSS score of 0.00626 does not indicate this is harmless. It more likely reflects that exploitation requires specific preconditions (the device must make outbound requests to malicious infrastructure) and that many vulnerable devices are sitting in homes with no update mechanism, never touching honeypots. The low EPSS is a measurement artifact of the IoT deployment model, not an accurate risk signal. The deeper problem is that the ESP32 Arduino toolchain provides no warnings for fixed-buffer-plus-variable-input patterns. If you are building on ESP32 audio libraries, audit any HTTP request construction code for explicit length bounds on the total header, not just individual components. Without explicit size invariants in the documentation or code, assume the library is unsafe for untrusted input sources.

Reviewed through automated stages and approved by a human before publication.