News › security
By The Linux Camp News, October 19, 2026
Quentin Kaiser reports an over-the-air WPS flaw affecting eCos- and Linux-based routers. His tested Belgian devices remained unpatched on October 15, but identifying affected firmware requires more than checking the chipset.
On October 16, 2026, Quentin Kaiser presented research at Hexacon and published an accompanying disclosure about Broadcom’s proprietary Wi-Fi implementation. The router-focused release includes firmware detection rules and a live access-point fingerprinting tool, giving operators a way to investigate exposure rather than relying solely on a product’s Broadcom branding. 1 3
The reported defect is an overflow during WPS EAP fragment reassembly, the process of joining pieces of a wireless enrollment message. The supplied historical code describes recording an expected total length, copying successive fragments into a buffer and increasing the received-byte count. That accumulation makes length validation central to keeping writes within the buffer. Kaiser identifies affected implementations on both eCos and Linux platforms, but the supplied code extract does not expose enough of the fragment-processing function to establish the exact defective check or overwrite. 1 2 3
Kaiser says an attacker within Wi-Fi reach needs neither the network key nor completed WPS enrollment. Consequently, the network password is not a prerequisite barrier to this reported attack. His ASKEY TCG3000 demonstration executes code that retrieves the pre-shared key from NVRAM, the router’s persistent storage, and returns it over Wi-Fi. This is a researcher demonstration of code execution and credential disclosure, not evidence that every listed router has identical exploit reliability or privileges. 1 3
In the disclosure retrieved October 19, Kaiser reports exploitable devices deployed by Proximus, VOO and Orange Belgium, including the BBOX 3V+, several Netgear and Technicolor models, and ASKEY TCG3000. His patch-status observation is dated October 15: none of those affected devices had been patched. He also reports root-shell access, but explicitly leaves Telenet exposure unconfirmed. Those statements describe his tested scope, not all Broadcom-based equipment. 1
“Unpatched” does not establish that no remediation exists anywhere. Kaiser’s timeline says Broadcom told him on July 28 that a patch was available and that affected manufacturers should contact Broadcom. That is the researcher’s account of a vendor response, not a direct vendor advisory or a verified fixed-firmware list. The supplied material retrieved October 19 does not establish which shipping firmware incorporates that patch. 1
For firmware review, Kaiser’s YARA rules offer pattern-based screening of extracted binaries. Treat a match as a reason to investigate, not a patch verdict: the toolkit warns that patched binaries can retain matching bytes, while compiler changes can hide vulnerable code from a detector. Confirm findings against integrated source or manual examination of fragment-length validation and the copy operation, then seek model-specific remediation from the manufacturer or ISP. 3 1
The implementation matters more than chipset identification. The toolkit explains that Broadcom-specific wireless information elements can come from a Linux kernel module even when userspace does not use Broadcom’s SDK. Its live fingerprinting therefore also distinguishes Broadcom’s wps_monitor from hostapd by their protocol responses. This makes a chipset-only inventory insufficient to establish exposure; the firmware component handling enrollment needs examination. 3
The October 19 source packet supplies no CVE identifier, CVSS score or evidence of exploitation outside the research demonstrations. Kaiser says Broadcom declined to register a CVE, but no direct vendor statement is included. Operators should therefore keep the demonstrated attack capability separate from a vendor severity assessment or a claim of exploitation in the wild. 1