1/3 Security Advisory Title Security Advisory Concerning ECDSA Secure Boot Issue in ESP32-H2 / ESP32-C5 / ESP32-C61 / ESP32-P4 Issue Date 2026/06/24 Advisory Number AR2026-006 Serial Number NA Version V1.0 Issue Summary A vulnerability has been identified affecting the ECDSA-based Secure Boot mechanism on the ESP32-H2, ESP32-C5, ESP32-C61 and ESP32-P4 SoCs. On affected products, the ROM-based ECDSA signature verification step may return a successful result for an invalid signature, allowing an attacker who can replace the signed firmware image in flash memory to bypass ECDSA Secure Boot. On all four products, the ECDSA Secure Boot verification workflow in the chip does not sufficiently validate that the supplied (r, s) signature components lie within the valid range defined by the elliptic curve (1 ≤ r, s ≤ n − 1). In addition, on ESP32-C5, the ECDSA peripheral is not correctly initialized in the ROM code prior to signature verification, leaving the underlying ECC peripheral in a power-down state during the operation. In both cases, signatures that are not valid for the firmware contents can be accepted as valid by the verification step. Exploitation in practice requires the attacker to be able to manipulate the signed firmware image including its signature field — in the external flash memory used at boot. This requires either supply-chain access or physical access to the device combined with the ability to write the external flash. Impact Analysis 1. Exploitation requires the attacker to be able to manipulate the signed firmware image, including its signature field, in external flash memory. This requires supply-chain access or physical access combined with flash write capability. Devices that never leave a trusted environment, and that do not present a flash-modification attack surface, are not exposed to this attack chain. 2/3 2. Where the attack chain succeeds, an attacker-supplied firmware image is accepted at boot and executes the same privileges as legitimate firmware. The downstream impact depends on the device's broader security model. 3. The use of Espressif products in System-in-Package (SiP) form factor makes physical access to the flash substantially harder, since the flash die is enclosed within the package and cannot be reached without decapsulation. In combination with Secure UART download mode enabled or UART download mode permanently disabled, this makes it difficult for an attacker to reprogram the flash. 4. The use of Flash Encryption (XTS-AES) alongside Secure Boot adds a further layer of defense. When encrypted writes through UART download mode are disabled, an attacker who can physically access the flash must first attack the XTS-AES Flash Encryption scheme before any modification to the flash contents can be made effective. 5. ECDSA verification from the application layer is not affected, since the ECDSA driver ensures correct peripheral initialization and validation for the input signature components. Hence, the OTA update path based on the ECDSA secure verification is not affected. Affected Espressif Products Series: This issue has been confirmed on ESP32-H2 (up-to chip revision v1.2), ESP32-C5 (up-to chip revision v1.2), ESP32-C61 (up-to chip revision v1.1), and ESP32-P4 (up-to chip revision v3.2). The hardware fix for this issue will be included in future tape-outs. Other Espressif products supporting ECDSA Secure Boot like ESP32-C2 and ESP32-C6 are not affected by this issue as they do not include the ECDSA hardware peripheral (only features ECC accelerator). Mitigation At present, there is no software fix available for this issue on currently affected SoCs. ROM-level updates and hardware fixes in future tape-outs are planned. Hardware Countermeasures Using Espressif products in System-in-Package (SiP) form factor with flash pins internally terminated adds an extra layer of defense by making it harder for an attacker to physically access, read, or modify the flash memory. Please contact Espressif support for SiP availability across affected target SoCs. 3/3 Enabling Flash Encryption (XTS-AES) in Release mode alongside Secure Boot, together with either Secure UART download mode enabled or UART download mode permanently disabled, further raises the bar: in this configuration, an attacker must first recover the XTS-AES Flash Encryption key before any modification to the flash contents can be made effective. Application Countermeasures The recommended mitigation is to configure Secure Boot to use RSA signatures instead of ECDSA for the new production batches. RSA-based Secure Boot is not affected by this issue and remains a fully supported firmware authentication mechanism on the affected products. For already-deployed products, migration from ECDSA to RSA-based Secure Boot is possible provided that the device has a non-revoked Secure Boot eFuse digest block available. For the detailed workflow and the associated risks during OTA update-based migration, please reach out to Espressif support. For ESP32-C61, ECDSA secure boot is the only supported scheme and hence there is no application countermeasure. For the affected products, the ECDSA Secure Boot feature in ESP-IDF is now gated by explicit Kconfig options and accompanied by a security warning highlighting the associated risks. To enable the feature, users must explicitly set both CONFIG_SECURE_BOOT_INSECURE and CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA, as shown below.