Schneider EmberZNet Zigbee Flaws: Immediate Mitigations for Wiser and Iconic

Schneider Electric has confirmed that a wide range of its Zigbee-based Wiser and Iconic products are affected by multiple vulnerabilities in Silicon Labs’ EmberZNet Zigbee stack, and the vendor is urging customers to apply immediate mitigations to avoid Denial‑of‑Service (DoS) outages that can render smart thermostats, dimmers, sockets and even EV charging sockets unavailable. l.lu])

Background / Overview​

Schneider Electric published a Common Security Advisory Framework (CSAF) notice that maps a cluster of EmberZNet vulnerabilities disclosed by Silicon Labs to dozens of Schneider Zigbee SKUs in the Wiser and Iconic families. The affected list includes, among others, Wiser iTRV2/iTRV3 thermostats, Wiser RTR, Wiser UFH, Wiser micromodules, Iconic Wiser Connected dimmers and switches, connected socket outlets, and Mureva EV Link. The vendor warns that failure to apply the recommended mitigations mayservice and product unavailability.
At a technical level the problems are not a single flaw but several related weaknesses in the EmberZNet (Silicon Labs Zigbee) stack: multiple buffer‑overflow style issues in different protocol layers (MAC, NWK, APS), and an uncontrolled resource consumption / state‑corruption issue related to unsolicited encrypted rejoin responses. These are tracked under a family of CVEs including CVE‑2024‑6350, CVE‑2024‑6351, CVE‑2024‑6352, CVE‑2024‑10106 and CVE‑2024‑7322. Public vulnerability databases and vendor advisories describe these as causing assertion failures or stack corruption that lead to device crashes and DoS.

---

What’s affected — products, versions and impact​

A broad footprint across home and building automation​

Schneider’s CSAF advisory lists many product SKUs and declares “All Versions” of those SKUs as known affected for the CVEs mapped in the advisory. That means owners of these products must treat the exposure as present until a vendor firmware release or other explicit remediation is published. The advisory expli and Iconic families plus branded micromodules and socket outlets.

The technical impact: Denial of Service (primary) and stability loss​

• Buffer overflow defects in the MAC, network (NWK) or APS layers may trigger internal assertions or memory corruption that halt the Zigbee thread, forcing device resets or leaving devices unresponsive until network re‑join or human intervention. CVE descriptions show DoS via malformed 802.15.4 or Zigbee packets as the likely exploitation path.
• The unsolicited encrypted rejoin response issue (CVE‑2024‑7322) can cause a device to change its node ID, which may break routing and require a full network re‑establishment to recover. That is an availability impact with operational friction for end users.

Who should care?​

• Homeowners and building managers using Wiser/Iconic smart thermostats, smart outlets, dimmers, motorized shutters and EV sockets.
• Integrators and installers who manage fleets of Wiser/Iconic devices in multi‑dwelling units or commercial buildings.
• OT/IT teams responsible for building control systems that may interconnect Zigbee gateways to higher‑level automation or monitoring platforms — because denial of local devices can cascade into perceived service outages and support calls.

---

Verification and cross‑checks​

I cross‑verified the Schneider advisory payload (the CSAF document provided) with public vulnerability recordres:

• Schneider’s CSAF advisory listing of affected SKUs and the recommended mitigations is present in the uploaded advisory file and JSON view.
• CVE trackers and vulnerability databases independently record the EmberZNet issues: CVE‑2024‑6350 (malformed 802.15.4 packet -> buffer overflow / DoS) and sibling CVEs (CVE‑2024‑6351, CVE‑2024‑6352) are cataloged in public CVE/NVD mirrors and summarized by third‑party trackers. These entries describe the same class of assertion/buffer overflow failures that Schneider attributes to Silicon Labs’ stack.
• The rejoin response problem (CVE‑2024‑7322) appears in multiple vulnerability trackers and in Silicon Labs’ community advisories, identifying EmberZNet version ranges where the behavior was corrected.

Where vendor advisories and independent CVE entries differ, I call those differences out below; in all cases readers should confirm final status with Schneider Electric support or the device release notes for their specific SKU.

---

Immediate mitigations Schneider recommends — and what they mean in practice​

Schneider’s immediate mitigation guidance is practical and focuses on reducing Zigbee network exposure and making paihenticated devices. The vendor’s recommended steps (paraphrased and operationalized) are:

• Restrict device access: Do not permit unknown devices to join the Zi hub or coordinator has a persistent open join window, close it.
• Review hub settings: Confirm how the Zigbee hub manages pairing and whether it allows facopen join modes by default. Disable open joins.
• Control network availability: Only open the network for new devices and immediately close it. Use the hub app or gatewwindows tightly.
• Use install codes and unique keys: Prefer unique install codes for new devices and avoid relying on the well‑known global key. Replace default keys where possible.

