What is the CVSS score of CVE-2026-10681?

CVE-2026-10681 has a CVSS 3.1 base score of 7.0 (High). CVSS vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Zephyr RTOS are affected by CVE-2026-10681?

Zephyr RTOS versions 2.0.0 through 4.4.0 contain a critical ACL isolation bypass in symmetric multiprocessing builds that allows concurrent user-mode threads to alias each other's kernel permissions,…. A patch is available.

How to fix or mitigate CVE-2026-10681?

Within 24 hours, audit all Zephyr RTOS deployments to identify systems running versions 2.0.0-4.4.0 with SMP enabled and CONFIG_USERSPACE activated; assess which systems depend on userspace isolation for security boundaries. Within 7 days, apply the available vendor patch to test and staging environments, validate functionality and performance, and confirm thread isolation is restored. Within 30 days, complete production deployment of the patched version across all affected systems and verify through testing that userspace ACL isolation is no longer compromised.

Zephyr RTOS CVE-2026-10681

EUVD-2026-49045 HIGH

Race Condition (CWE-362)

2026-07-25 zephyr

Race Condition Information Disclosure Zephyr

7.0

CVSS 3.1 · NVD

Severity by source

Vendor (zephyr) PRIMARY

MEDIUM

qualitative

NVD

7.0 HIGH

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

vuln.today AI

7.0 HIGH

Local SMP race requires existing thread execution (PR:L, AV:L) and precise timing (AC:H); successful aliasing grants full kernel-object ACL bypass (C:H/I:H/A:H), scope unchanged.

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

4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (zephyr).

CVSS VectorNVD

Attack Vector

Local

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Aug 12, 2026 - 15:13 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Aug 12, 2026 - 15:07 vuln.today

cvss_changed

Severity Changed

Aug 12, 2026 - 15:07 NVD

MEDIUM HIGH

CVSS changed

Aug 12, 2026 - 15:07 NVD

6.5 (MEDIUM) 7.0 (HIGH)

Source Code Evidence Fetched

Jul 26, 2026 - 12:06 vuln.today

Analysis Generated

Jul 26, 2026 - 12:06 vuln.today

DescriptionNVD

In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock.

On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx.

The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool.

The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).

AnalysisAI

Userspace ACL isolation is defeated in Zephyr RTOS v2.0.0 through v4.4.0 on SMP builds due to a missing spinlock in thread_idx_alloc(), allowing two concurrently executing user-mode threads to receive the same permission-index (tidx) and subsequently alias each other's ACL bit across every kernel object. Any kernel object access grant intended exclusively for one thread is silently extended to the aliasing thread, nullifying the CONFIG_USERSPACE isolation model. No public exploit or active exploitation (CISA KEV) is known at time of analysis, and SSVC marks automatable: no, but the technical impact is assessed as total, warranting prioritized patching for affected SMP deployments.

Technical ContextAI

The defect is in kernel/userspace/userspace.c within thread_idx_alloc(), which allocates entries from the global _thread_idx_map[] bitmap to assign unique per-thread permission indices (tidx). Every kernel object in Zephyr's userspace model maintains a perms[] bitfield indexed by tidx; granting a thread access to an object sets its tidx bit. Because thread_idx_alloc() performed a non-atomic read-modify-write on _thread_idx_map[] without holding lists_lock, two threads executing k_object_alloc(K_OBJ_THREAD) concurrently on an SMP system could each observe the same lowest free bit, both clear it independently, and both receive the identical tidx - a textbook CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization). A secondary race between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() could additionally leak index entries from the pool. The fix (commit 862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d) acquires k_spin_lock(&lists_lock) at the top of thread_idx_alloc(), covering the entire bitmap RMW and permission-clearing traversal, and inlines the obj_list walk (previously lock-acquiring itself) to avoid deadlock. CPE cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* covers all affected releases.

RemediationAI

Upgrade to Zephyr v4.5.0 or a release incorporating commit 862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d (https://github.com/zephyrproject-rtos/zephyr/commit/862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d); the fix version is inferred from the EUVD upper bound of <4.5.0 rather than independently verified against a tagged release, so operators should confirm their target release includes the fix commit. For deployments that cannot immediately upgrade, disabling CONFIG_SMP=n in the build eliminates the SMP concurrency condition entirely but carries a significant performance regression on multi-core hardware. Disabling CONFIG_DYNAMIC_OBJECTS=n prevents the vulnerable k_object_alloc(K_OBJ_THREAD) syscall path but removes runtime kernel object allocation capability, which may break application functionality. Restricting the use of k_object_alloc(K_OBJ_THREAD) to only fully trusted user threads via application-level policy reduces attack surface but does not close the race for threads permitted to call it. Consult the Zephyr security advisory at https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j693-5rh5-8g8h for official mitigation guidance.