VulnerabilityPublished 26 Oct 2026

CVE-2026-82390: zephyrproject zephyr · Race

Affects zephyrproject zephyrSource CVE Database V5

Not known to be exploited · CVSS 3.7 Low.

Data as of 26 Oct 2026, 18:13 UTC

CVSS 3.1 base score

3.7Low

How severe the flaw is on the 0–10 CVSS scale.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack Vector: Network
Attack Complexity: High
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality: Low
Integrity: None
Availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: High: A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
Integrity: None: There is no loss of integrity within the impacted component.
Availability: None: There is no impact to availability within the impacted component.

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 26 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Affected software

Product	Affected	Fixed in
zephyrprojectzephyr	Affected >=4.3.0 <=4.4.2	Fixed in–
GitHubzephyr`pkg:github/zephyr`Other threats	Affected >=4.3.0 <=4.4.2	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix is available that removes hardware register programming from the session start function and instead programs the key and direction inside the aes_lock mutex at each operation. Users should update to a fixed version beyond 4.4.2 when available. Until patched, applications should avoid using multiple concurrent AES sessions with different keys on this driver to prevent cryptographic failures.

Description

The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold. As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for example a protocol peer whose connection causes a session key to be installed — can influence which key is resident when a victim operation runs. The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted under another. Where the resident key is one the attacker knows or supplied, the affected plaintext becomes recoverable by that attacker, and the operation's direction (encrypt versus decrypt) can likewise be inverted. Exposure requires an application that holds two or more concurrent sessions with different keys against this driver; no in-tree Zephyr subsystem does so today (the 802.15.4 security layer, which does open two sessions, uses CCM mode, which this driver rejects), so the risk falls on application code that uses the documented multi-session API. The fix removes all hardware access from aes_begin_session() and reprograms the key and direction at the top of every operation, inside aes_lock, so the chip-global registers can no longer be observed stale by another session.

Impact

The vulnerability causes cryptographic failures where data believed to be encrypted or decrypted under one key is actually processed under another session's key. If the attacker controls the second session's key, they can recover plaintext or invert encryption/decryption operations. There is no memory corruption or denial of service impact. The risk is limited to applications using multiple concurrent AES sessions with different keys against this driver. No known in-tree Zephyr subsystem currently exhibits this usage pattern, so the impact is primarily on custom application code.

Summary

The Espressif AES driver in Zephyr advertises a multi-session cipher API allowing up to a default of 4 independent sessions, each with its own key and direction. However, the AES hardware has a single global set of key and mode registers. The driver programmed these registers once at session start outside the aes_lock mutex, which serializes transforms. Consequently, when a second session with a different key is opened, subsequent operations on the first session use the second session's key and direction without error. This race condition allows an attacker who can induce session creation to influence which key is active during victim operations, causing cryptographic failures rather than memory corruption. The vulnerability requires application code to hold multiple concurrent sessions with different keys, which is not currently done by Zephyr's in-tree subsystems. The patch moves hardware register programming into the locked operation phase, ensuring the correct key and direction are set per operation.

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 26 Oct 2026, 16:37 UTC

Technical details

References

Community reviews

Related threats