CVE-2026-45328: ESP-IDF Information Disclosure Vulnerability

CVE-2026-45328 Overview

CVE-2026-45328 affects the Espressif IoT Development Framework (ESP-IDF), specifically the esp_tee component used to implement a Trusted Execution Environment (TEE) on Espressif SoCs. In versions 5.5.4 and 6.0, secure-service wrappers exposed by esp_secure_services.c and esp_secure_services_iram.c bridge calls from the Rich Execution Environment (REE) to TEE-protected hardware peripherals including AES, SHA, ECC, HMAC, SPI, MMU, and WDT, along with security features like attestation, OTA updates, and secure storage. These wrappers fail to perform sufficient input validation, allowing a local attacker in the REE to compromise the integrity, confidentiality, and availability of the TEE. The issue is patched in versions 5.5.5 and 6.0.1.

Critical Impact

A local actor executing code in the user application can issue malformed calls to TEE-protected services and break the isolation boundary that protects cryptographic keys, secure storage, attestation, and OTA update logic.

Affected Products

• Espressif ESP-IDF version 5.5.4
• Espressif ESP-IDF version 6.0
• Devices using the esp_tee component for TEE-protected services

Discovery Timeline

• 2026-06-10 - CVE-2026-45328 published to NVD
• 2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-45328

Vulnerability Analysis

The esp_tee subsystem provides a TEE on Espressif microcontrollers and exposes a set of secure-service wrappers to the REE. These wrappers act as the trust boundary: REE code calls them to request TEE-protected operations against AES, SHA, ECC, HMAC, SPI, MMU, and WDT peripherals, as well as attestation, OTA, and secure storage services. Because the wrappers in esp_secure_services.c and esp_secure_services_iram.c did not adequately validate caller-controlled arguments, an attacker running code in the REE can supply parameters that drive TEE logic into unsafe states. The flaw is tracked as Improper Input Validation [CWE-20].

Root Cause

The wrappers accepted offsets, sizes, and pointers from the REE without enforcing bounds against the underlying TEE-controlled regions. For example, the OTA write path computed rel_offset + size and compared it to a region size, which is vulnerable to integer overflow when attacker-controlled values are large. The corrected check rejects out-of-region writes by separately validating size and using subtraction to avoid overflow.

Attack Vector

Exploitation requires the attacker to execute code in the REE on an affected device. From there, the attacker invokes secure-service entry points with crafted arguments to read or write memory outside intended TEE-managed regions, corrupt OTA state, or otherwise abuse TEE-protected peripherals. No user interaction or prior authentication to the TEE is required.

// Source: https://github.com/espressif/esp-idf/commit/145ba4c42dc8283054cfde9a1c3470db7399192f
// Patch in components/esp_tee/subproject/components/tee_ota_ops/esp_tee_ota_ops.c
// Replaces an overflow-prone bounds check with one that validates size first
// and uses subtraction to avoid integer overflow on attacker-controlled values.
         return ESP_ERR_INVALID_STATE;
     }
 
-    if (rel_offset + size > ota_handle.tee_next.pos.size) {
+    if (size > ota_handle.tee_next.pos.size || rel_offset > ota_handle.tee_next.pos.size - size) {
         ESP_LOGE(TAG, "Out of region write not allowed!");
         return ESP_FAIL;
     }

A second hardening change moved the internal secure-service call table from DRAM to IRAM so that the dispatch table backing TEE entry points is not addressable from data-side accesses originating in the REE:

// Source: https://github.com/espressif/esp-idf/commit/440a5d1906502023f2a0fb0aecbdf0602d14acbf
// components/esp_tee/subproject/main/core/esp_secure_service_table.c
-const DRAM_ATTR secure_service_entry_t tee_sec_srv_tbl_int_mem[] = {
+const IRAM_ATTR secure_service_entry_t tee_sec_srv_tbl_int_mem[] = {
     [0 ... SECURE_SERVICES_SPLIT_ID - 1] = { .func = NULL, .nargs = 0 },
 #define __SECURE_SERVICE(NR, SYM, ARGC)  [NR] = { .func = _ss_##SYM, .nargs = ARGC },
 #include "secure_service_int.h"

Detection Methods for CVE-2026-45328

Indicators of Compromise

• Unexpected OTA failures or Out of region write not allowed! log entries from the esp_tee OTA path on ESP-IDF 5.5.4 or 6.0 devices.
• Anomalous calls to secure-service entry points with out-of-range offsets, sizes, or pointer values in TEE audit logs where available.
• Firmware version strings indicating ESP-IDF 5.5.4 or 6.0 still in production after the patch release.

Detection Strategies

• Inventory deployed firmware images and confirm the ESP-IDF version against the Espressif Security Advisory GHSA-mmgp-73p4-92xp.
• Compare shipped binaries against the patched commits referenced in the advisory to confirm input-validation fixes are present.
• Where device telemetry is collected, alert on repeated TEE service errors or unexpected resets that may indicate probing of the secure-service interface.

Monitoring Recommendations

• Stream device logs and OTA status into a centralized analytics platform and alert on TEE error patterns associated with the esp_tee OTA and storage paths.
• Track firmware version distribution across the fleet and flag any device that fails to advance past 5.5.4 or 6.0.
• Monitor the upstream esp-idf repository for additional advisories that may bundle further esp_tee hardening.

How to Mitigate CVE-2026-45328

Immediate Actions Required

• Upgrade affected devices to ESP-IDF 5.5.5 or 6.0.1 and rebuild firmware that uses the esp_tee component.
• Roll out signed OTA updates to all fielded devices running 5.5.4 or 6.0, prioritizing units exposed to untrusted application code.
• Audit any custom secure-service wrappers built on top of esp_tee for the same class of input-validation defects.

Patch Information

Espressif fixed the issue across multiple commits referenced in Espressif Security Advisory GHSA-mmgp-73p4-92xp. Key changes include commit 145ba4c4 adding missing input validation checks for TEE service calls, and commits 440a5d19 and 764626a1 relocating the internal secure-service call table to IRAM. Additional hardening lands in commits 7867f4a5, afd14ab1, and eebabaff. Fixed versions are ESP-IDF 5.5.5 and 6.0.1.

Workarounds

• No vendor-supplied workaround replaces the patch. Upgrade to a fixed ESP-IDF version.
• Where immediate upgrade is not possible, restrict the ability to load or run untrusted application code on the REE side of affected devices.
• Disable optional TEE-backed features such as attestation or secure-storage callers that are not required by the product until patched firmware is deployed.

# Verify ESP-IDF version and update to a fixed release
idf.py --version
cd $IDF_PATH
git fetch --tags
git checkout v5.5.5   # or v6.0.1
git submodule update --init --recursive
./install.sh
. ./export.sh
idf.py fullclean
idf.py build