Which versions of Silicon Labs EmberZNet are affected by CVE-2026-47149?

Silicon Labs EmberZNet Zigbee-based physical access control systems face a critical operational risk from denial of service attacks.. A patch is available.

How to fix or mitigate CVE-2026-47149?

24 hours: Identify all systems and devices using Silicon Labs EmberZNet Zigbee with Door Lock cluster implementation. 7 days: Obtain vendor patches, conduct compatibility testing, and initiate staged firmware update deployment. 30 days: Complete firmware upgrades to patched versions per Silicon Labs advisory across all affected devices.

Silicon Labs EmberZNet CVE-2026-47149

Q: What is the CVSS score of CVE-2026-47149?

CVE-2026-47149 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-39404 HIGH

Out-of-bounds Read (CWE-125)

2026-06-25 Silabs

GHSA-4g44-cv7p-fgrg

Buffer Overflow Information Disclosure Emberznet Silicon Labs

7.1

CVSS 4.0 · Vendor: Silabs

Severity by source

Vendor (Silabs) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.5 MEDIUM

Reachable over the network but only from an already-joined device (PR:L), low complexity (AC:L), and impact is solely a process crash (A:H) with no confidentiality or integrity effect.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Silabs).

CVSS VectorVendor: Silabs

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 25, 2026 - 14:31 vuln.today

DescriptionCVE.org

In EmberZNet v9.0.2 and earlier, malformed or out-of-range Door Lock user identifiers can trigger out-of-bounds table reads and terminate the process. These messages must come from a device that has already joined the network, and no information leakage back to the sender was observed. Only devices supporting the Door Lock cluster may be impacted.

AnalysisAI

Denial of service in Silicon Labs EmberZNet Zigbee stack (v9.0.2 and earlier) lets an already-joined network device crash the target by sending Door Lock cluster messages containing malformed or out-of-range user identifiers, which trigger an out-of-bounds table read (CWE-125) that terminates the process. Only devices that implement the Door Lock cluster are affected, and no data is leaked back to the sender. There is no public exploit identified at time of analysis, and the issue is not in CISA KEV.

Technical ContextAI

EmberZNet is Silicon Labs' widely embedded Zigbee protocol stack, shipped in IoT and smart-home device firmware (gateways, hubs, and Zigbee end devices). The flaw lives in the Zigbee Cluster Library (ZCL) Door Lock cluster handling: a Door Lock 'user identifier' supplied in a received command is used to index an internal user table without adequate bounds validation. When the identifier is malformed or out of range, the code performs an out-of-bounds read against that table (CWE-125, classic out-of-bounds read), and the resulting fault terminates the process running the stack. The CPE cpe:2.3:a:silicon_labs:emberznet:*:*:*:*:*:*:*:* confirms the affected product is the EmberZNet application/SDK component.

RemediationAI

Upgrade the EmberZNet stack to the vendor-patched release: a patch is available from Silicon Labs (Patch available per vendor advisory; the exact fixed version is not enumerated in the provided data, so confirm the target version against the advisory at https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm00000pEGPQIA4?operationContext=S1 and the patched sources at https://github.com/SiliconLabsSoftware/sisdk-release/, then rebuild and reflash affected device firmware). Because this is firmware-embedded, plan an OTA or physical update campaign for all devices running 9.0.2 or earlier that expose the Door Lock cluster. Where immediate patching is impractical, compensating controls are limited but include: tightening Zigbee network admission (strict install-code/link-key provisioning and disabling open joining) to prevent rogue devices from joining and reaching the cluster - trade-off is added commissioning friction; and, where a device does not actually need Door Lock functionality, disabling or not advertising the Door Lock cluster removes the attack surface - trade-off is loss of that lock feature. Monitoring for unexpected stack restarts/crash loops can help detect attempts.