These mitigations are effective at reducing the attack surface because all of the CVEs require that a malformed or malicious Zigbee/802.15.4 packet be accepted and processed by a device. Limiting joins, preventing unknown nodes and avoiding default keys make it harder for an attacker to get a foothold on your Zigbee fabric.
Practical note: for many consumer Wiser deployments, the easiest immediate steps are (1) close join windows in the Wiser app or coordinator UI, (2) check that your coordinator/hub firmware is current, and (3) if possible, enable install code pairing for devices. If your hub is managed by a third party (integrator), instruct them to apply these settings immediately.

---

Recommended operational checklist — what integrators and IT/OT teams should do now​

• Inventory: Identify every Wvice on site. Create a spreadsheet with device type, part number, serial, firmware version and its Zigbee coordinator/hub. This is the baseline for any remedial action.
• Isolate: If Zigbee devices are bridged to management or bure the bridge/gateway is segmented behind firewalls and that only authorized management traffic is allowed. Follow OT segmentation best practices.
• HardClose join windows and disable automatic/unsupervised pairing. Use install codes or unique keys when provisioning new devices.
• Monitor: Enable and monitor logs on Zigbee hubs and gateways. Look for repeated malformed frames, abnormal join attempts or unexplained device resets. If available, integrate gateway logs into your SOC/IDS.
• Patching plan: Check Schneider and Silicon Labs for firmware updates that remediate the EmberZNet flaws. If Schneider publishes fixed firmware for a SKU, validate and schedule a staged deployment (test → pilot → production). If no patch is available, maintain mitigation posture.
• Communication: Inform occupants and stakeholders that devices are being protected, that short disruptions may occur during remediation, and provide a support channel for device failures.

---

Technical analysis — why these vulnerabilities are significant​

Buffer overflows in Zigbee stack layers (MAC, NWK, APS)​

Buffer overflows in low‑level protocol handling are classic and dangerous because the code paths process untrusted radio frames coming from neighbors or nearby attackers. The EmberZNet issues described across CVE‑2024‑6350/6351/6352 indicate that some packet parsing functions do not sufficiently bound‑check incoming payload lengths, leading to stack corruption or assertion failures when malformed frames are received. In constrained IoT firmware, assertions and unhandled memory corruption often translate directly to thread termination or system resets — i.e., practical DoS. Public CVE entries corroborate this behavior.

Rejoin response behavior and resource exhaustion (CVE‑2024‑7322)​

The unsolicited encrypted rejoin response issue is a protocol‑level logic problem: devices accept a rejoin response that changes their node identity/state in ways that break routing or network tables, requiring manual re‑provisioning or a full network rebuild to recover. This is less about raw memory corruption and more about state integrity and resource exhaustion, but the operational result is the same — devices become unavailable. CVE trackers indicate EmberZNet versions where this behavior was addressed.

Exploitability and real‑world risk​

Public trackers show modest EPSS or exploit prediction scores for these CVEs, and many vendors and researchers report no widespread exploitation as of the advisory dates. That said, the attack vector is local/adjacent network (radio/mesh) and some attacks may be feasible with modest effort from a nearby attacker or compromised device inside the mesh. For deployments in apartments, densely populated buildings, or multi‑tenant commercial sites, the risk is materially higher. Also, because Wiser devices are often used for climate control and EV charging, DoS can have real user impact (cold rooms, heating loss, EV charging interruption). ([cvefeed.io](CVE-2024-6350 - EmberZNet malformed MAC layer packet leads to denial of service# Strengths of Schneider’s response — and where gaps remain

Notable strengths​

• Timely disclosure and CSAF format: Schneider published a structured advisory that maps CVEs to SKUs and provides immed, which is the right approach for transparency and operational guidance.
• Practical mitigations: The vendor’s emphasis on closing join windows, using install codes, and reviewing hub pairing behavior are effective short‑term controls that most users can implement quickly.

Remaining concerns and practical gaps​

• **“All Versions” designation creates operatiisting products as affected across all firmware versions without clear fixed‑release mappings forces operators into a conservative posture (treat everything as vulnerable), complicating prioritization. This makes the inventory and isolation steps more urgent.
• Patch cadence and availability: As of the advisory there is no universal Schneider firmware release list that clearly shows which SKUs already have fixed firmware and which remain pending. Customers must verify firmware availability per SKU with Schneider support. That specific status often requires a vendor support ticket or portal check and is not always included in the CSAF summary.
• Supply chain dependence on Silicon Labs: Many vendors rely on Silicon Labs’ Zigbee stack; thus the impact is multi‑vendor and sometimes patch timing depends on silicon vendor fixes being integrated by device OEMs. This creates a coordination challenge for integrators and large customers.

I flag the last two points as operational risks that require active vendor engagement and realistic planning: do not assume a one‑click remediation; prepare for staged testing and possible hardware replacement for devunsupported.

---

Practical guidance for three user groups​

1) Homeowners and small‑site users (Wiser app users)​

• Immediately close join windows inid pairing new Zigbee devices until you confirm mitigations are applied.
• Reboot your Zigbee hub and check its firmware version; if a hub firmware update is available, read the release notes and apply in a maintenance window.
• If you lose critical devices (heating/cooling, EV charger), treat the outage as a support ticket and prioritize replacement/repair if the device cannot rejoin or remains unstable.

2) Bintegrators​

