silabs.com vulnerabilities and threats

After receiving a malformed 802.15.4 MAC Data Request the Zigbee Coordinator sends a ‘network leave’ request to Zigbee router resulting in the Zigbee Router getting stuck in a non-rejoinable state. If a suitable parent is not available, the end devices will be unable to rejoin. A manual recommissioning is required to recover the Zigbee Router.

An integer underflow vulnerability in the Silicon Labs Z-Wave Protocol Controller can lead to out of bounds memory reads.

When a WF200/WGM160P device is configured to operate as an Access Point, it may be vulnerable to a denial of service triggered by a malformed packet. The device may recover automatically or require a hard reset.

The web interface of the Silicon Labs Simplicity Device Manager is exposed publicly and can be used to extract the NTLMv2 hash which an attacker could use to crack the user's domain password.

In a Bluetooth device, using RS9116-WiseConnect SDK experiences a Denial of Service, if it receives malformed L2CAP packets, only hard reset will bring the device to normal operation

When SmartStart Inclusion fails during the onboarding of a Z-Wave PIR sensor, the sensor will join the network as a non-secure device. This vulnerability exists in Silicon Labs' Z-Wave PIR Sensor Reference design delivered as part of SiSDK v2025.6.0 and v2025.6.1.

Due to improper input validation, a buffer overflow vulnerability is present in Zigbee EZSP Host Applications. If the buffer overflows, stack corruption is possible. In certain conditions, this could lead to arbitrary code execution. Access to a network key is required to exploit this vulnerability.

Wi-SUN unexpected 4- Way Handshake packet receptions may lead to predictable keys and potentially leading to Man in the middle (MitM) attack

The Ember ZNet stack’s packet buffer manager may read out of bound memory leading to an assert, causing a Denial of Service (DoS).

A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host system (CPCd) due to heavy Zigbee traffic, resulting in a Denial of Service (DoS) attack, Only hard reset will bring the device to normal operation

In high traffic environments, a Silicon Labs OpenThread RCP (see impacted versions) fails to clear the SPI transmit buffer and may send a corrupt packet over SPI to its host,  causing the host to reset the RCP which results in a denial of service.

The following APIs for the Silcon Labs SiWx91x prior to vesion 3.4.0 failed to check the size of the output buffer of the caller which could lead to data corruption on the host (Cortex-M4) application.sl_si91x_aes sl_si91x_gcm sl_si91x_ccm sl_si91x_sha

A ZigBee coordinator, router, or end device may change their node ID when an unsolicited encrypted rejoin response is received, this change in node ID causes Denial of Service (DoS). To recover from this DoS, the network must be re-established

A buffer overflow vulnerability in the packet handoff plugin allows an attacker to overwrite memory outside the plugin's buffer.

Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service.  If a watchdog timer is not enabled, a hard reset is required to recover the device.

An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog timer is not enabled, a hard reset is required to recover the device.

The L2CAP receive data buffer for L2CAP packets is restricted to packet sizes smaller than the maximum supported packet size. Receiving a packet that exceeds the restricted buffer length may cause a crash. A hard reset is required to recover the crashed device.

Glitch detection is not enabled by default for the CortexM33 core in Silicon Labs secure vault high parts EFx32xG2xB, except EFR32xG21B.