homelab

A 16-year-old router bug with no CVE, because Broadcom will not issue one

A bug that has been sitting in Broadcom’s Wi-Fi Protected Setup code since at least 2010 lets anyone within radio range run code as root on your router. No Wi-Fi password. No WPS pairing. Just be close enough.

It has no CVE, because Broadcom won’t assign one.

A network switch rack with tangled cables
Photo: cell105, CC BY 2.0.

What it is

Quentin Kaiser presented it at Hexacon in Paris on October 16 under the name WPSplinter. It’s an overflow in how Broadcom’s SDK reassembles fragmented WPS EAP messages, and it’s reachable before any authentication happens, because reassembling the message is what the router does on its way to deciding whether to talk to you at all.

He demonstrated two things. Pulling the Wi-Fi password off an Orange Belgium ASKEY TCG3000, and getting a reverse shell over Wi-Fi frames on a Proximus BBOX3V+. He put the number of potentially exposed gateways in Belgium alone at over 1.5 million.

Affected chipsets span both of Broadcom’s firmware families: BCM3380, BCM3383 and BCM33834 on eCos, and BCM3390, BCM65xx and BCM68xx on Linux. That’s a very large share of the cable modems and ISP gateways shipped over the last decade.

The part that makes it a forever-day

Kaiser reported it to Broadcom in July. Broadcom replied that it had known since 2018, that it had already replaced the older implementation, and pointed him at the device manufacturers.

Kaiser’s position is that the 2018 correction was incomplete and left the underlying problem in place, which matches the fact that he was demonstrating it on current hardware eight years later. As of mid-October no affected device he tested had been updated.

And without a CVE there’s no identifier for anyone downstream to track. Your ISP can’t tell you whether your gateway is patched against a thing that officially has no number. Vulnerability management at every level below the chipmaker runs on those identifiers, so declining to issue one isn’t a paperwork decision. It’s what stops the fix propagating.

What you can actually do

Turn WPS off if your router’s interface offers it. That’s the honest first answer and it comes with a caveat: on plenty of ISP gear the toggle hides the feature without unloading the code that listens for it, and nobody outside the vendor can tell which kind you have.

The more durable answer is the one we keep arriving at. Treat the ISP gateway as hostile infrastructure you happen to be standing next to.

Put it in bridge mode and run your own router behind it, so the box you don’t control is a dumb modem and the box making decisions about your network is one you can patch. If bridge mode isn’t available, your own router behind it on a separate subnet still means a root shell on the gateway lands an attacker on a segment rather than inside everything.

That’s a weekend of work and a piece of hardware, which is a real cost. It also converts “hope Broadcom and my ISP both care” into something you can do yourself, which is the entire argument for owning your own stack.

Where we land

Consumer network gear has a maintenance model that doesn’t work. A chipmaker sells an SDK, a manufacturer builds a box on it, an ISP rebrands the box and ships it to a million homes, and the people with the problem are at the end of a chain where nobody is obliged to tell the next link anything.

Sixteen years, a working root exploit, 1.5 million devices in one small country, and no number to file it under. The technical flaw is an overflow in message reassembly. The reason it’s still here in 2026 is organisational.

Sources: The Hacker News on the WPSplinter disclosure, Techzine on the scale in Belgium, Hackaday’s roundup.

Leave a comment

Your email address will not be published. Required fields are marked *