• Execute the operational checklist (inventory, isolate, harden pairing, monitor). Use VLANs and firewall rules to segregate IoT/Zigbee gateway management and restrict remote management channels.
• Schedule staged ft on a small subset, monitor for stability and device behavior, then expand to production. Document rollbacks and recovery procedures in case a firmware update causes unexpected behavior.

3) Enterprise and critical‑services operators​

• Treat these devices as part of your OT/IoT risk regianalyses for device failures (e.g., heating in tenant spaces, EV provisioning) and map compensating controls (temporary backup heating or managed charging schedules).
• Work with Schneider Electric account or support teams to obtain official statements, patched firmware images, and upgrade plans. Validate cryptographic key management practices for Zigbee Trust Center implementations in your environment.

---

Communication template — what to tell users/customers now​

• We have identified a vendor‑advised vulnerability affecting some Zigbee devices used in our building/home automation systems. The vendor recommends closing device join windows, using install codes, and *restri. We are implementing those mitigations now and will schedule firmware updates when Schneider publishes vendor‑approved fixes for our exact SKUs.

This straightforward message helps manage expectations and shows you are taking immediate action rather than waiting for a patch.

---

Longer‑term lessons for IoT/OT device owners​

• Source diversity and vendor lock‑in matter: reliance on a single Zigbee stack vendor increases systemic risk across many brands and product lines. Operators should evaluate the vendor patch lifecycle and support commitments before large rollouts.
• Architectural controls beat reactive patching: network segmentation, principle of least privilege for device management and robust logging reduce t of zero‑day style stack problems.
• Lifecycle planning: create EOL replacement strategies for devices that cannot be patched in a timely fashion. If a product is unsupported, plan to replace or isolate it.

---

Caveats and unverifiable items​

• Schneider’s advisory marks numerous SKUs as “All Versions” affected. I cannot, from the advisory alone, confirm whether Schneider has since published patch versions for es checking Schneider’s product support portal or contacting Schneider Electric CPCERT. Until you confirm a fixed firmware image and validate it in testing, treat the devices as vulnerable.
• Public CVE records and vendor posts indicate the EmberZNet fixes are included in specific EmberZNet version ranges (for example fixes landing in EmberZNet 7.4.4 / 8.1.0 and later in some cases), but device OEMs must integrate and ship those stack updates in their firmware. That OEM integration step — and the timeline for each Schneider SKU — is not guaranteed synchronously across the product list and must be verified case‑by‑case.

---

Final assessment and recommendations​

This advisory is a classic example of a silicon‑stack vulnerability propagating across a product ecosystem. The immediate risk is Denial of Service — not remote code execution or data exfiltration in the majority of the lin device‑critical functions (heating, EV charging, power switches) is a practical and painful outcome for owners and operators.
Ds):

• Close Zigbee join windows and harden pairing on all hubs and coordinators.
• Inventory and segment: know every Wiser/Iconic device you own and ensure Zigbee gateways are properly segmented and logged.
• Contact Schneider support for SKU‑specific patch status and subscribe to vendor advisories for firmware releases. Treat any announced firmware as requiring staged testing before wide deployment.
• Prepare recovery and communication plans for potential device outages — particularly for heating and EV charging use cases — while mitigations and patches are applied.

Schneider’s advisory gives clear operational mitigations that materially reduce risk; follow them now while you verify firmware remediation paths with the vendor. Cross‑reference Schneider’s advisory with public CVE/NVD records to track the EmberZNet fixes’ appearance in firmware release notes — but don’t assume a fix is present until Schneider publishes and your testing validates it.

---

In summary: treat the Schneider/EmberZNet notices as high‑priority operational guidance. The vulnerabilities are not theoretical — they are real parsing and state‑management issues in a widely deployed Zigbee stack — and Schneider’s published mitigations are effective first‑line defenses. Prioritize inventory, close pairing windows, isolate Zigbee gateways, and coordinate with Schneider support for firmware updates and a safe, staged remediation plan.

---

Source: CISA Schneider Electric Zigbee Products | CISA