CVE-2026-19291

The 8.8 CVSS score on CVE-2026-19291 is technically accurate but operationally misleading for the environments where RS9116W and SiWx91x silicon actually lives. These aren't consumer chips getting firmware updates next Tuesday — they're embedded radio modules in industrial controllers, medical peripherals, and POS hardware where over-the-air updates are rare and validation cycles span years. The EPSS score of 0.00211 reflects the absence of telemetry sensors in embedded deployment ecosystems, not attacker disinterest. These are not the same thing, and treating them as equivalent has historically led defenders to conclude a vulnerability is dormant when it's actually unobserved. What makes this analytically distinct from comparable Bluetooth downgrade flaws is the re-pairing trigger mechanism. The attack surface isn't a protocol implementation flaw you patch — it's a legitimate user action. An attacker with brief physical proximity during a re-pairing event (maintenance window, battery replacement, firmware update) can permanently lock in reduced security for all subsequent sessions. This is a credential state change, not a transientMitM window. Defenders have no reliable way to detect that it happened without chip-level telemetry that most deployments don't collect. The BLERP paper's academic characterization of V3 means the vulnerability class is now in the public analytical record, lowering the barrier for targeted exploitation. Historical precedent from comparable wireless protocol vulnerabilities (Zigbee, Z-Wave) shows that when academic characterization includes reproducible PoC conditions, the disclosure-to-weaponization timeline compresses significantly — often well under the 12-18 months that EPSS models implicitly assume for server-side flaws. For deployments using RS9116W or SiWx91x, the immediate priority is audit, not patching. You cannot patch your way out of this: the deployment model that makes these chips attractive (stable, embedded, long-lived) is the same model that forecloses remediation. The audit question is simple but almost nobody asks it — has the Bluetooth pairing state on these devices been audited for downgrade artifacts from prior re-pairing events? If you can't answer that question, your inventory visibility is the real vulnerability, and the CVE is just the label on a structural exposure that will persist regardless of what CVSS or EPSS do next. The productive question is no longer "should this score higher?" — it's "what does secure re-pairing even look like for silicon already in the field that cannot be updated?" For most organizations, the answer is: it doesn't exist yet, and the false comfort from the low EPSS score is preventing the audit that would reveal the true exposure.

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