CVE-2026-16101

CVE-2026-16101 exposes a re-pairing vulnerability in the RS9116W and SiWx917 BLE chipsets where a spoofed device can trigger pairing re-initialization even when valid bond records already exist. The flaw lives in chipset firmware, not application code—meaning you cannot patch it from your product's software layer. You are dependent on Silicon Labs or RSI/Renesas to distribute a firmware update, and many IoT devices shipping these modules lack any meaningful update mechanism at all. This is not a novel bug class. Bluetooth pairing bypasses recur every 3-5 years across implementations, but this cycle is different: the consolidation of BLE silicon around a handful of vendors means one flawed firmware commit propagates into thousands of products simultaneously. The re-pairing path likely originated as a factory or development convenience feature—allowing bond records to be force-reset during debugging—but that context has been abandoned while the mechanism survived. No one deploying these chips in a smart lock intended for that code path to remain reachable. What you should do: First, identify which of your products use RS9116W or SiWx917 modules and check with your module vendor for firmware revision history. Second, audit whether your application-layer pairing logic performs any identity verification before accepting a re-pairing request—some application stacks can detect and reject this behavior even with vulnerable firmware, though this is a defense-in-depth measure, not a complete fix. Third, for any deployed devices where firmware updates are infeasible, treat the BLE bonding interface as a trusted channel only—do not rely on pairing as your security boundary for those products. The EPSS score currently suggests limited immediate exploitation, but this will shift as tooling matures and these chipsets proliferate in smart home, industrial, and medical devices. The real risk is not the CVE in isolation but the concentrated attack surface created by shared chipset firmware across millions of devices—one unpatched firmware version creates correlated vulnerability across your entire product ecosystem.

Reviewed through automated stages and approved by a human before publication.