WPSplinter: The Broadcom WPS Router Flaw With No CVE, Explained

WPSplinter is a memory corruption bug in Broadcom's legacy WPS code that ships inside many ISP gateways and routers. Someone within Wi-Fi range can reach it without the network password. No CVE exists and no attacks are reported. Find your gateway model, check the researcher's list, turn off WPS, and ask your ISP for firmware.

The bug was disclosed by security researcher Quentin Kaiser, an individual researcher rather than a security vendor, in a talk at Hexacon in Paris on 16 October 2026 and a long write-up published the same morning. A second post on 23 October argued that the fix Broadcom says it shipped in 2018 is itself incomplete. Kaiser named the issue WPSplinter on his documentation site because there is no CVE identifier to call it by. Broadcom, which is the CVE Numbering Authority for its own products, declined to request one.

That missing identifier is the real story for defenders. Scanners, SBOM tools, vulnerability feeds, VEX documents and ISP patch trackers all key on CVE IDs. A bug without one is invisible to most of that machinery, even when a researcher has shown code execution as root on gateways that sit in hundreds of thousands of homes. This post explains what was found, which chips and devices the researcher lists, how to tell whether your own gateway or your staff's home gateways are affected, what to ask your ISP, and what the episode says about firmware supply chains.

What happened

Kaiser reports that the flaw sits in WPS Monitor, the proprietary Wi-Fi Protected Setup implementation in Broadcom's 802.11 software development kit (SDK), and that the vulnerable code has been in that SDK since at least 2010. WPS is the "push the button on the router" pairing feature. To support it, the router runs a parser that listens for WPS setup messages from any nearby device, before that device knows the Wi-Fi password.

According to his 16 October post, that parser reassembles fragmented WPS messages without limiting the total to the size of the buffer it copies them into. A nearby attacker who sends crafted fragments can therefore write past the end of that buffer and read memory back. Kaiser demonstrated two outcomes on real ISP equipment in Belgium:

• On an Orange Belgium gateway, an ASKEY TCG3000, his proof of concept read the Wi-Fi pre-shared key (PSK) out of the device and joined the network with it.
• On a Proximus BBOX 3V+ built by Sagemcom, he obtained a reverse shell carried entirely over Wi-Fi frames, with no internet connection needed on the attacker's side.

He also reports confirming the bug on VOO gateways (Netgear CG3100 and CG3700, Technicolor TC7210 and a CGA4233). His slides add that the bug surfaced during AI assisted vulnerability research on eCos firmware, at a listed cost of 103 euros.

Broadcom's position, as relayed by Kaiser's documentation site, is that the affected software is obsolete and outside its support window, that it fixed the issue in 2018, and that it replaced WPS Monitor with hostapd, the widely used open source access point daemon, from 2018 onwards. Broadcom told Kaiser that a patch was available and that he should contact device manufacturers. It declined to register a CVE and declined to share the notification it says it sent to manufacturers.

Timeline

Kaiser's 90 day disclosure window ran from 18 July to the talk on 16 October.

Why there is no CVE

The CVE system lets many organizations assign identifiers. Large vendors, including Broadcom, are CVE Numbering Authorities (CNAs) for their own products. When a researcher reports a bug in a CNA's product, the normal route is for that CNA to assign the ID.

Here, Kaiser reports that Broadcom refused. His documentation site gives Broadcom's reason as the software being obsolete and outside its support window. When he took the case to CERT/CC, which coordinates disclosures that stall, the case was opened and closed on 4 August because Broadcom, as the CNA, was unwilling to register a CVE.

Broadcom's account deserves to be stated fairly. In its view the bug was fixed seven or eight years ago, the vulnerable component was replaced by hostapd in later SDKs, and the devices still running it are old products whose manufacturers were told to move on. Kaiser's 23 October post says he has heard, but cannot independently verify, that Broadcom is assuring customers that its patch is sufficient. We found no public statement from Broadcom about WPSplinter itself, and the press reports we read did not include one either.

