One parser, two bugs, many routers: Exploiting Broadcom WiFi across eCos, Linux
quentinkaiser.beCan we talk about how this particular CNA is abusing its power here ?
The article estimates the number of these routers in the author's home country (Belgium), but the vulnerability would exist in units sold worldwide, no? Seems to me that their estimates of affected units are a couple orders of magnitude low.
> The article estimates the number of these routers in the author's home country (Belgium), but the vulnerability would exist in units sold worldwide, no?
It seems like the author is aware of the undercount, no?
FTFA:
> [This issue] affects dozens of vendors, hundreds of products, and millions of Broadcom-based access points worldwide. In an effort to discover all affected vendors and devices, I’m providing a fingerprinting script and YARA rule so you can help me document the blast radius.
> ...
> I demonstrated that the vulnerability is present and exploitable on 3 out of 4 Belgian Internet Service Providers including Proximus (BBOX 3V+), VOO (Netgear CG3100, Netgear CG3700, Technicolor 7210, CGA4233) and Orange (ASKEY TCG3000). Telenet may be affected through Sagemcom F@st devices, but I could not get my hands on one.
> As of October 15th, 2026, none of these affected devices have been patched. This means you can get a root shell from across the street on a significant proportion of routers in Belgium, and probably elsewhere.
> ...
> I did some napkin math with my friend Sol using data published by the IBPT and public communication from the ISPs about model release over the years. I have medium confidence in these numbers; hopefully the ISPs will start communicating about the exact number of affected devices once this hits the Internet. [A table that contains guestimates of number of affected subscribers from the four Belgian ISPs mentioned above follows.]
> ...
> And this is *not* limited to Belgium. Affected manufacturers serve a larger market.
yes. In my talk there’s a slide where I guesstimated a worldwide impact in the low hundred millions.
We will only ever know once the ISPs come forward with exact numbers.
unless affected Original Equipment Manufacturers (OEMs) are willing to migrate.
...or someone spends a bit of time with an AI to come up with a patch? Bonus points for one that can be remotely installed using the same exploit...
> ...or someone spends a bit of time with an AI to come up with a patch?
Based on the guy's slides [0], it seems like Broadcom has already released a fixed version. The slide numbered as 97 contains this part of what I assume is an email with Broadcom:
The blog post makes it sound like there was no updated version, but the guy's email with Broadcom says otherwise. If we knew the name of the SDK, we could check the release notes and maybe get the truth. I gave up after like a minute of searching for the name, but perhaps others are more interested in the search than I am.Thank you for your above-cited report. This report is based on Broadcom’s 18.1 SDK release. Broadcom has known about this specific vulnerability for a long time; other external entities have also reported it to us. For several years, Broadcom has been offering its customers updated software that lacks this vulnerability. In particular, the WPS implementation in this old software package (based on WPS Monitor) was obsoleted several years ago and replaced starting in 2018 by a new implementation based on HostAPD and WPA Supplicant.[0] <https://quentinkaiser.be/assets/qkaiser-broadcom-wps-hexacon...>
I probably need to adapt the wording then.
Broadcom released an insufficient patch in 2018, then they moved to hostapd in their SDK. So as an OEM you can get the support of Broadcom to move to a fixed revision.
The whole issue is not that Broadcom has a bug, everyone has, it’s that their communication did not make its way down the supply chain.
They said they notified OEMs but refused to share the content with me. So we don’t know whether it was a single line in a changelog or an actual security advisory.
Since every OEM is not keeping track of all vendor communications, a proper CVE would have alerted the OEMs to take action 8 years ago I think.
could you also mention which driver this is somewhere? I deduct it is the proprietary broadcom-driver, so only used in routers? Also what happens if you turn WPS off?
Broadcom just makes the chip right? So customers in this sense would be the router OEMs like netgear who may not have distributed the new update to end devices.
> Broadcom just makes the chip right?
And -based on the email- the SDK used by folks who use that chip in hardware, yes.
So, yeah. The customers are the folks who build the hardware that uses that chip and the relevant parts of Broadcom's SDK as part of the software loaded into that hardware. Though it could totally be the ISP's fault for not testing and deploying updated firmware for affected CPE. There's not enough information to know exactly who is at fault, but it doesn't look like it's Broadcom.
> Bonus points for one that can be remotely installed using the same exploit...
I remember hearing about people doing that for log4j when the log4j/log4shell exploit was going around
that’s a possibility because firmware signing and authentication is not implemented by these devices. On Linux devices the patch would be to simply get rid of wps_monitor, which is only in charge of WPS/WSC anyway.
On eCos you could do it through binary patching so the WPSM real-time task is not launched. I’ve heard of ISP doing that when Cable Haunt was released. Not sure all of them would be okay with this given the risks of pushing a really bad update.
NB for anyone who isn't versed in legalese: it is still an authorized access with a lot of judical consequences.
> Key Takeaways: Security through Complexity is Dead.
Only systemd thinks this is not the case.
An interesting situation, to be sure, that came about because of this bug