Silicon Labs EmberZNet CVE-2026-47149

Exploitation requires the attacker to control a device that has ALREADY joined the target Zigbee network (the messages 'must come from a device that has already joined the network'), so prior network membership/authentication is a hard prerequisite - this is reflected in PR:L. The target must implement and support the Zigbee Door Lock cluster; devices without that cluster are not impacted. The trigger is a Door Lock command carrying a malformed or out-of-range Door Lock user identifier, which forces the out-of-bounds table read. Affected build must be EmberZNet 9.0.2 or earlier. Limiting factors that reduce realistic risk: no remote unauthenticated path (must be a joined device), impact is confined to a process crash/DoS with no code execution and no data disclosure back to the attacker, and only Door-Lock-capable devices are in scope.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with impact limited to VA:H (availability only; VC:N/VI:N/VA:H) scores 7.1 and accurately reflects a network-reachable but membership-gated denial of service with no confidentiality or integrity impact. The key limiting factor is PR:L: the malicious messages 'must come from a device that has already joined the network,' so an attacker first needs to be an authenticated Zigbee network participant rather than an arbitrary remote host, which substantially narrows the realistic threat to compromised/rogue joined devices. There is no EPSS value, no KEV listing, and no POC in the provided data, so real-world exploitation pressure appears low and any exploitation would be targeted rather than opportunistic. Note a conflict in the source data: the tags list 'Information Disclosure' and 'Buffer Overflow', but the description explicitly states no information leakage was observed and the CVSS sets VC:N - treat this as a pure availability/crash issue, not an info-disclosure or memory-corruption RCE, unless the vendor advisory states otherwise.

An attacker who has compromised or spoofed a device already joined to the Zigbee network sends a crafted Door Lock command containing an out-of-range user identifier to a target device that supports the Door Lock cluster. The malformed identifier causes an out-of-bounds table read in EmberZNet that terminates the stack process, knocking the lock/controller offline (a crash/DoS). No public exploit code is identified at time of analysis, and the low attack complexity means a joined attacker can repeat the crash to sustain the outage.