CVE-2026-82390 (GCVE-0-2026-82390)
Vulnerability from cvelistv5 – Published: 2026-10-26 16:08 – Updated: 2026-10-26 17:37
VLAI
EPSS
VEX
Title
Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver
Summary
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.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-26 16:49 UTC
CWE
- CWE-362 - race
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.3.0 , ≤ 4.4.2
(semver)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82390",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T16:49:07.670669Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T17:37:10.530Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/crypto/crypto_esp32_aes.c"
],
"programRoutines": [
{
"name": "aes_begin_session"
},
{
"name": "aes_cbc_op"
},
{
"name": "aes_ctr_op"
},
{
"name": "aes_ecb_op"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API \u2014 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.\n\nAs a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session\u0027s 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\u0027s cipher_begin_session() landing between the first thread\u0027s begin and its operation makes that operation run under the second thread\u0027s key. An attacker who can induce session creation on the device \u2014 for example a protocol peer whose connection causes a session key to be installed \u2014 can influence which key is resident when a victim operation runs.\n\nThe 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\u0027s 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.\n\nThe 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."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.7,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "race",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T16:08:54.724Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/cb4168ab3f6bd1bfc26060fd33cfcd00e8e641f1"
},
{
"name": "GHSA-rvww-w3mx-r99q",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rvww-w3mx-r99q"
}
],
"title": "Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-82390",
"datePublished": "2026-10-26T16:08:54.724Z",
"dateReserved": "2026-08-28T21:11:44.241Z",
"dateUpdated": "2026-10-26T17:37:10.530Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-82390",
"date": "2026-10-28",
"epss": "0.00198",
"percentile": "0.09539"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/crypto/crypto_esp32_aes.c"
],
"programRoutines": [
{
"name": "aes_begin_session"
},
{
"name": "aes_cbc_op"
},
{
"name": "aes_ctr_op"
},
{
"name": "aes_ecb_op"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"source": "vulnerabilities@zephyrproject.org"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API \u2014 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.\n\nAs a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session\u0027s 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\u0027s cipher_begin_session() landing between the first thread\u0027s begin and its operation makes that operation run under the second thread\u0027s key. An attacker who can induce session creation on the device \u2014 for example a protocol peer whose connection causes a session key to be installed \u2014 can influence which key is resident when a victim operation runs.\n\nThe 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\u0027s 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.\n\nThe 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."
}
],
"id": "CVE-2026-82390",
"lastModified": "2026-10-26T18:34:17.050",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 3.7,
"baseSeverity": "LOW",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"exploitabilityScore": 2.2,
"impactScore": 1.4,
"source": "vulnerabilities@zephyrproject.org",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-82390",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T16:49:07.670669Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-10-26T17:17:30.883",
"references": [
{
"source": "vulnerabilities@zephyrproject.org",
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/cb4168ab3f6bd1bfc26060fd33cfcd00e8e641f1"
},
{
"source": "vulnerabilities@zephyrproject.org",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rvww-w3mx-r99q"
}
],
"sourceIdentifier": "vulnerabilities@zephyrproject.org",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-362"
}
],
"source": "vulnerabilities@zephyrproject.org",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-82390",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-26T16:49:07.670669Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T17:35:17.842Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/crypto/crypto_esp32_aes.c"
],
"programRoutines": [
{
"name": "aes_begin_session"
},
{
"name": "aes_cbc_op"
},
{
"name": "aes_ctr_op"
},
{
"name": "aes_ecb_op"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API \u2014 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.\n\nAs a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session\u0027s 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\u0027s cipher_begin_session() landing between the first thread\u0027s begin and its operation makes that operation run under the second thread\u0027s key. An attacker who can induce session creation on the device \u2014 for example a protocol peer whose connection causes a session key to be installed \u2014 can influence which key is resident when a victim operation runs.\n\nThe 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\u0027s 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.\n\nThe 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."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.7,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "race",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-26T16:08:54.724Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/cb4168ab3f6bd1bfc26060fd33cfcd00e8e641f1"
},
{
"name": "GHSA-rvww-w3mx-r99q",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rvww-w3mx-r99q"
}
],
"title": "Cross-session AES key confusion in the Espressif ESP32 hardware crypto driver",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-82390",
"datePublished": "2026-10-26T16:08:54.724Z",
"dateReserved": "2026-08-28T21:11:44.241Z",
"dateUpdated": "2026-10-26T17:37:10.530Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.