The consequence is practical, not moral. Without a CVE, scanners and firmware analysis tools have no record to match, SBOM and VEX workflows have no identifier to mark affected or not affected, CERTs, ISPs and enterprise patch programs have nothing to track, and manufacturers who received a private notice in 2018, if they did, faced no public pressure to act.

Kaiser's slides summarize the downstream patch path in three cases: the manufacturer moves to hostapd and you are fine; the manufacturer ignores the notice and you are not; or the manufacturer marks the device end of life and nothing will ever change. That third case is what "forever day" means here.

Who is affected

Kaiser splits affected Broadcom system on chip (SoC) families into two groups. Both lists come from his write-up and documentation site; a chipset match alone does not prove that a given firmware is vulnerable.

The slides spell one eCos family as BCM3384 while the post and documentation site use BCM33834. We use the written documentation's spelling.

Belgian ISP estimates

Kaiser estimated the Belgian exposure from public subscriber data published by the telecom regulator BIPT and from ISP model announcements. He labels these as medium confidence estimates, not counts.

The three estimated figures add up to roughly 1.56 million gateways. The slide asks "at least 1.5 million affected devices?" with a question mark, which is the right level of certainty to carry forward.

Outside Belgium

Kaiser's slides include a passive Wi-Fi survey in Paris. It marked several Broadcom based ISP devices as patched (a Bouygues Telecom Bbox, Sagemcom F5696b; Orange Livebox models Fast5698_OFR and Fast5670_OFR; a Sercomm Wi-Fi 6 repeater) and two as not patched (an Orange Livebox 5, Sagemcom Fast5656_OFR, and SFR NB6VAC r0 and r1). French press, for example Univers Freebox on 18 October, reported these as "could be affected", noting that not every unit is necessarily vulnerable. We found no statement from the French operators.

His community list on GitHub covers dozens of vendors and hundreds of product rows, from ARRIS, ASUS, D-Link, Huawei, Netgear, Nokia, Sagemcom, Technicolor, TP-Link, ZTE and Zyxel to smaller ISP equipment makers. The list says plainly that it is not exhaustive. Some rows are confirmed, some say LIKELY, some carry a question mark or are still to be determined, and many list "ALL" versions. A separate table lists devices assessed as patched, for example the Sagemcom F5598T and the Sky Q Hub ER110. Treat the list as a place to start an inquiry, not as a verdict on your device.

On worldwide scale, the slides offer a "guesstimate" in the low hundreds of millions if every ISP behaved like the Belgian ones. That is a speculative upper bound from the researcher himself, and we do not repeat it as a fact.

How it works, in plain language

A Broadcom based gateway splits Wi-Fi work across several pieces of software. The slides show the wl driver (a kernel module on Linux) handling the radio, an eapd process that multiplexes EAP and EAPOL authentication packets, nas for WPA key handling, and wps_monitor for WPS. On eCos devices the same roles exist inside a single firmware image.

WPS pairing runs an eight message exchange called M1 to M8 over EAP, the same framework used for enterprise Wi-Fi logins. The messages can be large, so the protocol allows them to be split into fragments. The receiver collects fragments, tracks how many bytes it has so far, and copies each new fragment onto the end of a buffer.

The bug, as Kaiser describes it, is that the reassembly code trusts the sizes in the fragments and does not cap the running total at the size of the destination buffer. Because the device accepts these messages from anyone in range, before WPS enrollment completes, no password or button press is needed. Overrunning that buffer lets an attacker change nearby fields in the state the parser keeps, which Kaiser turned into memory disclosure and code execution as root.

Two details matter for defenders. A strong Wi-Fi password does not help, because the attack happens before any key is used; on the Orange device it recovered the key itself. And turning WPS off in the web interface may not remove the exposure: the WPSplinter documentation warns that a settings toggle may not disable the vulnerable parser. That is why the fix everyone points to is firmware that moves to hostapd.

Technical details

This section collects the defender useful specifics published by the researcher. There is no CVE, no CVSS score, no vendor advisory and no list of fixed firmware versions from Broadcom, so the values below come from Kaiser's posts, slides and toolkit, and from the CVE record for a related glibc issue. Every item is attributed.

Component and code locations

Build characteristics on Linux devices

