1/4 Security Advisory Title Security Advisory Concerning AES Key Recovery Using Voltage Fault Injection on ESP32-S3 Issue Date 2026/06/10 Advisory Number AR2026-005 Serial Number NA Version V1.0 Issue Summary A hardware vulnerability has been identified in the ESP32-S3 chip affecting the general-purpose AES peripheral. This peripheral is the hardware AES accelerator used by firmware for cryptographic operations such as TLS session encryption and secure communication with external components. It is distinct from the XTS-AES peripheral used for Flash Encryption. A security researcher demonstrated that the AES hardware engine can be faulted during intermediate AES rounds using voltage fault injection on the CPU power supply rail. The engine completes execution but produces a corrupted ciphertext exhibiting structured byte-level error diffusion. Differential Fault Analysis (DFA) applied to a small set of correctly classified faulty ciphertexts allows recovery of the final AES round subkey; because the AES key schedule is fully invertible, the full AES-128 secret key can then be reconstructed. Successful exploitation requires physical access, dedicated external equipment to tune the voltage glitch parameters, and precise knowledge of when the AES operation executes on the target — which on a deployed device must be located indirectly through side-channel power analysis. Considering these prerequisites and the per-device, ephemeral nature of any recovered key, the overall impact of this attack on deployed systems is assessed as low. What is a Voltage Fault Injection? A fault-injection attack introduces intentional errors into a system to disturb its execution and induce exploitable behavior. Voltage fault injection achieves this by applying a brief, precisely timed disturbance — commonly referred to as a glitch — to one of the device's power supply rails, which can cause the processor or 2/4 peripheral to compute or store incorrect intermediate values without halting execution. The attack on ESP32-S3 discussed in this advisory uses an external crowbar glitching technique applied to the CPU core supply rail, driven by a deterministic FPGA-based glitching platform together with a fast external MOSFET switching stage. What is the Differential Fault Analysis? Differential Fault Analysis (DFA) is a cryptanalytic technique that compares the correct output of a cryptographic operation with an output produced under a fault. When a fault occurs at a specific stage of AES-128, the structured propagation of the resulting error through subsequent rounds reveals information about the round subkey. A small number of correctly classified faulty ciphertexts is sufficient to recover the final round subkey, and because the AES key schedule is fully invertible, this is equivalent to recovery of the original AES-128 secret key. Impact Analysis 1. The affected hardware is the general-purpose AES peripheral of the ESP32-S3, distinct from the XTS-AES peripheral used for Flash Encryption. It is typically used for cryptographic operations such as TLS session encryption and secure communication with external components. In many deployments the keys handled by this peripheral are short-lived or session-specific — for example, TLS session keys derived per connection — in which case the practical impact of recovering a single key on a single device is limited in both scope and lifetime. 2. Because the AES key recovered through this attack belongs to one specific device, the attack is intrinsically per-device when each device is provisioned with a unique key. Provided long-lived static keys and cross-device key reuse are avoided; the attack cannot be scaled into a class attack against an entire device population. 3. The attack requires physical access and intrusive board-level modifications — removal of the CPU rail bypass capacitor, isolation of that rail from the main 3.3 V rail, and attachment of an external voltage glitching circuit — together with a deterministic FPGA-based glitching platform, a fast external MOSFET crowbar stage, and accurate localization of the AES execution timing window on the target. It does not require chip decapsulation, backside probing, body-biasing, or laboratory-grade infrastructure, but it still represents a meaningful barrier in expertise, instrumentation, and tuning effort. Affected Espressif Products Series: This vulnerability has been confirmed on ESP32-S3. ESP32-S3 and certain earlier-generation Espressif SoCs - including ESP32, ESP32-S2, ESP8684, ESP32-C3, 3/4 ESP32-C6 do not include a hardware-integrated power-glitch detector and therefore do not provide intrinsic resistance against this class of voltage fault injection. Newer Espressif SoC series - including ESP32-C61, ESP32-C5, ESP32-H2 (Chip Revision v1.2), ESP32-P4, and ESP32-S31— incorporate a hardware-integrated glitch detection circuit, substantially increasing the difficulty of voltage fault injection attacks. Customers whose threat model includes attackers with physical access and voltage fault injection capability are recommended to consider these newer SoC series. Mitigation There is no complete software or hardware fix available for this issue on currently affected products, since the vulnerability originates inside the hardware AES engine itself. Future products will incorporate improved hardware countermeasures. The following are recommendations to reduce risk on existing deployments. Hardware Countermeasures Protect the device from physical access using a tamper-resistant enclosure that cannot be breached without detection and configure the device to respond to tamper events according to a predetermined action, such as resetting or clearing secret information. Physical access prevention is the most effective countermeasure, as this attack fundamentally depends on direct electrical access to the CPU power supply rail. Application Countermeasures The most effective application-level mitigation is careful management of the keys handled by the AES peripheral. Espressif's security guidance strongly recommends the following practices: • Prefer short-lived or session-specific AES keys (such as TLS session keys derived per connection) over long-lived static keys. Recovery of an ephemeral key affects only the session in which it was used. • Avoid long-lived static AES keys shared between devices or within a manufacturing batch. Each device should be provisioned with a unique secret tied to its identity. 4/4 • Where the AES peripheral protects data on external memory or shared communication channels, ensure those keys are device-unique and rotated where possible. • Enable Flash Encryption and Secure Boot together, which reduces the risk of an attacker rewriting firmware that uses the AES peripheral. Credits We would like to thank Bedri Zija, Independent Embedded Systems Engineer and Hardware Security Researcher, for reporting this vulnerability and for practicing responsible disclosure.