CVE-2026-10672 is an out-of-bounds read (CWE-125) in the LwM2M firmware update code of Zephyr RTOS, scored 8.2 high. A long package URI from a management server is copied without a terminator and read past its buffer. The advisory lists Zephyr v4.5.0 as the patched version, so update to it or later.
What's affected
The record says the vulnerable copy came with the pull context refactor, first released in v3.0.0, and is present through v4.4.0. The GitHub advisory lists the versions it checked as v4.3.0, v4.2.1 and v3.7.1 and names v4.5.0 as the patched version. Treat v3.0.0 through v4.4.0 as the range to review, and confirm the exact list in the advisory.
The code path is the default on LwM2M firmware update pull support, which the record says is switched on by default (the CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT setting). Devices that use LwM2M for firmware download are the ones in scope.
The upstream fix adds a length check on the URI that returns an out of memory error when it does not fit, and switches to a copy that guarantees a terminated, bounded buffer.
How to check if you're exposed
Check which Zephyr revision your firmware builds from. In a west workspace, run this in the zephyr directory:
git describe --tags
Then look at your build configuration for LwM2M and firmware update pull support. In a built tree you can search the generated config:
grep -n "LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT\|LWM2M_SWMGMT_PACKAGE_URI_LEN" build/zephyr/.config
If pull support is enabled, check who controls the LwM2M management server and how the device authenticates to it. The record notes that an on path attacker is relevant on sessions that lack strong DTLS, so look at your security mode too.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Update to Zephyr v4.5.0 or later, or cherry pick the upstream fix into your maintained branch.
- If you cannot update yet, disable LwM2M firmware update pull support in builds that do not need it.
- Make sure every LwM2M session uses DTLS with strong authentication, so only your own server can write the package URI.
- Limit who can write the firmware update object on your LwM2M server, and review its recent writes for unusually long URIs.
- Schedule an over the air update for deployed devices and test that the update path itself still works.
- Run test builds with address sanitizer to catch other copies that size a read or write from the destination instead of the source.
Why it matters
The Firmware Update object stores the server supplied URI in a 255 byte buffer. The pull context holds a smaller buffer, 128 bytes by default. The code copied exactly the destination size from the source with no length check, and it did not add a terminator. The next functions treat the buffer as a C string, so they read past it into adjacent memory.
The record describes two effects. The extra bytes end up in outbound CoAP requests, which discloses adjacent device memory to the server or a proxy. A long enough read can also crash the device. This is CWE-125, a read past the end of a buffer.
The flaw is reachable from the server side during ordinary firmware download startup. That makes the trust in your management server part of the risk picture. The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability.
Quick check
Who can trigger this?
A LwM2M management server, or an on path attacker on a session without strong DTLS, according to the record. Strong session security removes the second case.
Is a fix available?
The GitHub advisory lists v4.5.0 as patched. Check the advisory and your own branch for the matching commit.
Sources
Last reviewed: 19 October 2026.