The slides summarize what Kaiser observed across the Linux firmware he examined. All observed binaries were built with non executable memory (NX) but were not position independent (non PIE), and were compiled for either 32 bit little endian ARM or 32 bit big endian MIPS. The C library was position independent in every case. For defenders, this means the usual memory protections on these devices are partial, and that a single bug class can be reachable across very different hardware.

The slides also note that the wl command line tool on these devices can send arbitrary 802.11 frames, which is how the reverse shell on the Proximus device avoided needing any network path. Kaiser comments on the slides that this makes the bug potentially wormable between devices in radio range. That is his assessment on a slide, not something he reports having observed.

The 2018 fix and why Kaiser calls it incomplete

Broadcom never published changelogs, SDK versions or release dates for this code, Kaiser says. To find the 2018 change, he took leaked Broadcom source covering 2010 to 2018, imported the files into a git repository in timestamp order, and used a language model to split 224 import boundaries into 640 synthetic commits. He is explicit that those commits and their messages are inferred, not historical. The best candidate for the fix is a synthetic commit dated 24 January 2018.

According to his reconstruction, that change does three things in the access point EAP code:

1. It initializes the count of received data to zero and only computes it when data has already been received.
2. It rejects a first fragment whose length is below a minimum.
3. It checks the declared total length against the maximum, minus the header size, and stores the validated value.

His argument is that the minimum length check applies only to the first fragment. A malformed follow-on fragment can still reach memcpy with a size that wraps around, a problem he attributes to signed and unsigned handling of lengths. On most C libraries, a wrapped size passed to memcpy ends in a crash of the WPS process, which is a denial of service but not code execution. On some C library builds, it can be worse.

When the residual path may be exploitable

Kaiser lists the conditions below for 32 bit ARM. He presents them as analysis that must be confirmed per firmware build, and says the issue "can apply to BCM68xx and BCM65xx firmware".

The original 2020 report on CVE-2020-6096 describes the glibc issue as specific to ARMv7 and notes that x86 is not affected by this behavior. Kaiser's own conclusion is short: "So better move to hostapd." He also advises against spending time proving whether the residual path is exploitable in a specific build.

Detection aids published by the researcher

Kaiser's broadcom-wps repository on GitHub is MIT licensed and contains two triage tools and the device list.

Use the fingerprinting script only against equipment you own or are explicitly authorized to test. It sends frames to the target, which is a test, not a passive scan.

Is anyone exploiting it?

No exploitation in the wild is reported. Kaiser wrote that he had not observed attacks, and the working exploits described in the coverage are his own research demonstrations. We found no government advisory that reports attacks, and there is no KEV entry because there is no CVE.

One security vendor's blog headline mentioned "active exploitation"; no primary source we read supports that. Keep in mind that an over the air attack near the target leaves no trace in internet facing logs, so absence of reports is not proof of absence.

What to do now

The right steps depend on who you are. Home users mostly need to identify their gateway and talk to their ISP. Enterprises need to think about branch offices and home workers. Firmware and product teams need to check their own builds.

For anyone with an ISP gateway or Broadcom based router

1. Identify the exact model and firmware. The label on the device usually gives the model. The gateway's admin page, usually reached at the default gateway address shown by your computer, shows the firmware version. On Windows, ipconfig shows the "Default Gateway". On macOS, run route -n get default. On Linux, run ip route show default.

2. Check the researcher's list. Search the affected devices table in the qkaiser/broadcom-wps repository for your vendor and model. Note the Confirmed column (Y, LIKELY or unknown), the versions listed, and whether your ISP is named. Also check the patched table. A match is a reason to ask your ISP, not proof.

3. See whether your network advertises WPS. On a Linux laptop, this passive check reads the WPS element from beacons and probe responses:

   sudo iw dev wlan0 scan | grep -E "SSID:|WPS:|Manufacturer|Model|Device name|Setup State"
   

   With wpa_supplicant running, wpa_cli scan_results shows a [WPS] flag next to networks that advertise it. The manufacturer and model strings in the WPS element often name the real hardware behind an ISP branded box.

