Security researcher Quentin Kaiser disclosed an unpatched memory-corruption flaw in Broadcom’s proprietary Wi-Fi Protected Setup (WPS) implementation at Hexacon in Paris on October 16. An attacker within radio range can run code as root on an affected router without the Wi-Fi password and without pairing with the device. No CVE has been assigned, and as of October 19 secondary reporting indicates no fix has reached the ISP-managed gateways Kaiser tested. No in-the-wild exploitation has been reported.

What happened

The bug sits in how Broadcom’s wireless code reassembles fragmented WPS (EAP-based) messages. Crafted fragments corrupt memory in the reassembly path. WPS exchanges occur before authentication, so the vulnerable code is reachable by any radio-adjacent client that can send frames to the access point. Kaiser traced the vulnerable code in Broadcom’s proprietary implementation back to at least 2010.

Kaiser demonstrated the issue on home gateways from Belgian ISPs:

  • Orange Belgium Askey TCG3000: extracted the Wi-Fi key from the device.
  • Proximus BBOX3V+: obtained a remote root shell over Wi-Fi.

Reporting also names VOO as exploitable, and Telenet devices may be affected but were not tested. Kaiser estimates more than 1.5 million Belgian gateways may be exposed, with a potentially much larger global population because the code is part of Broadcom’s shared Wi-Fi stack. These figures are researcher estimates and have not been independently verified.

Patch status is disputed

Accounts conflict on what Broadcom has done. One version says Broadcom told Kaiser a fix has existed since 2018 and declined to assign a CVE. Another says the 2018 fix was incomplete and customers were advised to move to a different Wi-Fi software package. Either way, gateway firmware is built and shipped by ISPs and ODMs (Askey, Sercomm, etc.), not Broadcom, so a chipset-level fix does not reach devices unless the ISP integrates and pushes it. Treat the public status as “no verified fix on shipping devices.”

Impact

Root on a gateway gives an attacker a foothold on the subscriber LAN. From there: traffic interception, DNS tampering, pivoting to internal hosts, and persistence on a device users rarely inspect. For infrastructure teams the relevant exposure is not data centers but:

  • Remote workers whose corporate VPN endpoints sit behind an ISP-supplied gateway.
  • Branch and small-office sites running ISP-managed CPE.
  • ISPs and MSPs who manage fleets of Broadcom-based gateways and own the patch pipeline.

Exploitation requires physical proximity (radio range), which limits mass remote attacks but makes targeted attacks against specific locations practical, and a compromised device could in principle be used to attack neighbors’ devices.

Mitigation

There is no vendor patch to apply. Practical steps:

  1. Disable WPS in the gateway admin UI where the firmware allows it. Many ISP builds hide or ignore this toggle, so verify rather than assume.
  2. Put your own router behind the ISP gateway, or run the ISP device in bridge mode and disable its radios, using a separately maintained access point for Wi-Fi.
  3. Disable the gateway’s Wi-Fi entirely if wired-only operation is acceptable.
  4. Do not rely on the Wi-Fi password as a control for these devices; the attack does not require it. Treat the LAN behind an affected gateway as exposed to nearby attackers and keep VPN and management traffic end-to-end authenticated.
  5. ISPs and MSPs: ask your Broadcom/ODM suppliers for firmware that replaces or fixes the WPS reassembly code, inventory affected models, and push WPS-disabled configurations in the interim.

Detection

Look for anomalous WPS or EAP fragment traffic and unexpected gateway reboots or crashes (memory corruption often crashes the Wi-Fi daemon on failed attempts). Most consumer gateways expose little logging, so ISP-side telemetry on crash and restart rates is the most realistic signal.

Caveats

The findings are from a conference talk and secondary write-ups; the exact firmware builds and device lists are unconfirmed, and Broadcom’s position is reported inconsistently. Check Kaiser’s Hexacon materials and your ISP or gateway vendor for authoritative model lists and fixed firmware.

References