A 16-Year-Old Broadcom Wi-Fi Bug Lets Attackers Root ISP Gateways From Across the Street

A memory corruption bug in Broadcom's own Wi-Fi software lets an attacker within radio range take full control of affected home gateways without knowing the Wi-Fi password, security researcher Quentin Kaiser disclosed on October 16, 2026. He presented the work at Hexacon in Paris the same day and published a long-form write-up and slides.

The flaw sits in how Broadcom's proprietary 802.11 stack reassembles fragmented WPS (Wi-Fi Protected Setup) EAP messages. Kaiser traces the vulnerable code in Broadcom's SDK back to at least 2010. According to his write-up, it can be triggered over the air without the network key and without completing a normal WPS enrollment, and exploitation gives both controlled information disclosure and arbitrary code execution.

No CVE, and a fix that never reached many devices

There is no CVE for this bug, and there is no public Broadcom advisory. Kaiser reported it to Broadcom's PSIRT in July 2026. Broadcom replied that it has known about the issue for a long time, that other researchers had reported it too, and that the old WPS Monitor based code was replaced starting in 2018 by an implementation built on hostapd and wpa_supplicant. Kaiser describes the 2018 change as an incomplete patch released silently. Broadcom declined to register a CVE or share the notice it sent to device makers, and CERT/CC closed his case the same day it was opened because Broadcom is its own CVE Numbering Authority.

His slides show the affected chips span cable (DOCSIS) and DSL gateway families:

On the Linux platforms, the fix is for the device maker to move to the hostapd-based Wi-Fi stack. Because there is no fix for the eCos platforms, owners of those gateways depend on the ISP or manufacturer replacing the hardware or the software stack.

Belgian ISP gateways shown vulnerable

Kaiser says he confirmed the bug is present and exploitable on gateways from three of Belgium's four major ISPs: Proximus, VOO and Orange Belgium. Telenet may be affected through Sagemcom F@st devices, but he could not test one. As of October 15, 2026, none of the affected devices had been patched, he writes. His demo videos show unauthenticated code execution on an Orange Belgium Askey TCG3000, where the payload reads the Wi-Fi key from memory and sends it back over the air, and a reverse shell over 802.11 frames on a Proximus BBOX 3V+. He says the attack works over long distances, not only when the antennas are close.

Using public subscriber figures, Kaiser estimates at least 1.5 million affected gateways in Belgium alone, with what he calls medium confidence:

The problem is not limited to Belgium. The affected-device list in Kaiser's toolkit repository names products from ARRIS, Arcadyan, Askey, CastleNET, Cisco, Comtrend, Huawei, MitraStar, Netgear, Nokia, Sagemcom, TP-Link, Zyxel and ZTE, among others, deployed by ISPs including KPN, Movistar, SFR and Türk Telekom. In a passive scan in Paris, his slides list some Orange and Bouygues boxes on newer chips as patched, while an Orange Sagemcom Fast5656 and SFR NB6VAC units were not. No vendor or ISP advisory for the bug could be found at the time of writing.

Kaiser has not released exploit code. What he did publish is a detection toolkit: a fingerprinting script for live access points and YARA rules for firmware images. He also warns that bugs like this suit attackers who use nearby Wi-Fi networks to get in, pointing to Volexity's "Nearest Neighbor Attack" report and Microsoft's report on Midnight Blizzard targeting travelers through hotel networks.

Are you affected?

1. Identify your gateway. Check the label on the box or the admin page for the brand and model, then compare it with the affected-device table in the broadcom-wps repository and the ISP table above. A match, especially an ISP-supplied cable or DSL gateway, means the device is likely exposed.

2. Fingerprint your own access point. Kaiser's script needs a Wi-Fi adapter that supports monitor mode. Only run it against networks you own or are authorized to test. Put the adapter in monitor mode (replace wlan0 with your interface):

sudo ip link set dev wlan0 down
sudo iw dev wlan0 set monitor none
sudo ip link set dev wlan0 up

Then run the script against your SSID:

sudo uv run --with scapy \
  broadcom_fingerprint.py \
  --interface wlan0 \
  --ssid YOUR-SSID

An Assessment: LIKELY_VULNERABLE result means the access point appears to run the vulnerable Broadcom WPS code.

3. Scan firmware (for researchers and vendors). On an extracted firmware tree, run:

yara -w -r broadcom_wps_monitor.yar \
  extracted_firmware_dir

A hit on VULN_BRCM_WPS_EAP_Fragment_Reassembly_ELF points to the vulnerable reassembly path. The README calls these rules triage aids: a patched binary can still match, so confirm by manual review.

4. Check the firmware and ask the ISP. Note the firmware version on the gateway's admin page and ask the ISP or manufacturer whether it has been fixed or moved to the hostapd-based Wi-Fi stack. As of October 15, no fix had reached the Belgian devices Kaiser tested, and eCos-based gateways may never get one, so ask about a replacement.

5. Reduce exposure until there is a fix. Kaiser does not document a workaround, and he does not say whether switching off WPS in the settings blocks the bug, so that should not be treated as a fix. Since the attack arrives over the gateway's own Wi-Fi, turning off the gateway's built-in Wi-Fi and using a separate, unaffected access point removes that path, if the ISP allows it.

6. Report what you find. Kaiser asks for affected devices to be reported through a pull request on the repository, with vendor, product, firmware version and ISP.

Sources: Quentin Kaiser's write-up, Hexacon 2026 slides, qkaiser/broadcom-wps toolkit, Hexacon talk page.