4. Turn WPS off in the gateway settings. It is usually under the Wi-Fi or wireless section, sometimes called "WPS", "Wi-Fi Protected Setup" or "pairing button". Then repeat step 3 and confirm the WPS element is gone. The WPSplinter documentation warns that this may not remove the vulnerable parser, so think of it as reducing exposure, not fixing the bug. If you never use the WPS button, you lose nothing.

5. Ask your ISP the questions in the next section. Only the ISP or the manufacturer can ship firmware that removes WPS Monitor.

6. After a firmware fix or device swap, change the Wi-Fi password. On affected devices the PSK should be treated as readable by anyone in range. Changing it before the fix does little, because the new key would be just as readable. Changing it after the fix closes the door on anyone who already has it.

7. If your device is an eCos cable gateway on the list, plan for replacement. Kaiser's assessment is that these have no practical migration path. Ask your ISP for a newer model. If your ISP supports it, a modem only or bridge mode with your own router behind it can move Wi-Fi off the gateway, but confirm with the ISP that bridge mode turns off the gateway's own Wi-Fi radio.

If you have shell access to a device you own or manage

Some business gateways and many hobbyist routers give you a shell. Telenet's check, as reported in Kaiser's 20 October update, was to look for the WPS Monitor process across its fleet.

ps | grep -i wps_monitor
ls /bin /usr/sbin /sbin 2>/dev/null | grep -iE "wps_monitor|hostapd|eapd|nas"

A running wps_monitor means the legacy stack is present. A hostapd process instead points to the newer stack. If you see both or neither, record the firmware version and ask the vendor.

For enterprise security teams

Gateways at branch offices, retail sites and home workers' houses are third party infrastructure that touches your traffic. For WPSplinter:

1. Inventory ISP supplied gateways. For branches, the ISP contract usually names the device. For home workers, a short voluntary survey of model and ISP is enough to start.
2. Treat home and branch Wi-Fi as untrusted. Assume anyone near an affected gateway can join the network and run code on the gateway. Require your VPN or zero trust client for corporate traffic and keep endpoint firewalls on.
3. Segment branch networks. Keep corporate devices behind your own firewall, with the ISP gateway outside it.
4. Add the question to vendor reviews. Ask ISPs and equipment suppliers whether any supplied device runs Broadcom's legacy WPS Monitor and what their plan is.

For firmware, device and product teams

If you build products on Broadcom SoCs or ship gateways under your own brand:

1. Run the YARA rules against every firmware image you ship or support. Extract the root filesystem with your usual tooling, for example binwalk -e firmware.bin, then run yara -r broadcom_wps_monitor.yar <extracted_dir>. Confirm any match by checking which WPS implementation the build actually uses.
2. Record the C library and version. On Linux images, check the files under lib/ and the version string, for example strings lib/libc.so.6 | grep "GNU C Library". For uClibc, check the library file names and the build configuration for UCLIBC_HAS_STRING_ARCH_OPT. Kaiser's analysis says these settings change how dangerous the residual 2018 code path is.
3. Move Linux based products to the hostapd based SDK. That is the fix Broadcom itself points to.
4. Publish an advisory with model and firmware numbers, even without a CVE, including the plan for eCos products that cannot be migrated.

What to ask your ISP or device vendor

Short, specific questions get better answers from support channels. Copy these:

1. Does my gateway model and firmware version run Broadcom's legacy WPS Monitor (wps_monitor) or hostapd?
2. Is my model on the WPSplinter list published by Quentin Kaiser, and do you agree with that assessment?
3. Have you disabled WPS remotely, and if so, does that stop the wps_monitor process or only remove the WPS advertisement?
4. Which firmware version removes WPS Monitor, and when will it reach my device?
5. If my model is eCos based and cannot be fixed, when will you replace it, and at whose cost?
6. Can I use bridge or modem only mode with my own router, and does that turn off the gateway's Wi-Fi radio?
7. Will you publish a security notice with model and firmware numbers?

What changed since first reports

The story moved quickly in its first week:

