ESP-IDF EUVD-2026-35916

Exploitation requires the target firmware to be built with the esp_tee component enabled on ESP-IDF 5.5.4 or 6.0 and the attacker to already be executing code in the Rich Execution Environment with the ability to invoke the esp_secure_services.c/esp_secure_services_iram.c wrappers (matching CVSS PR:L, AV:L, UI:N) - i.e. a compromised or attacker-controlled REE application, not network-reachable attack. Limiting factors: no remote vector, no automation (SSVC Automatable: no), the device must actually use esp_tee (devices that do not enable the TEE component are not affected), and the attacker must supply crafted buffer/pointer arguments that straddle REE/TEE boundaries or target the previously-unchecked context, IV, SHA state or OTA offset parameters - generic REE code execution alone is not sufficient without targeting these specific wrappers.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H gives 8.8 and correctly reflects a local, low-privileged caller breaking the REE/TEE scope boundary with total confidentiality, integrity and availability impact on the secure side. CISA SSVC corroborates this with Technical Impact 'total' but Exploitation 'none' and Automatable 'no', and EPSS is only 0.02% (5th percentile) - consistent with a hardware-bound bug that requires the attacker to already be executing code on the target ESP32 device. There is no public exploit identified at time of analysis and the CVE is not in CISA KEV, so this is best treated as a serious supply-chain/firmware-update priority for products that rely on esp_tee for attestation, secure storage or secure OTA (where TEE compromise voids the security model), but not an internet-facing emergency. The 'Information Disclosure' tag understates the impact - the commit diff and CVSS show full integrity/availability impact on TEE peripherals, not just disclosure.

An attacker who can execute code in the REE - for example by exploiting a separate bug in the application firmware, by shipping a malicious component into the device's build, or by abusing a debug/OTA path on a device they physically possess - calls one of the esp_tee secure-service wrappers (e.g. _ss_esp_aes_crypt_cbc or the SHA wrappers) with crafted buffer pointers and lengths that pass the pre-patch start/end-pointer check but actually overlap TEE-protected memory or unchecked context/IV/state buffers. Through repeated calls they coerce the TEE into reading or writing protected memory and driving AES/SHA/ECC/HMAC/MMU/WDT peripherals or OTA flash regions on their behalf, escalating from REE to full TEE compromise. No public exploit identified at time of analysis.