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

Silicon Labs EmberZNet Zigbee stack versions 9.0.2 and earlier contain a denial-of-service vulnerability that can crash connected devices.. A patch is available.

How to fix or mitigate CVE-2026-4526?

Within 24 hours: Asset inventory of all EmberZNet deployments (v9.0.2 and earlier); obtain patched version details from Silicon Labs security advisory. Within 7 days: Validate patched firmware in test environment; confirm backward compatibility and stability. Within 30 days: Deploy patched version across all production systems, prioritizing critical infrastructure and customer-facing deployments.

EmberZNet CVE-2026-4526

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

CVE-2026-4526 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-39396 HIGH

Out-of-bounds Read (CWE-125)

2026-06-25 Silabs

GHSA-xq6v-3fpg-crf4

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

5.7 MEDIUM

Attacker must be a joined node on a local Zigbee PAN, so AV:A and PR:L; low complexity, and impact is crash-only, so C:N/I:N with A:H.

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:28 vuln.today

DescriptionCVE.org

In EmberZNet v9.0.2 and earlier, malformed global ZCL messages can trigger out-of-bounds reads in framework parsing logic 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.

AnalysisAI

Denial of service in Silicon Labs EmberZNet (Zigbee stack) v9.0.2 and earlier allows an already-joined Zigbee device to crash the process by sending malformed global ZCL (Zigbee Cluster Library) messages that trigger out-of-bounds reads in the framework parsing logic. The flaw affects availability only - no information leakage back to the sender was observed despite the dataset's 'Information Disclosure' tag. A vendor patch is available, and there is no public exploit identified at time of analysis.

Technical ContextAI

EmberZNet is Silicon Labs' embedded Zigbee networking stack shipped in their EFR32/Wireless Gecko SoCs and SDKs, implementing the Zigbee Cluster Library (ZCL) used for application-layer messaging between Zigbee devices. The root cause is CWE-125 (Out-of-Bounds Read): the framework's parser for global ZCL commands does not adequately validate field lengths or boundaries when handling malformed frames, reading past the intended buffer and faulting the device firmware. CPE cpe:2.3:a:silicon_labs:emberznet:*:*:*:*:*:*:*:* identifies the affected component as the EmberZNet application stack across versions up to and including 9.0.2.

RemediationAI

Patch available per vendor advisory: upgrade EmberZNet to the fixed release published by Silicon Labs above version 9.0.2 via the Simplicity SDK update (sisdk-release at https://github.com/SiliconLabsSoftware/sisdk-release/ and the advisory at https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm00000pEGPQIA4); an exact fixed version string is not stated in the provided data, so confirm the target build from the advisory before deploying firmware. Because exploitation requires an already-joined device, the primary compensating control is tightening network admission: disable or close the Zigbee permit-join window after commissioning, use install codes / link-key based joining rather than well-known keys, and audit/remove untrusted joined nodes - the trade-off is added friction when onboarding new legitimate devices. Implement firmware watchdog/auto-restart so a crashed node recovers quickly, accepting that this mitigates impact (uptime) but not the underlying parsing flaw.