Security researcher Quentin Kaiser presented new research on Broadcom’s WiFi WPS implementation at Hexacon in Paris on October 16, and the story behind the bug is almost as interesting as the bug itself. The short version: a memory corruption flaw in Broadcom’s proprietary 802.11 stack, present since at least 2010, exploitable over the air with no authentication and no network key, affecting ISP gateways from multiple vendors. Broadcom declined to assign a CVE.
What the bug is
The flaw sits in the WPS (Wi-Fi Protected Setup) message handling code, specifically the reassembly of fragmented EAP messages. A parser bug, appearing in two forms across Broadcom’s SDK. An attacker who can reach the device over WiFi can trigger it without knowing the network password and without completing WPS enrollment, which defeats the usual “WPS is only reachable from inside the network” assumption.
The primitives Kaiser chained together are ugly: a controlled field gives arbitrary write, sequence state gives arbitrary read, and overwriting a function pointer in connection state yields code execution. On ARM targets the exploit lands on a fixed system@PLT address, sidestepping ASLR. On MIPS it leaks a libc base from a printf GOT entry. The demonstration exfiltrates command output and the WiFi pre-shared key back over 802.11 frames, so the whole attack runs over the air with no cloud callback.
Demonstrated on real ISP gateways
This is where it stops being academic. Kaiser demonstrated unauthenticated code execution over WiFi on gateways from three of Belgium’s four major ISPs: Proximus BBOX 3V+ units from Sagemcom, VOO’s Netgear and Technicolor hardware, and Orange Belgium’s ASKEY devices. As of October 15, none of the tested devices had been patched. Kaiser’s own estimate, which he labels medium confidence, puts roughly 850,000 Proximus, 500,000 VOO, and 210,000 Orange Belgium gateways in scope.
The affected-device list in his toolkit names products from ARRIS, Arcadyan, Askey, Cisco, Comtrend, Huawei, Netgear, Nokia, Sagemcom, TP-Link, Zyxel, and ZTE, deployed by ISPs across Europe and beyond. If your ISP handed you a router with Broadcom silicon inside, it is worth checking whether it is on the list.
A forever day by design
Here is the part that should annoy you. Broadcom’s SDK has shipped this code since at least 2010. A partial fix came out in 2018, along with a recommendation that vendors migrate to the open source hostapd WPS implementation instead. The eCos-based chipsets (BCM3380, BCM3383, BCM33834) have no fix path at all short of migrating the stack or replacing hardware. The Linux-based families (BCM3390, BCM65xx, BCM68xx) are patchable in theory, but somebody has to build and ship that firmware.
Nobody has. Kaiser reported the bugs to Broadcom PSIRT in July, worked through a 90-day disclosure window, and the window expired the day he presented. Per his writeup, Broadcom declined to publish an advisory or assign a CVE, and CERT/CC closed the VINCE case in August because Broadcom is itself a CVE Numbering Authority. That last detail matters more than it sounds: when the affected vendor is also the CNA and declines to act, the vulnerability disappears from every tracking system defenders rely on. No CVE means no entry in KEV, no scanner signatures, no vendor bulletins. Kaiser released a fingerprinting script and YARA rules in his broadcom-wps repository to fill the gap, and he is collecting affected-device reports via pull request.
The disclosure timeline, in full
Kaiser’s writeup lays out the sequence. First report to Broadcom PSIRT went out on July 18, with a follow-up on July 27. A standard 90-day disclosure window ran from there and expired on October 16, the day of the Hexacon talk. Along the way, Kaiser involved CERT/CC through its VINCE coordination platform, which closed the case on August 4, reasoning that Broadcom coordinates its own vulnerabilities as a CNA. In other words, the system worked exactly as designed, and the design produced no advisory, no CVE, and no public fix for the hardware that cannot be patched.
That is the crux of the problem. CVE assignment is voluntary for CNAs, and Broadcom exercised that discretion. Everything downstream, the Known Exploited Vulnerabilities catalog, enterprise scanner coverage, vendor advisories from the OEMs who shipped the affected firmware, depends on that one identifier existing. When it does not, detection falls back on bespoke tooling like Kaiser’s fingerprinting script. For a bug reachable wirelessly from a neighboring apartment, “invisible to standard tooling” is not a comfortable place to be.
The AI footnote that isn’t a footnote
Kaiser credits frontier AI models with compressing the research timeline. Work he estimates would have taken months of solo reverse engineering wrapped up in under a week. That is one researcher’s account of one project, not a benchmark, but the direction is hard to argue with. Deep firmware vulnerability research is getting cheaper. The same 16-year-old SDK code that sat unexamined because nobody had the months to spare is now a week’s project, and that cuts both ways: defenders get fingerprinting tools faster, and so does everyone else.
What you can actually do
If you manage ISP-supplied gateways, the honest answer is limited. Disabling WPS is worth doing where the device allows it, though Kaiser’s post does not confirm that it blocks the attack. Ask your ISP whether gateway firmware includes Broadcom’s fix or the hostapd-based stack. For eCos-based hardware with no fix path, replacement is the only real answer. And if you are on the defensive side, the fingerprinting script and YARA rules in the repository are the fastest way to find affected devices in your estate.
The systemic lesson is older than the bug: a silicon vendor patch that no OEM ships is not a patch, and a CVE that the vendor declines to issue is invisible to everyone who would act on it.