#46: ESP32-S3 AES Key Recovery Using Voltage Fault Injection
ESP32-S3 AES Key Recovery Using Voltage Fault Injection
Espressif just published a security advisory AR2026-005 about a vulnerability in the ESP32-S3’s general-purpose AES peripheral. An independent researcher found a way to fault the hardware AES engine mid-operation using a voltage glitch and then recover the full AES-128 key from the corrupted output. Let’s break down what this actually means for a product using the S3.
What Happened
First, an important distinction. This is NOT the XTS-AES peripheral that handles Flash Encryption. This is the general-purpose AES accelerator your firmware reaches for when it needs to do crypto work like TLS session encryption or talking securely to an external component. Two different peripherals, two different jobs.
The researcher demonstrated that if you apply a brief, precisely timed disturbance (a “glitch”) to the CPU core’s power supply rail while the AES engine is crunching an intermediate round, the engine doesn’t crash. It happily finishes and spits out a ciphertext. But that ciphertext is now corrupted in a very specific, structured way.
That structure is the whole game. A technique called Differential Fault Analysis (DFA) compares a correct ciphertext against the faulty ones. Because an AES error propagates through the remaining rounds in a predictable pattern, a small handful of correctly classified faulty outputs is enough to recover the final round subkey. And since the AES key schedule is fully invertible, recovering that last round key is mathematically equivalent to recovering the original AES-128 secret key. That key is now fully compromised.
How Bad Is It?
Before you panic, let’s look at what an attacker actually needs to pull this off.
Physical access to the device. Board-level surgery, specifically removing the bypass capacitor on the CPU power rail, isolating that rail from the main 3.3V supply, and wiring in an external glitching circuit. A deterministic FPGA-based glitching platform with a fast MOSFET crowbar stage. You also have to know exactly when the AES operation runs on the target, which on a deployed device means hunting that timing window down indirectly through side-channel power analysis first.
To be fair, Espressif notes this attack does not require chip decapsulation, backside probing, body biasing, or laboratory-grade infrastructure. But your neighbor or disgruntled former employee is not pulling this off.
The bigger comfort is what you actually walk away with. In most deployments, the keys this peripheral handles are short-lived, like TLS session keys derived per connection. Recover one of those after all that effort and you’ve compromised exactly one session on exactly one device. And because the attack is intrinsically per-device, there’s no scaling it across a fleet as long as each device has its own unique key. Espressif assesses the overall impact on deployed systems as low, and I’d completely agree.
Should You Care?
Probably not, but let’s talk about affected chips.
This has been confirmed on the ESP32-S3. More broadly, the S3 along with several earlier parts, including the original ESP32, ESP32-S2, ESP8684, ESP32-C3, and ESP32-C6, don’t have a hardware-integrated power-glitch detector, so they offer no real protection against this class of voltage fault injection.
The good news is that the newer generation of Espressif SoCs do include a hardware glitch detection circuit, which substantially raises the difficulty of this kind of attack. That list includes the ESP32-C61, ESP32-C5, ESP32-H2 (Chip Revision v1.2), ESP32-P4, and ESP32-S31. So if your threat model genuinely includes someone with physical access and major hardware hacking skills, you’ll want to make sure you’re design incorporates one of those newer SKUs.
Mitigation Options
In Espressif’s own words, “There is no complete software or hardware fix available for this issue on currently affected products,” because the weakness lives inside the hardware AES engine itself. Future products will get improved hardware countermeasures. In the meantime, here’s what you can do.
Hardware side: Physical access prevention is the single most effective countermeasure. This entire attack depends on getting electrical access to the CPU power rail. A tamper-resistant enclosure that can’t be opened without detection, configured to respond to tamper events by resetting or clearing secrets, takes the whole attack off the table.
Application side: This is where you have the most leverage, and it’s mostly good key hygiene. Prefer short-lived or session-specific keys over long-lived static ones, so that recovering a key only burns the session it belonged to. Never share a static AES key across devices or within a manufacturing batch. Each device should get a unique secret tied to its identity. Where the AES peripheral protects data on external memory or a shared channel, keep those keys device-unique and rotate them where you can. And as always, enable Flash Encryption and Secure Boot together so an attacker can’t rewrite the firmware that uses the peripheral in the first place.
Conclusion
This one sounds scary, “recover the full AES key,” but in practice it’s a sophisticated, physical, per-device, per-session attack that most products will never realistically face. For the vast majority of us, the takeaway isn’t fear, it’s a reminder to go audit how you’re managing the keys your AES peripheral touches. Are they unique per device? Are they short-lived where they can be? Are Flash Encryption and Secure Boot both on? If the answer is yes, you’re already in good shape, and this advisory is just one more reason to keep it that way.