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

Silicon Labs EmberZNet Zigbee stack (v9.0.2 and earlier) contains a denial-of-service vulnerability affecting color-capable smart devices on your network, such as intelligent lighting controllers and…. A patch is available.

How to fix or mitigate CVE-2026-47145?

Within 24 hours: Inventory all Silicon Labs EmberZNet deployments, prioritizing devices implementing Color Control cluster (lighting nodes, coordinators). Within 7 days: Apply vendor patch to all affected devices. Within 30 days: Validate patch deployment and test end-to-end functionality of lighting control and coordination systems.

Silicon Labs EmberZNet CVE-2026-47145

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

CVE-2026-47145 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-39399 HIGH

Reachable Assertion (CWE-617)

2026-06-25 Silabs

GHSA-j947-x436-34ff

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

Attacker must be a joined Zigbee node (PR:L) reaching the target over the network (AV:N) with no interaction; crafted frame trivially triggers a crash (AC:L) causing availability-only loss (A:H).

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:29 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) allows an already-joined network device to crash the target by sending malformed Color Control cluster messages, which trigger a reachable assertion that terminates the process. Only devices implementing the Color Control cluster (typically Zigbee lighting/color-capable nodes and coordinators) are affected. Vendor-rated CVSS 4.0 7.1 with availability-only impact; no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

EmberZNet is Silicon Labs' widely embedded Zigbee 3.0 protocol stack used in IoT gateways, hubs, and smart-lighting SoCs/modules. The Color Control cluster is a standard Zigbee Cluster Library (ZCL) application-layer cluster used to manage hue, saturation, and color temperature on lighting devices. The root cause is CWE-617 (Reachable Assertion): malformed Color Control command frames reach an internal sanity-check assertion that the firmware cannot gracefully handle, causing the process/stack to abort rather than safely rejecting the bad input. This is a robustness/input-validation failure in ZCL frame parsing rather than a memory-corruption bug, which is consistent with the availability-only CVSS impact.

RemediationAI

Patch available per vendor advisory: upgrade EmberZNet beyond v9.0.2 to the fixed release distributed through the Silicon Labs SiSDK (https://github.com/SiliconLabsSoftware/sisdk-release/) and follow the advisory at https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm00000pEGPQIA4; an exact patched version number is not stated in the provided data, so confirm the target release with Silicon Labs. Because exploitation requires an already-joined device, the most effective compensating control while planning firmware updates is to tighten network admission - disable or time-box open join/permit-join, use install codes and link-key based commissioning, and avoid admitting untrusted nodes onto networks that contain color-capable devices (trade-off: makes legitimate device onboarding more operationally cumbersome). Where Color Control functionality is not used, consider disabling or not exposing that cluster on affected nodes to remove the attack surface (trade-off: breaks color/lighting control features for those devices).