A critical NFC vulnerability in Milesight sensors could expose keys protecting LoRaWAN communications if someone gains physical access to the device. The vulnerability affects specific firmware versions and is primarily associated with the use of ABP and D2D.
The official Milesight update, dated July 15, 2026, explains that ABP and D2D keys are transmitted in plain text when read via NFC. The CVE-2026-80216 gives the vulnerability a score of 8.3 and classifies the risk as high.
See also: Hackers exploit Milesight routers to send phishing SMS
What the NFC vulnerability reveals
The attack does not require an account or remote access. The attacker needs to be close to the sensor and use a suitable NFC tool to read the information. This way, they can obtain the ABP nwkskey and appskey , as well as the D2D keys
LoRaWAN keys are not just configuration elements. They can allow for traffic decryption, sensor data falsification, and sending unauthorized commands to D2D endpoints. In some cases, forged frames can lead to legitimate messages being dropped.
The report mainly concerns devices in public spaces or facilities without adequate access control. In contrast, Milesight says that devices in OTAA are not affected in the same way because the transmission via NFC is encrypted. Devices without ABP or D2D are also out of scope.
Which Milesight models are affected?
The announcement covers several sensor series. Indicatively, these include the AM102/102L V2 up to version 1.4, the AM103/103L V2 up to 1.8, the WS101 up to 1.5, the WS201 up to 1.2, as well as several models of the VS, TS, WT, UC and EM series.
There is no single common patch version for all products. For VS321, the version is v321.1.0.1-r6, while for TH-Series EM300-TH V3 and EM320-TH, the versions are 1.11 and 1.8 respectively. For many other models, Milesight places the patch version by the end of September, October or December 2026.
Administrators should not assume that a general update automatically covers every device. The exact model and firmware version should be matched to the company's dashboard before any changes are made to the network.
The same category includes the AM, WS, VS, GS, TH, TS, WT, UC and EM series, which increases the likelihood of having an affected sensor in installations with heterogeneous equipment. The notice notes that some products, such as the VS350 V3 and UC521 LoRaWAN, did not yet have a version available on the official website.
Recording serial numbers and operating settings helps quickly identify devices that need to be changed, while security teams can alert facility managers to the risk of uncontrolled access.
Because the CVE-2026-80216 does not include a complete list of models, the safest course of action is to check the official Milesight page rather than assuming that a similar model is out of danger. The update should be combined with a key change where there is evidence that the keys have been read.
NFC vulnerability is not addressed by changing settings in the central system alone. Physical security, device inventory, and version tracking must be integrated into the same process.
See also: Hackers use fake CAPTCHA in new SMS scam
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Immediate protection measures for LoRaWAN keys
Until the appropriate firmware is available, the SecNews technical team recommends restricting physical access to sensors and registering all devices operating with ABP or D2D. Milesight recommends, where possible, migrating from ABP to OTAA via Toolbox, deleting the old profile on the network server, and re-enrolling the device.
The company also recommends temporarily disabling D2D when not necessary. After the change, administrators should renew any exposed keys, review access paths, and look for unusual traffic or commands to sensors.
The NFC vulnerability shows that the security of an IoT network does not depend solely on the remote software. A point installed in a shared space can reveal critical credentials if encryption, proper activation mode, and physical access control are not combined.
The transition to OTAA should not be done mechanically. Coordination with the LoRaWAN server is required, as the old ABP profile must be removed and the device must be re-registered with the correct information. Operators should keep a copy of the configuration and confirm that measurements continue to arrive normally.
See also: WhatsApp Update: Multiple passkeys and stronger 2SV
