ESP-IDF CVE-2026-45542

The target device must be running ESP-IDF 5.2.6, 5.3.5, 5.4.4, 5.5.4, or 6.0 firmware AND must be in its provisioning state with the protocomm component active and Security Scheme 2 (SRP6a) configured as the security version - this is the default for ESP-IDF unified provisioning but is typically only exposed during initial device onboarding, factory reset, or explicit re-provisioning. The attacker must be on the adjacent provisioning link (BLE GATT or SoftAP Wi-Fi, per CVSS AV:A) - internet-only attackers cannot reach the vulnerable handler. No authentication is required (PR:N) and no user interaction at the device side is needed (UI:N); the bug fires in the first session-setup message before any SRP6a credentials are verified. The chief limiting factor is therefore deployment posture: a device that has completed provisioning and torn down its protocomm endpoint is not exposed, which is why fleet-wide risk depends on how long devices remain in onboarding mode.

The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H gives a base score of 7.1 driven primarily by High availability impact and unauthenticated low-complexity access, but constrained to Adjacent network - meaning the attacker must be on the same BLE/Wi-Fi provisioning link, not the open internet. This realistically reflects that protocomm is most exposed during device pairing/onboarding, where a nearby attacker can crash or wedge the device but full code execution is not claimed in the description. No EPSS score, no KEV listing, and no POC reference were supplied, and no public exploit was identified at time of analysis, so this should not be triaged as an active campaign - it is a defensive patch priority for fleet operators rather than an emergency. One nuance worth verifying: the description mentions truncation-versus-copy asymmetry which typically yields heap corruption (potential RCE on embedded targets without ASLR/W^X), yet the CVSS C:N/I:L rating suggests Espressif assessed practical exploitation as limited to availability and minor integrity impact - defenders treating ESP32 devices in high-trust roles (industrial, medical, access control) should not assume RCE is ruled out without independent confirmation.

An attacker within Bluetooth Low Energy or Wi-Fi range of an ESP32 device in provisioning mode connects to its protocomm endpoint and sends a crafted SessionCommand0 protobuf message whose client_username field carries an oversized length value, triggering the unchecked memcpy in handle_session_command0() and corrupting the heap. The most reliable outcome is a device crash and watchdog reset (denial of service of the onboarding flow), with heap-grooming on this embedded target potentially enabling further integrity impact against adjacent allocations. No public exploit was identified at time of analysis, but the vulnerable code path and fix diff are public on GitHub, lowering the bar to write a proof-of-concept.