• 20 October: Kaiser's update reported that Proximus disabled WPS across its BBox fleet and planned full patching in the coming weeks, that Orange Belgium was investigating and considering disabling WPS, and that Telenet checked its fleet for wps_monitor, found none, and says it is not affected.
• Press numbers: some early coverage gave narrower vendor and product counts. Use the researcher's current list, which keeps growing.
• 23 October: the patch reconstruction post added the argument that Broadcom's 2018 fix is incomplete. That changes the advice for Linux devices that received the 2018 change but kept WPS Monitor: per Kaiser, even those may need the move to hostapd.
• CVE status: unchanged. As of 25 October we found no CVE for this issue.

Open questions

• Which firmware versions are fixed? No ISP or manufacturer has published model and firmware numbers that we could find.
• Did Broadcom's 2018 notice reach every manufacturer? Broadcom declined to share it, so nobody outside can check.
• Is the 2018 fix sufficient? Kaiser argues it is not, based on reconstructed leaked source. Broadcom has not responded publicly. The question will stay open until Broadcom or a manufacturer publishes analysis.
• Does disabling WPS stop the parser on each model? Each ISP will need to answer for its own devices.
• Will a CVE ever be assigned? We could not find any indication that one is coming.

What would have helped

Practices any team can use

• Ask suppliers for an SBOM of the firmware they ship. A firmware SBOM that lists the WPS implementation, the SDK release and the C library version would have let ISPs answer "are we affected?" in an afternoon. The IoT firmware SBOM requirements post covers what to ask for.
• Track third party devices as assets. Gateways, access points and modems supplied by ISPs belong in your asset inventory with model, firmware and owner, like any other vendor supplied system.
• Do not let "no CVE" mean "no work". Researcher disclosures, national CERT notes and vendor bulletins without IDs need a place in your intake. Give them a local tracking ID so they do not fall out of the process.
• Put support windows in contracts. Broadcom's position rests on the code being outside its support window. Contracts with ISPs and device suppliers should say how long security fixes will ship and what happens after.
• Turn off what you do not use, and segment. WPS off by default on managed devices is cheap, and corporate traffic should never depend on a consumer gateway.
• Understand CNA status. The CNA status post explains how a vendor's role as its own CNA shapes what gets an ID.

Where Safeguard fits

Safeguard would not have prevented WPSplinter, and it does not analyze router firmware binaries or detect this bug in gateways. Without a CVE, vulnerability matching in any tool has nothing to match. What Safeguard can help with is the inventory and governance around incidents like this:

• Vendor records. The compliance suite includes a Vendors area and questionnaires, so you can record ISPs and network suppliers as vendors and track their answers to the questions above.
• SBOMs you receive. If a supplier gives you an SBOM for its firmware, you can load it with safeguard scan --sbom <file> and keep it alongside your own. The platform shows which projects contain a given component and version, which turns "does anything we hold list this component?" into a search rather than a hunt.
• Policies and gates. For the software you build yourself, policies and gates evaluated in the platform keep known vulnerable versions out of releases once an identifier exists.
• Your own Linux based products. If you package software as container images, safeguard scan --image <name> inventories the image and matches its components against vulnerability databases, and safeguard scan --dir . does the same for a source repository. Results land as JSON under ./output. That keeps known vulnerable open source, such as an old C library, visible in the parts you build.

Where it does not help: Safeguard cannot patch an ISP's gateway, cannot push firmware to devices you do not control, and cannot assign a CVE.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Router firmware and proprietary chip SDKs are outside what it covers, so it has no bearing on WPSplinter.

Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version. It has no record for WPSplinter, because there is no CVE, and Gold does not cover proprietary router firmware.

The habit that applies here is the general one: pull patched, signed components from a curated source and rebuild quickly, so the open source parts of your own products do not become the next forever day.

Common mistakes

• Assuming a strong Wi-Fi password protects you. The bug is reached before any key is checked.
• Assuming the WPS toggle fixes it. The researcher's documentation says it may not. Treat it as risk reduction.
• Changing the Wi-Fi password before the fix. On an affected device the new key is just as readable. Change it after the firmware fix or swap.
• Treating the vendor list as a verdict. Rows marked LIKELY or with a question mark are leads. Firmware revisions within one model can differ.
• Reading "no CVE" as "not real". The researcher demonstrated code execution on shipping ISP devices. The missing ID is a process gap, not a severity rating.
• Forgetting home workers. Branch and home gateways carry corporate traffic every day and are rarely in anyone's inventory.

