FreeRTOS-Kernel CVE-2026-77234

Exploitation requires (1) a FreeRTOS-Kernel build that enables the MPU port - flat single-privilege builds are not in scope; and (2) the attacker already executing as an unprivileged (MPU-restricted) task on the device, i.e., a pre-existing local foothold (CVSS PR:L, AV:L). Given those, no user interaction and only low attack complexity are needed (UI:N/AC:L). Limiting factors that reduce real-world risk: it is not remotely reachable on its own (local vector only), it applies only to MPU-enabled ports and kernel versions 7.0.0-11.3.0, and it presupposes the ability to run untrusted code as a task - so devices that run only vendor-signed, fully-trusted tasks with no untrusted code path have no attacker to escalate.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) with high impact to both the vulnerable and subsequent system (VC/VI/VA:H, SC/SI/SA:H) is internally consistent with the description: exploitation is local, low-complexity, needs no user interaction, and requires only the low privilege of an already-running unprivileged task - but the payoff is total (full kernel-context code execution and loss of MPU isolation), which is why it scores 9.3/Critical. The realistic barrier is the AV:L/PR:L requirement: an attacker must already be able to run code as an unprivileged task on the device, so this is a privilege-escalation primitive rather than an initial remote-access flaw. No EPSS score was provided, there is no KEV listing, and no public exploit is identified at time of analysis, so evidence points to no widespread automated exploitation today; however, in defense-in-depth embedded designs the MPU boundary is precisely the mitigation attackers must defeat, so operators running MPU-enabled firmware should treat this as high priority. The 'Authentication Bypass' tag should be read as a boundary/authorization bypass (CWE-863), not a network login bypass - do not infer network authentication semantics from it.

An attacker who can get an unprivileged application task onto an MPU-enabled FreeRTOS device - for example by compromising a lower-trust component or supplying malicious code to a task that loads it - crafts input to a kernel service that the kernel fails to validate at the privilege boundary. The kernel then executes attacker-controlled logic in privileged context, giving full control of the device and defeating MPU isolation. No public proof-of-concept is identified at time of analysis, and exploitation requires local presence as a running task (AV:L, PR:L) with low complexity.