CVE-2026-8686 is a high severity (CVSS 7.5) heap out-of-bounds read in coreMQTT, the FreeRTOS MQTT client library. A malicious or compromised MQTT 5.0 broker can crash a client or expose nearby memory with a crafted packet. Only v5.0.0 is affected. Upgrade to v5.0.1, because there is no workaround.
What's affected
The project advisory lists coreMQTT v5.0.0 as the only affected version, and v5.0.1 as the patched one. The record words it as "before 5.0.1", so treat any copy of the library older than the fix with care and check which MQTT version it was built for.
The trigger is a crafted SUBACK or UNSUBACK packet sent by an MQTT v5.0 broker. No authentication is needed on the client side, because the client reads whatever its broker sends. If your devices only talk to a broker you run and secure, the practical risk is a compromised broker or a man in the middle on an unprotected link.
How to check if you're exposed
coreMQTT is C source that many teams copy into firmware or pull in as a git submodule, so a package manager scan may not see it. Check these places:
git submodule status | grep -i mqtt
git -C path/to/coreMQTT describe --tags
Look at vendored directories in your firmware repositories, SDK bundles from your board vendor, and any SBOM your build produces. A copy is exposed if it is version 5.0.0 and you use the MQTT 5.0 code path.
What to do now
- Find every place coreMQTT is built into your products, including vendored copies inside board support packages.
- Update to v5.0.1 or later and rebuild the firmware.
- Plan the rollout of updated firmware to devices in the field, starting with those that connect to brokers you do not control.
- Confirm that devices use TLS to the broker, so a network attacker cannot inject packets.
- Record the library version in your SBOM for each firmware release.
Why it matters
The weakness is CWE-125 (out-of-bounds read). The MQTT v5.0 property parser did not check bounds well enough on certain packets, so it could read past the end of a buffer. The advisory says the result can be disclosure of adjacent heap memory or a crash.
Embedded libraries are the hard case for patching. The code lives inside firmware images, and fixing it means shipping a new image. That is why a complete list of which products contain which library version matters more than the patch itself.
The record does not mark this CVE as known exploited, and it is not in the CISA KEV list.
Quick check
Which version fixes it?
coreMQTT v5.0.1, according to the project advisory. The advisory says there is no workaround.
Does this affect MQTT 3.1.1 clients?
The advisory names the MQTT v5.0 deserialization path and v5.0.0. Check the advisory for how your build is configured.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
- https://github.com/FreeRTOS/coreMQTT/security/advisories/GHSA-6qh9-r6jp-2wxc
- https://github.com/FreeRTOS/coreMQTT/releases/tag/v5.0.1
- https://aws.amazon.com/security/security-bulletins/2026-032-aws/
Last reviewed: 19 October 2026.