FAQ

Is there a CVE for WPSplinter?

No. Broadcom, the CVE Numbering Authority for its products, declined to request one, saying the affected software is obsolete and outside its support window. CERT/CC closed its case on 4 August 2026 for that reason. WPSplinter is the researcher's informal name.

Is WPSplinter being exploited?

No. The demonstrations are the researcher's own, and with no CVE it cannot appear in CISA's KEV catalog.

Which chips are affected?

Per Kaiser: eCos based BCM3380, BCM3383 and BCM33834, and Linux based BCM3390, BCM63xx, BCM65xx and BCM68xx. A chipset match alone does not prove a firmware is vulnerable.

Does turning off WPS fix it?

Not necessarily. The documentation warns that the settings toggle may not remove or disable the vulnerable parser. It still reduces exposure on many devices and costs nothing if you do not use WPS. Proximus disabled WPS fleet wide as an interim step while it prepares firmware.

How do I know if my ISP gateway is affected?

Find the exact model and firmware, search the researcher's device list, and ask your ISP whether the device runs wps_monitor or hostapd. With shell access, look for a running wps_monitor process.

Broadcom says it fixed this in 2018. Is that wrong?

Both can be true. A fix existed, but Kaiser found many shipping devices never received it or the move to hostapd, and his 23 October analysis argues the 2018 change is incomplete anyway.

Does Safeguard detect WPSplinter?

No. Safeguard does not analyze router firmware, and there is no CVE to match. It can help you track suppliers, hold the SBOMs they give you and keep the open source in your own products current.

WPSplinter is the extreme case of the second gap below: for eCos gateways there is no upstream fix coming, and for the rest the fix depends on manufacturers you do not control. The steps in this section apply to the open source you build into your own products, which is where you can act today.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval, pushing nothing. For WPSplinter, the same loop fits the repository where your team keeps network device configuration or the build for a Linux based product: you would ask it to turn WPS off in managed access point templates or to bump the C library in a firmware build. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The runner demo shows setting up the Safeguard runner on your own machine, approving it with its device code, and scanning from the terminal. Here, a firmware or product team would run scans on an internal build host, against the root filesystem images and supplier SBOMs it holds, and read the JSON under ./output for the C library version.

Click through it at your own pace, or open it full screen.

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. For an incident like this one, a security lead could then ask Claude which products and SBOMs in the platform list a given component and version, without opening the dashboard.

Click through it at your own pace, or open it full screen.

To try it on your own builds, download Safeguard and follow the CLI docs. For related reading, see edge device zero-days in October 2026, AI found vulnerabilities in PHP2Shell and PwnEscape, SBOM incident response: finding affected products fast and October 2026 security incidents and what would have helped.

Quick check

Sources

• Quentin Kaiser: One Parser, Two Bugs, Many Routers: Exploiting Broadcom WiFi Across eCos and Linux (16 Oct 2026, updated 20 Oct)
• Quentin Kaiser: Reconstructing Broadcom's 2018 WPS Patch (23 Oct 2026)
• Quentin Kaiser: site feed with publication times
• WPSplinter documentation site
• qkaiser/broadcom-wps on GitHub: YARA rules, fingerprinting script, device list
• Hexacon 2026 slides: One Parser, Two Bugs, Many Routers (PDF)
• CVE record: CVE-2020-6096 (glibc ARMv7 memcpy)
• NVD: CVE-2020-6096
• TALOS-2020-1019 report for CVE-2020-6096
• The Hacker News: Unpatched Broadcom Wi-Fi flaw (19 Oct 2026)
• Techzine: Broadcom WPSplinter vulnerability leaves millions of Belgian routers vulnerable (19 Oct 2026)
• Univers Freebox: French ISP boxes possibly concerned (18 Oct 2026)
• CISA Known Exploited Vulnerabilities catalog (JSON feed)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.