CVE-2025-52471 is a critical integer underflow (CVSS 9.8) in the ESP-NOW code of Espressif ESP-IDF. The advisory lists fixes in 5.4.2, 5.3.4, 5.2.6 and 5.1.6. Update your firmware builds to a patched release, or on 5.3 and earlier validate the receive length in your callback.
What's affected
The record describes an integer underflow in the ESP-NOW protocol code of the ESP Wi-Fi component. It names ESP-IDF versions 5.4.1, 5.3.3, 5.2.5 and 5.1.6 as affected. The same record lists fixes in 5.4.2, 5.3.4, 5.2.6 and 5.1.6, which repeats 5.1.6 on both sides, so check the Espressif advisory for the exact 5.1 boundary before you rely on it.
The weakness is CWE-191 (integer underflow). The record says insufficient validation of the user supplied data length in the packet receive function can lead to out of bounds memory access and possibly arbitrary memory writes. On systems without a memory protection scheme, it says this could potentially be used to achieve remote code execution. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The CISA Known Exploited Vulnerabilities flag is false for this CVE, and the record does not say it is exploited in the wild.
Only firmware that uses ESP-NOW is relevant. If your product never enables it, the exposure is lower, though updating is still sensible.
How to check if you're exposed
This is a firmware dependency, so the check happens in your build, not on a running server. In your ESP-IDF checkout, read the version:
idf.py --version
git -C "$IDF_PATH" describe --tags
Then search your application source to see whether ESP-NOW is used at all:
grep -rn "esp_now_" main components
A hit on esp_now_register_recv_cb means your device runs the receive path described in the advisory. Check each product line, because different firmware images are often built with different ESP-IDF versions, and devices in the field keep the version they were built with. Your release records are the way to find which shipped versions are affected.
What to do now
- List every firmware image you ship or run, with the ESP-IDF version it was built with.
- Check which of them enable ESP-NOW.
- Rebuild on a fixed release: 5.4.2, 5.3.4, 5.2.6 or the 5.1 line named in the advisory. Confirm the 5.1 detail in the Espressif advisory.
- If you cannot upgrade a 5.3 or earlier build yet, add a check in your receive callback that the
data_lenargument is a positive value before you process the data. The advisory says there is no application level workaround for 5.4 and later. - Plan an over the air update for devices already deployed, and prioritize any that sit in exposed locations.
- Check that your boards use the memory protection features of the chip, since the record ties code execution to systems without them.
Why it matters
An integer underflow happens when a subtraction goes below zero in an unsigned or checked type and wraps to a huge number. Here the receive code works out a payload length by subtracting header sizes from the length it was given. If the incoming length is smaller than the headers, the result wraps, and later code believes it has a very large buffer to work with.
ESP-NOW is a connectionless protocol that lets devices exchange short messages without joining a network. That convenience also means a nearby device can send packets without any handshake. The record scores the flaw as network reachable and needing no privileges, so a patched build matters.
Firmware is slow to update. A fix in the framework helps only after it is built into an image and shipped to devices. Teams that track which ESP-IDF version went into which release can answer this kind of question quickly. Teams that do not will need to open the build files for every product.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which ESP-IDF versions fix CVE-2025-52471?
The record lists 5.4.2, 5.3.4, 5.2.6 and 5.1.6. The same text names 5.1.6 as affected, so check the Espressif advisory for the 5.1 boundary.
Is there a workaround?
For ESP-IDF 5.3 and earlier, the advisory suggests checking that the data_len value in the receive callback is positive before processing it. For 5.4 and later there is no application level workaround, so upgrade.
Sources
- Safeguard Gold record: https://gold.safeguard.sh/vulnerability/CVE-2025-52471
- The CVE record text, which carries the Espressif advisory wording on affected and fixed versions and on the workaround. Espressif commits are linked from the record; the GitHub advisory page itself should be checked for the final version list.
Last reviewed: 18 October 2026.
