> ...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.
I'm probably not seeing something obvious, but if this is just a case of downstreams not replacing upstream-EOL'ed parts, why is it wrong for Broadcom to refuse a CVE and full patch? It's like when FOSS upstreams tell tell me to go back to my distro because they won't support my old version?
It seems a certain YouTuber (Low Level) is being bad. Said they'd put qkaiser's writeup and videos below, but didn't AND deleted my comments pointing it out:
Thanks for linking to quentinkaiser's One Parse, Two Bugs and Broadcom-WPS WPSplinter page. /s
Clearly promised at 1:13! in the video (titled "Do You See the Problem Here?")
Does link to "The Hacker News", which seem like some fake name rip-off of Hacker News, which does have an article that links to qkaiser's article.
27 comments
[ 0.56 ms ] story [ 22.0 ms ] thread...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...
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...>
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.
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?
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>
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.
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.IMHO there should be jail time for Broadcom CEO.
I remember hearing about people doing that for log4j when the log4j/log4shell exploit was going around
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.
Only systemd thinks this is not the case.
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.
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?
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>
Thanks for linking to quentinkaiser's One Parse, Two Bugs and Broadcom-WPS WPSplinter page. /s
Clearly promised at 1:13! in the video (titled "Do You See the Problem Here?") Does link to "The Hacker News", which seem like some fake name rip-off of Hacker News, which does have an article that links to qkaiser's article.