Skip to content
Fencer Intel
low 3.1

CVE-2026-13479 json

Out-of-bounds read in LoRaWAN clock-sync AppTimeAns downlink handler

published 2mo ago modified 5d ago also EUVD-2026-66555

cvss
3.1
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 13%
public exploits
0
none known

Summary

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.

Patch / fix

  • zephyrproject zephyr 4.3.2, 4.4.2

Is CVE-2026-13479 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2mo ago

Exploit prediction

0.23% chance of exploitation in the next 30 days, higher than 13% of all scored CVEs (FIRST EPSS, 2026-11-09).

Exploits and checks

  • github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2m6g-p3vx-p2fh referenced PoC, tagged "exploit" by a source, unverified

CVSS scores

assigned by version score vector
CNA 3.1 3.1 CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
NVD 3.1 4.3 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Affected products

  • zephyrproject zephyr

Classification

Weakness

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.