#47: ESP32 ECDSA Secure Boot Bypass on the H2, C5, C61, and P4
Espressif just published a security advisory (AR2026-006) about a flaw in the ECDSA-based Secure Boot mechanism on four SoCs: the ESP32-H2, ESP32-C5, ESP32-C61, and ESP32-P4. The short version is that the ROM signature check can accept a bad signature as valid, which means an attacker who can swap out your firmware image in flash could slip past Secure Boot entirely. Let’s break down what’s actually going on and whether you need to do anything about it.
Before reading on, if you use RSA for Secure Boot instead of ECDSA, you are unaffected by this security notice and can stop reading here. If you use ECDSA, read on.
What Happened
Secure Boot’s entire job is to make sure the firmware your chip runs is the firmware you signed. When the device boots, the ROM checks the signature on the image in flash against a key burned into eFuses. Bad signature, boot fails.
On these four chips, the ECDSA version of that check has a bug. The ROM doesn’t properly validate that the (r, s) components of the ECDSA signature fall within the valid range the curve defines (1 ≤ r, s ≤ n − 1). When the verification step is fed a signature that doesn’t actually belong to the firmware, it can still return “looks good to me.”
The ESP32-C5 has a second problem on top of that. Its ROM code doesn’t initialize the ECDSA peripheral before running the verification, so the underlying ECC hardware is sitting in a power-down state during the operation. Same end result: invalid signatures get approved.
One thing worth calling out clearly, because it’s easy to panic here: this is a ROM-level Secure Boot issue. ECDSA verification done from the application layer is not affected — the ESP-IDF driver initializes the peripheral correctly and validates the signature components. That means your OTA update path, which relies on that application-layer verification, is not vulnerable to this. The problem is specifically in the boot-time ROM check.
How Bad Is It?
Before you panic and start a redesign off the ESP32, let’s look at what an attacker actually needs to exploit this.
They have to be able to replace the signed firmware image — including its signature field — in your external flash. That’s the entire attack surface. And getting there requires one of two things: supply-chain access (someone tampering with devices before they reach you or your customers) or physical access to a deployed device combined with the ability to write to its external flash. This is non-trivial.
If your devices live in a trusted environment and never present a flash-modification attack surface, this attack chain simply doesn’t apply to you. There’s no remote exploit here. Nobody is bypassing your Secure Boot over the network.
Affected Chips
Espressif has confirmed the issue 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
- ESP32-P4 up to chip revision v3.2
Espressif says the hardware fix is coming in “future tape-outs” but didn’t provide a timeline in the notice. Notably, the ESP32-C2 and ESP32-C6 are not affected — they support ECDSA Secure Boot but don’t have the ECDSA hardware peripheral (they only have the ECC accelerator), so they sidestep this entirely.
Mitigation Options
There’s no software patch for the currently affected silicon. ROM-level updates and hardware fixes are planned for future tape-outs, but for chips already in your hands, you’re working with countermeasures rather than a fix. Here’s what’s available.
Switch to RSA-based Secure Boot. This is the headline recommendation. RSA Secure Boot is completely unaffected by this issue and is a fully supported authentication mechanism on these chips. For new production batches, configure Secure Boot to use RSA signatures instead of ECDSA and you’re clear of the whole problem.
For already-deployed devices, migrating from ECDSA to RSA is possible if the device still has a non-revoked Secure Boot eFuse digest block available. There’s nuance and real risk in doing this over OTA, so this is one to coordinate with Espressif support rather than wing on your own.
The one exception: on the ESP32-C61, ECDSA is the only supported Secure Boot scheme, so there’s no RSA fallback. For that chip you’re leaning entirely on the hardware-layer defenses below.
Layer in hardware countermeasures. Since the attack requires physical flash access, anything that makes that harder raises the bar:
- System-in-Package (SiP) variants with the flash die enclosed in the package. You can’t get at the flash pins without decapping the part.
- Flash Encryption (XTS-AES) in Release mode alongside Secure Boot, with either Secure UART download mode enabled or UART download mode permanently disabled. In that configuration, an attacker has to recover your XTS-AES key before any flash modification even takes effect — a serious obstacle on its own.
My Take
This is a foundational-layer bug, and a Secure Boot bypass always deserves attention. That said, there is no remote attack here. To exploit this, someone needs supply-chain access or hands-on physical access plus the ability to rewrite your external flash. If your fleet never leaves a trusted environment, you’re not in the blast radius.
The practical move for most teams: if you’re spinning new boards on the H2, C5, or P4, switch to RSA Secure Boot and move on. It’s a supported, unaffected scheme, and there’s no reason to keep shipping ECDSA Secure Boot on affected silicon when RSA is right there. If you’re on the C61, where ECDSA is your only option, lean hard on Flash Encryption and SiP packaging.
And the broader lesson is one I keep coming back to: Secure Boot is one layer, not the whole wall. The teams that come out of advisories like this one unbothered are the ones who already enabled Flash Encryption, locked down UART download mode, and didn’t treat any single feature as a silver bullet. If this advisory is the nudge that gets you to audit your security config, that’s time well spent.