CVE-2023-6874 is a high severity (CVSS 7.5) denial of service in Silicon Labs Ember ZNet, which is part of the Gecko SDK, in versions before 7.4.0. It works through manipulation of the NWK sequence number. Upgrade to Ember ZNet 7.4.0 or later.
What's affected
The record says versions prior to 7.4.0 of Ember ZNet are affected, and lists the Silicon Labs Gecko Software Development Kit. The Silicon Labs community post referenced by the record did not load for automated reading, so check it for the Gecko SDK release that carries Ember ZNet 7.4.0.
Products are affected when they build on an SDK release that bundles an older Ember ZNet stack. That includes Zigbee devices from many manufacturers, since the stack is compiled into firmware.
How to check if you're exposed
Ask your firmware team which Gecko SDK and which Ember ZNet stack version each product uses. Build systems usually record this in the SDK metadata or project files.
If you are a buyer rather than a builder, ask the device vendor whether their firmware uses a Silicon Labs Ember ZNet stack older than 7.4.0, and whether a firmware update is available.
What to do now
- Move builds to a Gecko SDK release that includes Ember ZNet 7.4.0 or later.
- Ship a firmware update, and plan how field devices will receive it.
- Confirm in testing that devices recover when the network sees abnormal sequence numbers.
- Record the SDK version for each product in your inventory.
Why it matters
The description says an attacker can cause denial of service by manipulating the NWK sequence number. In a mesh network, sequence numbers help a device decide whether a frame is fresh or a replay. If the stack handles unexpected values poorly, a nearby sender can make a device drop out of the network. The record tags CWE-312 and CWE-754, which do not line up neatly with that description, so rely on the description.
Embedded wireless stacks are hard to patch once deployed. The practical lesson is to build update paths into every device before it ships.
Firmware and engineering software update slowly. Start with an inventory of what you run and where it connects. Network isolation buys time while you test and schedule updates, and it is usually the first measure vendors recommend. Give each exception an owner and a review date so the workaround does not become permanent.
Weakness class in the record: CWE-754 (Improper Check for Unusual or Exceptional Conditions) CWE-312 (Cleartext Storage of Sensitive Information).
Quick check
Can I fix this without a firmware update?
The fix is in the stack, so it needs a firmware build with Ember ZNet 7.4.0 or later. Network design can limit exposure, but it cannot replace the update.
What if we cannot patch quickly?
Reduce who and what can reach the device. Segment the network, restrict management access to a known host, and record the exception with an owner and a review date.
Sources
The Silicon Labs page did not load for automated reading, so details come from the NVD record.
Last reviewed: 19 October 2026.
