> 18/08/2026 - Orange Belgium CISO follows me on LinkedIn now. Still no answer from Orange.
Hilarious!
Broadcom being a terrible and company that makes cybersecurity worse for everyone isn't unexpected, but I am a little disappointed the VINCE path led nowhere because Broadcom managed to block the CVE process.
If I were the author, I'd release the entire exploit chain the week after the one ISP that did sort-of act (Proximus) started patching their routers. Apparently this isn't a big enough security problem for Broadcom or ISPs to care about, so there shouldn't be any issue with releasing the bug, right?
> Broadcom being a terrible and company that makes cybersecurity worse for everyone...
To be fair, it looks like Broadcom released a fix for this in 2018. [0] So, the party at fault is the vendors who haven't bothered to either upgrade or fix the issue themselves.
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.
> ...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:
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.
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.
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.
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.
Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
Since they wouldn't share the contents of their notification to their customers, we don't know how clearly those customers (router makers) were notified. But having a CVE and detection signatures would get this vuln into all the usual scanning and reporting channels, which is another route the customers might (should!) be paying attention to.
Also, I don't know how laws over there work, but there might be legal requirements to patch things once they're known, where "known" is probably defined by "has a CVE issued". So by refusing to issue one, Broadcom is blocking that process.
> Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
One would imagine that both what Broadcom is obligated to do and the definition of "legitimate vulnerability" depend on the contracts between Broadcom and its customers, as well as the relevant laws and regulations, no?
> How is that blameless?
I'm going to ignore your speculation about hypothetical legal requirements that neither of us currently know anything about.
We're here talking about faults in CPEs nearly a decade after Broadcom released a fix for those problems and announced the availability of the new SDK version its usual channels. Broadcom also _claimed_ that they notified affected OEMs. [0]
You may disagree, but I'd say that if you have an in-support product with field-upgradeable software, and you don't bother to check the release notes and support status of the software components you have loaded into that product at least once every year or so, then you're definitely to blame. This goes double if you've been notified by the vendor of a vulnerable component that it's vulnerable and there's a fix available.
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?
A vulnerability affecting Broadcom’s proprietary implementation of 802.11 has present in their SDK since at least 2010. An incomplete patch was silently released in 2018, followed by Broadcom’s recommendation to move to hostapd instead, making it a definitive forever day on eCos-based platforms (BCM3380, BCM3383, BCM33834) and a potential forever day on Linux platforms (BCM3390, BCM65xx, BCM68xx) unless affected Original Equipment Manufacturers (OEMs) are willing to migrate.
to something like
A vulnerability affecting Broadcom’s proprietary implementation of 802.11 has present in their SDK since at least 2010. An incomplete patch was silently released in 2018, followed by a new version of their SDK which replaced the vulnerable components with hostapd. Broadcom recommended to move to this new SDK version, making it a definitive forever day on eCos-based platforms (BCM3380, BCM3383, BCM33834) and a potential forever day on Linux platforms (BCM3390, BCM65xx, BCM68xx) unless affected Original Equipment Manufacturers (OEMs) are willing to migrate.
It makes it clear that Broadcom supplied a fixed version that uses hostapd, rather than making it seem like vendors might have been required to do the migration to hostapd themselves.
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.
> 18/08/2026 - Orange Belgium CISO follows me on LinkedIn now. Still no answer from Orange.
Hilarious!
Broadcom being a terrible and company that makes cybersecurity worse for everyone isn't unexpected, but I am a little disappointed the VINCE path led nowhere because Broadcom managed to block the CVE process.
If I were the author, I'd release the entire exploit chain the week after the one ISP that did sort-of act (Proximus) started patching their routers. Apparently this isn't a big enough security problem for Broadcom or ISPs to care about, so there shouldn't be any issue with releasing the bug, right?
> Broadcom being a terrible and company that makes cybersecurity worse for everyone...
To be fair, it looks like Broadcom released a fix for this in 2018. [0] So, the party at fault is the vendors who haven't bothered to either upgrade or fix the issue themselves.
[0] <https://news.ycombinator.com/item?id=50145776>
Proximus took 2 years back in the bbox2 days to switch to an encrypted wifi.
It was possible at the time to get a root shell from the street, with the pppoe creds obfuscated in a config file.
Never trust ISPs with security.
See my blog post here: https://www.zoobab.com/berec-routers-consultation
Even when they are a CNA, there are procedures to get a CVE issued.
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.
Can we talk about how this particular CNA is abusing its power here ?
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.
[0] <https://quentinkaiser.be/assets/qkaiser-broadcom-wps-hexacon...>
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.
Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
Since they wouldn't share the contents of their notification to their customers, we don't know how clearly those customers (router makers) were notified. But having a CVE and detection signatures would get this vuln into all the usual scanning and reporting channels, which is another route the customers might (should!) be paying attention to.
Also, I don't know how laws over there work, but there might be legal requirements to patch things once they're known, where "known" is probably defined by "has a CVE issued". So by refusing to issue one, Broadcom is blocking that process.
How is that blameless?
> Is Broadcom not obligated to issue a CVE for a legitimate vulnerability?
One would imagine that both what Broadcom is obligated to do and the definition of "legitimate vulnerability" depend on the contracts between Broadcom and its customers, as well as the relevant laws and regulations, no?
> How is that blameless?
I'm going to ignore your speculation about hypothetical legal requirements that neither of us currently know anything about.
We're here talking about faults in CPEs nearly a decade after Broadcom released a fix for those problems and announced the availability of the new SDK version its usual channels. Broadcom also _claimed_ that they notified affected OEMs. [0]
You may disagree, but I'd say that if you have an in-support product with field-upgradeable software, and you don't bother to check the release notes and support status of the software components you have loaded into that product at least once every year or so, then you're definitely to blame. This goes double if you've been notified by the vendor of a vulnerable component that it's vulnerable and there's a fix available.
[0] <https://news.ycombinator.com/item?id=50148720>
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?
> I probably need to adapt the wording then.
Yeah. I'd recommend changing
to something like
It makes it clear that Broadcom supplied a fixed version that uses hostapd, rather than making it seem like vendors might have been required to do the migration to hostapd themselves.
NB for anyone who isn't versed in legalese: it is still an authorized access with a lot of judical consequences.
"NB for anyone who isn't versed in legalese"
IMHO there should be jail time for Broadcom CEO.
> 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.
That's interesting, the Vodafone CGA4233DE cable gateways, that I'm pretty sure are based on BCM3390, are locked down very tight.
One more reason to never trust ISP provided appliances, it seems. No one there has security or your interest in mind.
> 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