HIGH 7.1

CVE-2026-47150: EmberZNet IAS Zone Out-of-Bounds Write DoS

EmberZNet, Silicon Labs' Zigbee networking stack, contains a flaw in how it processes enrollment messages from the IAS (Intruder Alarm System) Zone cluster. A device already connected to the network can send specially crafted enrollment packets that cause the software to write data beyond the intended boundaries of a state table, crashing the process. The vulnerability is confined to network-adjacent attackers with prior network membership and only affects devices that implement IAS Zone functionality.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Weaknesses (CWE)
CWE-787
Affected products
1 configuration(s)
Published / Modified
2026-06-25 / 2026-06-25

NVD description (verbatim)

In EmberZNet v9.0.2 and earlier, malformed IAS Zone enrollment messages can trigger an out-of-bounds state-table write and terminate the process. The size and location of this write is limited. These messages must come from a device that has already joined the network. Only devices supporting the IAS Zone cluster may be impacted.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-47150 is an out-of-bounds write vulnerability (CWE-787) in the IAS Zone cluster message handling of EmberZNet v9.0.2 and earlier. When a joined device sends a malformed IAS Zone enrollment message, the stack performs an unchecked write to a state table, exceeding the allocated buffer. Although the write size and offset are constrained, the out-of-bounds condition can terminate the affected process, resulting in denial of service. Exploitation requires network access and prior device enrollment.

Business impact

Organizations deploying EmberZNet-based Zigbee systems—particularly in building automation, industrial IoT, and smart home environments—face process crashes and service disruption when a networked device launches this attack. While integrity and confidentiality are not directly compromised, availability impact is significant: a single malicious or compromised endpoint can crash critical network infrastructure. Recovery typically requires manual restart and network re-establishment. In environments where IAS Zone is used for security monitoring (alarm systems), this denial of service could disable intrusion detection capabilities during the outage.

Affected systems

EmberZNet versions up to and including v9.0.2 are vulnerable. Only devices that support the IAS Zone cluster are at risk; Zigbee devices not implementing this cluster are unaffected. Affected deployments are typically found in commercial and residential security systems, industrial control networks, and IoT platforms built on Silicon Labs Zigbee stacks. The vulnerability requires an attacker to already be a joined member of the target network, limiting the scope to insider threats or compromised endpoints within the mesh.

Exploitability

Exploitation is moderately feasible but requires specific preconditions. The attacker must already have network membership—either as a legitimate enrolled device or through a prior compromise—and must target nodes that support IAS Zone. No user interaction is required once the attacker is on the network. The attack is deterministic: a single malformed message reliably crashes the process. However, the lack of public exploit tooling and the requirement for prior network access keep real-world risk below critical, despite the HIGH CVSS score reflecting high availability impact.

Remediation

Update EmberZNet to a patched version released after v9.0.2. Verify the exact version number against Silicon Labs' security advisory and apply updates via the standard vendor delivery channels. In parallel, implement network segmentation to restrict which devices can send IAS Zone enrollment messages, and monitor for unexpected enrollment traffic patterns. Restart affected processes after patching to ensure the fix is in effect.

Patch guidance

Silicon Labs will provide an updated EmberZNet release that sanitizes IAS Zone enrollment message handling and validates message length and state-table bounds before writing. Consult the official Silicon Labs security advisory for the specific patched version number and deployment instructions. Test patches in a non-production Zigbee network before wide rollout to ensure compatibility with existing devices and integrations. Priority should be given to deployments where IAS Zone is actively used for security-critical functions.

Detection guidance

Monitor for unexpected process crashes or restarts on devices running EmberZNet, especially following unusual Zigbee network activity. Packet analysis of IAS Zone enrollment messages (cluster 0x0500) can reveal malformed packets with incorrect length fields or payloads. Set alerts for repeated IAS Zone enrollment attempts from a single source device, which may indicate attack reconnaissance. Review logs for denial-of-service patterns—sudden unavailability of Zigbee coordinator or router nodes—correlating timing with potential attacker activity.

Why prioritize this

Although the CVSS score of 7.1 reflects significant availability risk and the vulnerability is exploitable by a joined attacker with no user interaction, real-world impact is moderate because exploitation requires prior network membership and affects only IAS Zone-enabled devices. Prioritize patching if your organization operates security-critical IAS Zone systems (alarm monitoring, intrusion detection) or if you operate large, multi-tenant Zigbee networks where device compromise is a credible insider threat. Standard-priority patching is appropriate for general IoT and building automation deployments where IAS Zone is optional or rarely used.

Risk score, explained

CVSS 7.1 (HIGH) reflects: (1) network-based vector and low attack complexity (AV:N, AC:L), (2) requirement for prior authentication as a network member (PR:L), (3) no user interaction (UI:N), (4) scoped to the process (S:U), (5) no confidentiality impact (C:N), and (6) partial integrity and high availability impact (I:L, A:H). The high availability component—process termination and service unavailability—drives the score. The requirement for prior network membership prevents a critical rating despite the reliable denial of service.

Frequently asked questions

Do all Zigbee devices running EmberZNet need to be patched?

No. Only devices that support the IAS Zone cluster are affected. If your deployment uses EmberZNet for general lighting, HVAC, or other clusters but does not implement IAS Zone, the vulnerability does not directly impact you. However, if a coordinator or router node in your network does support IAS Zone, it can be targeted by a joined attacker and should be patched.

Can an attacker outside the network exploit this vulnerability?

No. Exploitation requires the attacker to have already joined the Zigbee network. If your network uses a strong joining key or restricts device enrollment, the barrier to attack is higher. However, once an attacker has network membership—either legitimately or through a compromised device—the attack is straightforward and requires only a single malformed message.

What happens when the vulnerability is exploited?

The targeted process crashes, typically the Zigbee coordinator or a router node. This causes temporary loss of connectivity for devices served by that node and may require manual restart. The network does not automatically heal without intervention. If the affected node is a security-critical component (e.g., alarm gateway), the outage directly impacts monitoring and response capabilities.

Are there workarounds if I cannot patch immediately?

Temporary mitigations include: isolating IAS Zone devices to a separate network segment, disabling IAS Zone enrollment if not in active use, monitoring for anomalous enrollment messages, and maintaining offline failover systems for critical alarm functions. These do not eliminate the vulnerability but reduce the window and impact of a successful attack. Patching should remain the primary remediation goal.

This analysis is based on publicly available vulnerability data as of the publication date. Patch version numbers and specific remediation steps should be verified against Silicon Labs' official security advisory. Real-world impact may vary based on network architecture, device composition, and operational practices. This advisory does not constitute legal or compliance advice; organizations should evaluate risk within their own threat model and regulatory environment. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).