CVE-2026-77237 is a medium severity (6.5) out-of-bounds read in FreeRTOS-Kernel. Missing type validation in xQueueAddToSet lets an unprivileged task on an MPU port with queue sets enabled read privileged kernel memory. Affected versions are 7.4.0 through 11.3.0. V11.3.1 fixes it.
What's affected
The GitHub advisory says impacted versions are 7.4.0 through 11.3.0, on MPU-enabled ports with configUSE_QUEUE_SETS set to 1. The record says FreeRTOS-Kernel before 11.3.1. The fix is in V11.3.1.
Applications built without queue sets are not affected. The AWS security bulletin 2026-086-aws covers this issue together with three others in FreeRTOS-Kernel: CVE-2026-77234, CVE-2026-77235 and CVE-2026-77236. Read the bulletin for those.
Where sources differ. The record and the advisory agree on the fix version and on 6.5 Medium. The advisory adds a lower bound of 7.4.0 that the record does not give. They also agree on the vector: local access, low privileges, changed scope, high confidentiality impact.
How to check if you're exposed
Two checks, both in your own source tree. First, whether queue sets are on:
grep -rn configUSE_QUEUE_SETS .
A value of 1 in FreeRTOSConfig.h means queue sets are enabled. Second, the kernel version, which the kernel header exposes as tskKERNEL_VERSION_NUMBER in task.h, and your port: only MPU-enabled ports are in scope.
Embedded projects often vendor FreeRTOS inside a vendor SDK, so check the SDK's copy as well as your own. Your device vendor may have to ship the update. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- Find every product that includes FreeRTOS-Kernel and note version, port and the configUSE_QUEUE_SETS setting.
- Where queue sets are not needed, the advisory says disabling the feature removes the risk.
- Otherwise update FreeRTOS-Kernel to V11.3.1 or later, and make sure forked or derived code gets the fix as well.
- Ask SDK and device vendors for updated firmware if you ship their copy of the kernel.
- Read AWS bulletin 2026-086-aws for the three sibling CVEs.
Why it matters
On an MPU port, the kernel runs privileged and tasks run unprivileged, and the memory protection unit keeps them apart. xQueueAddToSet did not check that the handle it was given was really a queue, so a non-conforming handle could be added to a queue set. A later queue set operation then treated that memory as a structure it is not, and the over-read bytes landed in application-readable storage. The record files it under CWE-125, CWE-843, an out-of-bounds read, and type confusion.
The advisory calls it an information disclosure primitive that can help further attacks, such as learning kernel addresses. The requirement is a task already running on the device, so this is about containment inside the device, not a remote hole. For products that rely on MPU isolation to separate trusted and untrusted code, that containment is the point. The record does not mark it as a CISA KEV entry.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect builds without queue sets?
No. The advisory says applications built without queue sets are not affected, and disabling the feature removes the risk.
Is it remotely exploitable?
The vector is local with low privileges. An unprivileged task on the device is needed.
Sources
- GitHub advisory GHSA-9wvc-hqvx-5wf5
- FreeRTOS-Kernel V11.3.1 release
- AWS security bulletin 2026-086-aws
Last reviewed: 18 October 2026.
