Zephyr RTOS CVE-2026-15890

Exploitation requires ALL of: (1) an application that writes the SAME ITS UID concurrently from two or more threads - the ITS layer (secure_storage_its_set) performs no serialization, so this reaches the racy provider directly, but it is a non-default application coding pattern; (2) use of the default AEAD nonce provider secure_storage_its_transform_aead_get_nonce() with AES-GCM or ChaCha20-Poly1305; (3) one of the shipped log-structured back-ends (zms.c or the settings/NVS store), whose deferred garbage collection leaves both superseded and new ciphertexts readable simultaneously in the raw partition; and (4) an adversary with the ability to read the raw backing flash image. Limiting factors: the race window is narrow (AC:H), access is local (AV:L, PR:L), and per-UID key salting (DEVICE_ID_HASH / ENTRY_UID_HASH) makes nonce reuse across DIFFERENT UIDs harmless - only same-UID concurrent collisions are security-relevant.

This is a genuine but heavily gated cryptographic flaw, not an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N = 5.3 Medium) is internally consistent with the description: exploitation is local (AV:L) because it requires code running on-device plus the ability to read the raw flash backing store, high-complexity (AC:H) because it depends on winning a narrow thread race on same-UID concurrent writes, and requires low privilege (PR:L). Confidentiality is high (C:H - nonce reuse leaks the XOR of two secret plaintexts, including PSA persistent keys) with limited integrity impact (I:L - GCM auth-key exposure enabling forgery of stored entries) and no availability impact. No EPSS score, KEV listing, or public POC was provided, so the real-world exploitation signal is essentially absent; per precision rules this is 'no public exploit identified at time of analysis.' The signals are consistent rather than conflicting: a medium CVSS, no active-exploitation evidence, a narrow multi-condition trigger, and a shipped vendor patch all point to a low operational priority. The dominant limiting factor is that the vulnerable behavior only manifests in applications that concurrently write the SAME ITS UID from two threads - a non-default coding pattern - so most Zephyr deployments are not exposed even after accounting for the crypto severity.

An embedded application uses PSA Internal Trusted Storage and, by design or accident, writes the same UID from two threads at once; the racy nonce provider hands both AES-GCM/ChaCha20-Poly1305 operations the same nonce under the per-UID key. Because both back-ends (zms.c and settings/NVS) are log-structured with deferred garbage collection, both ciphertexts remain physically present in the flash partition, so an attacker who can read the raw backing image recovers the XOR of the two plaintexts and, for GCM, the authentication key enabling forgery. No public exploit code was identified, and the attack requires local flash-read access plus a favorable race window (CVSS AV:L/AC:H).