Zephyr RTOS EUVD-2026-109976

Requires a Zephyr application on ESP32 that holds two or more concurrent cipher sessions with different keys against this hardware AES driver (CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX, default 4) using ECB, CBC or CTR mode. No stock Zephyr subsystem meets this: the 802.15.4 security layer opens two sessions but uses CCM mode, which this driver rejects, so only custom application code using the documented multi-session API is exposed. The attacker must be able to induce session creation - e.g. a protocol peer whose connection installs a session key - and, for the threaded race variant, land a second cipher_begin_session() between the victim's begin and its operation. Limiting factors: ESP32 hardware only, affected driver versions 4.3.0-4.4.2, non-default multi-session usage pattern required, and the attacker must know or supply the key that ends up resident for plaintext to be recoverable.

This is a genuinely low-priority issue whose signals are internally consistent rather than conflicting. The NVD CVSS of 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) reflects a high-complexity attack with only limited confidentiality impact, and the vuln.today decision label is 'monitor' - the weakest urgency tier. No EPSS score, no CISA KEV listing, and no exploit-code reference were provided (only vendor patch commit and the GHSA advisory, which are remediation artifacts, not exploit code), so exploitation status is 'no public exploit identified at time of analysis.' The dominant limiter is not the CVSS complexity metric itself but the deployment precondition the advisory states explicitly: exploitation requires application code that holds two or more concurrent sessions with different keys against this driver, and the advisory confirms NO in-tree Zephyr subsystem does so today (the 802.15.4 layer that opens two sessions uses CCM, which this driver rejects). Therefore the real-world attack surface is effectively zero for stock Zephyr and non-zero only for bespoke applications using the multi-session AES API on ESP32. The AV:N rating is defensible because an attacker influences which key is resident by inducing session creation over a protocol connection, but the AC:H and the application-dependency together make this a correctly-scored low-risk cryptographic correctness bug, not an under-rated threat. One nuance worth verifying: NVD sets I:N, yet the described direction inversion (encrypt vs. decrypt) and wrong-key encryption are arguably integrity-affecting, so the true impact may be slightly broader than the vendor vector shows.

An ESP32-based Zephyr application uses the documented multi-session AES API, keeping one session for its own protected data and installing a second session key when a network/protocol peer connects. An attacker whose connection causes that second session to be created - with a key the attacker knows or supplied - makes the chip-global key registers hold the attacker's key when the victim's next ECB/CBC/CTR operation runs, so the victim's data is transformed under the attacker's key and its plaintext becomes recoverable. No public exploit code was identified; exploitation also hinges on winning the race between the victim's begin and its operation, consistent with the AC:H rating.