Which versions of EmberZNet are affected by CVE-2026-47146?

Silicon Labs EmberZNet Zigbee stack (v9.0.2 and earlier) contains a denial-of-service vulnerability affecting color-capable lighting devices on affected networks.. A patch is available.

How to fix or mitigate CVE-2026-47146?

Within 24 hours: Inventory all deployed Silicon Labs EmberZNet devices; identify version numbers and Color Control cluster implementation status. Within 7 days: Obtain vendor patch and stage deployment on non-production Zigbee test networks; validate Color Control functionality post-update. Within 30 days: Deploy patch across all production Zigbee infrastructure; complete update of device firmware records in asset management systems.

EmberZNet CVE-2026-47146

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

CVE-2026-47146 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-39400 HIGH

Reachable Assertion (CWE-617)

2026-06-25 Silabs

GHSA-9wp6-568f-352r

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

5.7 MEDIUM

Zigbee RF requires local network membership and radio reach, so AV:A and PR:L rather than the vendor's AV:N; a pure crash gives A:H with C:N/I:N and unchanged scope.

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

4.0 AV:A/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:30 vuln.today

DescriptionCVE.org

In EmberZNet v9.0.2 and earlier, malformed Color Control messages can lead to asserts that terminate the process. These messages must come from a device that has already joined the network. Only devices supporting the Color Control 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 a target by sending malformed Color Control cluster messages that trip a reachable assertion and terminate the process. Only devices implementing the Color Control cluster (typically color-capable lighting) are affected, and the attacker must already be a member of the Zigbee network. No public exploit identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

EmberZNet is Silicon Labs' widely embedded Zigbee protocol stack running on its wireless SoCs and modules in IoT and smart-lighting products. The Color Control cluster is a standard Zigbee Cluster Library (ZCL) component used to manage color, hue, and saturation on lighting devices. The root cause is CWE-617 (Reachable Assertion): malformed inbound Color Control frames are not validated before reaching an assert(), which on failure aborts the firmware process. The vulnerable code path exists only on devices that support the Color Control cluster.

RemediationAI

Patch available per vendor advisory - upgrade EmberZNet beyond 9.0.2 using the fixed firmware published in the Silicon Labs SiSDK release repository (https://github.com/SiliconLabsSoftware/sisdk-release/) and consult the advisory at https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm00000pEGPQIA4 for the exact patched version, which was not specified in the available data. Until firmware can be updated, reduce exposure by tightening network membership: keep the Zigbee network closed to new joins (disable permit-join), enforce install-code/link-key provisioning so untrusted devices cannot join, and audit and remove unrecognized joined devices, since exploitation requires an already-joined node. These controls limit who can reach the vulnerable cluster but do not fix the underlying assertion, and disabling permit-join will block legitimate device commissioning until it is re-enabled.