Broadcom WPS flaw: no CVE on 19 October, 90 days after the report; Broadcom cites a 2018 replacement

90 days from report to disclosure, and no CVE on 19 October

A security researcher reported a flaw in Broadcom's Wi-Fi Protected Setup (WPS) code to Broadcom on 18 July 2026 and disclosed it on 16 October 2026. That is 90 days (derived from the two dates in the researcher's write-up). Broadcom answered within 10 days (derived; the write-up dates its reply 28 July) and, in the researcher's account, refused to register a CVE. Between 07:38 and 07:39 UTC on Monday 19 October 2026 the National Vulnerability Database returned no record for any of ten keyword searches on the flaw, and the CISA Known Exploited Vulnerabilities catalogue (version 2026.10.16) has no matching entry. Seven further searches, run at 09:01, 09:12 and 09:14 BST, gave the same result. The time stamps are in the text because every one of those statements can stop being true at any hour.

The claim, in one sentence: Broadcom's older WPS code mishandles fragmented setup messages in a way that lets someone within radio range read memory and run code on a gateway, without the Wi-Fi password and without completing a WPS enrolment. The researcher demonstrated it against an Orange Belgium gateway (reading its Wi-Fi password off the device) and a Proximus gateway (a shell over Wi-Fi frames), and says VOO gateways are also affected. This briefing says nothing further about how it works, and no address, key, message format or device recipe appears in it.

What the record does not establish is the larger part of the story. It does not establish how many devices are affected: the largest figure that can be computed from it is a sum of three provider estimates, 1,560,000 gateways in Belgium (derived), which the researcher rates as medium confidence. It does not establish that any UK device uses the code: no UK provider appears in any list read. It does not establish that anyone has used the flaw outside the researcher's demonstrations: no source reports that. And it does not give Broadcom's position in Broadcom's own voice: that rests on a message quoted on a slide and on the researcher's account, because no Broadcom statement was found.

How this was read. The researcher's write-up, his project page, the repository README and the 107-page slide deck were fetched and read in full from the researcher's own site and from GitHub. The Hacker News report of 19 October (07:29 BST) was read in full too, but only as a pointer: its page answered one request with a bot check, which was not bypassed, and served normally on a later plain request. Where it differs from the researcher's material, this briefing follows the researcher's material and says so. Nothing was filled in or submitted. The first fetch was at 08:34 BST and the last re-check at 09:14 BST on Monday 19 October 2026. The researcher is not named in this briefing, and nor is anyone else.

The claim, and what the record around it states and does not state

The table sets what the researcher's documents and the other sources read state against what they leave unsaid. "Not stated" means not found in the sources read, in full where they are named as read in full. It does not mean the information does not exist.

What the researcher's write-up, project page, README and slides state about the Broadcom WPS flaw, what they do not, and what the checks made on 19 October 2026 found. Quotation marks show the sources' own words.

The question	Stated	Not stated
What is the flaw?	A flaw in Broadcom's legacy WPS Monitor code in how fragmented setup messages are reassembled, reachable over Wi-Fi before enrolment completes. The page says it can cause "controlled memory disclosure and arbitrary code execution".	Any severity score. Which firmware builds are vulnerable: the page says a chipset match alone does not establish it.
What was demonstrated?	Unauthenticated code execution on an Orange Belgium gateway and a Proximus gateway, in two videos. The write-up says the flaw is "present and exploitable" on VOO devices too.	Any video of a VOO device, any UK device, any attack outside the researcher's own tests.
How far does it reach?	The write-up says the flaw affects "dozens of vendors, hundreds of products, and millions of Broadcom-based access points worldwide". The list is flagged as not exhaustive.	A device count. The 'millions' is the researcher's estimate and is not broken down.
Has it been used?	Nothing read reports use outside the demonstrations. The Hacker News says the researcher reports no real-world attacks; his write-up does not say so in those words. The write-up names nearest-neighbour attacks and hotel networks as the use it expects.	Any evidence of use. One slide's side note says the flaw would be wormable on Linux-based devices; no spread is shown.
Is there a CVE, an advisory or a score?	No CVE (the project page says Broadcom declined to request one). No NVD record and no KEV entry on 19 October.	Any CVSS score, any Broadcom advisory, any CERT/CC note: the researcher says CERT/CC closed his case the day it opened.
Have providers and makers answered?	Proximus asked for the full report on 29 July and held a call on 25 August. The write-up says the researcher has "no information about the measures taken" by affected vendors and providers.	Any statement from Orange Belgium, VOO, Proximus, Telenet, Sagemcom, Askey or Netgear. Orange Belgium gave no answer, per the write-up. None was found on the news pages searched.
Has a UK body said anything?	No item in the NCSC's combined, news, blog or report feeds matches Broadcom, WPS or Wi-Fi; the combined feed's newest item is dated 15 October.	Any NCSC, OPSS or Ofcom position on this flaw.

Two sources that look independent are not. The Security Affairs report of 19 October and the French-language coverage read (Univers Freebox) repeat the write-up and the slides, and add no provider statement. Where the briefing says "the researcher says", the only source is the researcher's own material. A conference talk is not peer review, and a finder has an interest in the finding being taken seriously, as any publisher does. That is not a reason to doubt the demonstrations, which are on video; it is a reason to keep the claims about scale apart from the claims about the demonstrations.

What Broadcom is quoted as saying, and what is missing

Broadcom sells the chips and the software development kit (SDK) that these gateways are built on, so it has an interest in how the flaw is labelled. Its stated reason for not requesting a CVE, as the project page reports it, is that the affected software is obsolete and outside its support window. Apart from the researcher's paraphrases, the only text attributed to Broadcom is a reply the researcher shows on slide 97. It reads, in part: Broadcom has "known about this specific vulnerability for a long time" (the write-up paraphrases that as since 2018), and for several years has offered customers "updated software that lacks this vulnerability". It adds that the WPS Monitor code was "replaced starting in 2018" by an implementation based on hostapd and wpa_supplicant, and that the researcher's report was based on the 18.1 SDK release.

Broadcom's position as it appears in the researcher's slide 97 and write-up. Nothing here comes from a Broadcom page: its Product Security Center page is built by script and could not be read with the tools used, and no statement was found.

The question	Stated	Not stated
When did Broadcom reply?	The write-up dates the reply 28 July, 10 days after the first report (derived). The slide dates it 27 July, 9 days after.	Which date is right. The reply may have been to the first or the second report (sent 27 July).
Is the flaw fixed?	Updated software exists, and the old WPS code was replaced from 2018 (both as quoted on the slide).	Which chip families or SDK versions the updated software covers, and whether it can run on the oldest of them.
Were makers told?	The researcher says Broadcom told manufacturers (OEMs) through its customer portal.	The content, date and recipients of any notice. The researcher says Broadcom refused to give him a copy.
Why no CVE?	The project page: the software is obsolete and outside Broadcom's support window. The write-up: Broadcom refused to register one.	Broadcom's own wording of the refusal. Whether any Broadcom unit is a CNA for this scope (see below).

Read side by side, Broadcom's position and the researcher's are less opposed than the headlines suggest. Both say a replacement for the old code exists. They differ on whether that is a fix. The researcher calls the 2018 change an "incomplete patch" released "silently", and says that for the oldest chip families the result is a "definitive forever day". The headline word "unpatched" is the researcher's last check on tested devices, not a statement that no patch exists anywhere. The Hacker News goes further and says in its text that there is "no patch to install"; the researcher's own timeline records Broadcom saying a patch is available, so this briefing follows the primary.

The 90 days, dated, and a deadline that moved

Dates as printed in the researcher's write-up (16 October 2026) and slides; day counts from the first report are derived by calc.py. 'Researcher's account' means no other source confirms the event.

Date in 2026	What the researcher records	Days after first report (derived)
18 Jul (Sat)	First report sent to Broadcom's product security team, covering the older eCos-based chip families.	0
27 Jul (Mon)	Second report sent, covering the newer Linux-based families. The slide dates Broadcom's reply to this day.	9
28 Jul (Tue)	Broadcom answers that a patch is available and says to tell any affected manufacturer to contact Broadcom (write-up).	10
29 Jul (Wed)	Broadcom refuses a CVE and refuses to share its notice to manufacturers. Report sent to Proximus; contact attempted with Orange Belgium and VOO; report and toolkit sent to Belgium's cyber security centre.	11
4 Aug (Tue)	CERT/CC case opened and closed the same day, because Broadcom is a CNA and would not register a CVE (the researcher's account).	17
25 Aug (Tue)	Follow-up call with a Proximus product security analyst.	38
15 Oct (Thu)	The researcher's last check: none of the affected devices he tested had been patched.	89
16 Oct (Fri)	Talk in Paris; write-up and project page published. The 90 days end.	90
19 Oct (Mon)	This briefing's reading: no NVD record, no KEV entry, no provider statement found.	93

One thing in the researcher's own material does not match. His post of 18 July, published the day of the first report, speaks of a coordinated disclosure process "with a 30-day deadline" and details to follow on 19 August. The October write-up speaks of a "strict 90-day disclosure policy" and says all parties were told the deadline was 16 October. From 18 July, 19 August is 32 days later and 16 October is 90 days later (both derived). The sources read do not say why the deadline changed. The 90 days in this briefing's title is the gap between two dates in the October write-up, not a deadline the researcher's documents agree on.

What the table does not show is any provider acting. Between 29 July and 16 October the write-up records one provider call and no fix. It is a researcher's log, so silence in it is not proof that a provider did nothing; it is proof that the researcher was told nothing he reports.

Four labels doing the work of a fix

The friendly-name fallacy here is not one word but four, each true in its own sense and each easy to read as a control.

Patched. Broadcom says updated software exists, and the researcher says none of the devices he tested had it on 15 October. Both can be true: a fix held by a chip maker is not a fix on a gateway. Between them sit the device maker, which has to build and test firmware, and the internet provider, which has to push it. The researcher's slides draw three paths for that journey (diagram below), and the researcher's Paris survey of six boxes seen over the air classes four as patched and two as not. Six is a sample, not a rate, but it shows patched firmware exists on some products on the market. It does not show which group any UK gateway would be in.

Obsolete. Broadcom's word describes its own support, not the installed base. The researcher's write-up is about code that Broadcom calls obsolete and that tested, deployed gateways still run. The NCSC's guidance on obsolete products puts the consequence plainly: for an organisation that cannot move off one, "the only fully effective way to mitigate this risk is to stop using the obsolete product".

WPS off. It is tempting to read "WPS" as a feature you can turn off. The project page asks the question itself, whether disabling WPS in the settings fixes the problem, and answers "Do not assume so": a settings toggle may not remove or fully disable the vulnerable parser. That is the researcher's caution, not a test result, but it is the only statement on the point in the sources read.

No CVE. It means no identifier, not no flaw. The next section says what that does and does not change.

The chip families are where the labels run out. The Hacker News speaks of "two families"; the write-up names six chip labels in two platform groups, and the project page and slides add more. The researcher states a fix path for six of them only, and the labels are not consistent from document to document.

Chip family labels in the researcher's write-up (16 October), project page and slides. The count of eight is derived by calc.py from the three October documents. A fix path is quoted only where the write-up gives one.

Chip family labels and where named	Fix path as the researcher states it	Not stated
BCM3380, BCM3383, BCM33834: three eCos-based families. In the write-up summary, the project page and (as BCM3384) the slides.	"Definitive forever day" on eCos-based platforms. The project page adds that older eCos-based products "may have no migration path".	Whether BCM33834 and the slides' BCM3384 are one family. The researcher's July post names BCM3383, BCM3384 and BCM33843 instead.
BCM3390, BCM65xx, BCM68xx: three families, described as Linux-based in the write-up. Slide 87 shows BCM3390 as eCos plus Linux.	"Potential forever day" on Linux platforms unless manufacturers are "willing to migrate" to hostapd.	Which manufacturers have migrated. Any date.
BCM63xx: on the project page and slides, not in the write-up's summary.	None found.	Any fix-path statement for this family.
Totals: 6 labels in the write-up, 7 on the project page, 7 on the slides, 8 across the three (derived).	Six of the eight carry a stated fix-path class: three "definitive", three "potential".	A fix-path class for the other two labels, and a list of the chips inside each family.

Slide 87 groups the labels by access medium: coaxial for the BCM33xx family, copper and fibre for the others. The families are therefore not tied to one kind of broadband line. Whether any gateway on a UK line uses one is not stated anywhere in the sources read.

No CVE: what the CVE Program's own rules say

The researcher says CERT/CC closed his case on 4 August because Broadcom is a CVE Numbering Authority (CNA) and would not register a CVE. The CVE Program's public list of CNAs, read from the CVE Program website's data file (last changed 13 October 2026), has four entries with Broadcom in the name or description, each with a stated scope: Brocade products only; CA Technologies issues only; Symantec enterprise products plus third-party software that Symantec discovers and that no other CNA covers; and VMware, Spring and Cloud Foundry issues only. None of the four names Wi-Fi software or broadband chips. The list also shows MITRE as the CNA of last resort for vulnerabilities "not already covered by a CNA". That does not show that Broadcom has no CNA able to cover this scope, because a scope line can be read broadly and the list can lag. It shows that the scope line the record names is not obvious, and a reader cannot tell from the list who owned this decision.

The more useful primary is the CVE Program's CNA Operational Rules, version 4.2.0, approved 20 August 2026. That is 33 days after the first report (derived), so it is not necessarily the text in force when the researcher wrote to Broadcom; the earlier version was not read. Read as written, it points the other way from a refusal.

What the CVE Program's CNA Operational Rules, version 4.2.0, say about a flaw like this one, with the rule numbers. Read from the CVE Program website's data file on 19 October 2026.

Rule	What it says	What it does not do
4.2.7	CNAs "SHOULD assign CVE IDs whether or not a Fix is available".	It is SHOULD, not MUST. It does not make anyone ship a fix.
4.2.17.1	CNAs "SHOULD assign CVE IDs for vulnerabilities that affect EOL Products, even if those products no longer receive Fixes", and must tag the record unsupported-when-assigned.	It does not say whether the old WPS code counts as an end-of-life product. A CNA may document its own approach (4.2.17.5).
4.2.1.2	For a publicly disclosed flaw, if the CNA with the most appropriate scope documents that it will not assign, says so within 72 hours or does not respond, a Root "MUST" make a vulnerability determination and, if one exists, direct a CNA of last resort or another CNA to assign "no later than 72 hours" after learning of the refusal.	It starts when a Root becomes aware of the refusal. No page read records that moment, or any request to a Root.
4.4.3	Where a CNA cannot make a clear decision after a good-faith effort, it "SHOULD err on the side of assignment".	It does not say who asks. A researcher can request an ID; none is recorded as having been asked of a Root.

Because the flaw was publicly disclosed on 16 October, rule 4.2.1.2 is live. Counted from the write-up's own timestamp (08:00 UTC on 16 October), 72 hours would end at 09:00 BST on 19 October (derived), but the rule runs from a Root's awareness of the refusal, which no source records. So "no CVE" may be true for hours or for months. The honest statement is the time-stamped one: none had been assigned at 07:38 UTC and at the later re-checks.

What a missing CVE costs a defender is concrete. The KEV catalogue is keyed by CVE: every entry in it carries one, so a flaw without an ID cannot be listed. Scanners and many asset tools match on CVE IDs. And the Cyber Essentials rule on patching, covered below, runs on updates that fix flaws rated critical or high by the vendor or scored 7 or above, none of which exists in any source read for this flaw. The researcher's own inference is that Broadcom's refusal to assign a CVE or to communicate publicly is "probably the reason why so many OEMs did not patch", which is inference and not something the record shows. For comparison, earlier briefings on this site met the same shape in other products: a vendor that said it fixed a critical flaw and published no CVE, score or version, and a Struts flaw where two of four affected lines are end of life and get no code fix.

How many devices? One researcher's napkin sum

The figure that travelled is "millions". The only worked estimate is the researcher's table of Belgian providers, which he built from subscriber data published by the IBPT (Belgium's telecoms regulator) and the providers' public statements about when they released each model, and rates at "medium confidence".

The researcher's estimate of affected gateways in Belgium (write-up and slide 100). Shares and the sum are derived by calc.py. The researcher's own slide ends the table with 'at least 1.5 million affected devices ?', question mark included.

Provider	Estimated affected gateways of subscribers	Models named by the researcher
Proximus	850,000 of 2,318,000 (36.7 per cent, derived)	BBOX 3, BBOX3V+
VOO (legacy fleet)	500,000 of about 500,000 (100 per cent: the estimate equals the fleet size)	Netgear CG3100, CG3700, Technicolor TC7210, CGA4233
Orange Belgium	210,000 of about 547,000 (38.4 per cent, derived)	Askey TCG3000
Telenet	No estimate ("?") of about 1,758,000 subscribers	Two Sagemcom models marked to be confirmed
Sum of the three estimates	1,560,000 (derived)	Not the whole of Belgium: Telenet is missing

Three other scale claims sit in the same documents and rest on less. The write-up says "millions" worldwide with no breakdown. A slide guesses the worldwide figure at the "low hundred million", conditional on every other provider acting as the Belgian ones did and marked with a question mark. And the README expects the final device list to run to thousands of makes and models while its table holds 52 rows from 17 vendors as read (the project page names 18). These are different quantities: gateways, access points, and models. They should not be added, compared or quoted as if they were one number.

What the Belgian table does show is the shape of the exposure. The researcher's own examples of an affected provider fleet are large shares of that provider's subscriber base, and they depend on a handful of models. That is how a flaw in a supplier's old code can become a national figure: a few gateway models deployed to many homes for years (inference from the table). It is also why the question for a UK reader is a model and firmware question, not a country question.

Found with an AI agent in under a week: the claim and its scope

The write-up's first takeaway is that the research "took me less than a week" with frontier models, where he says it would have taken months alone. His slides name the harness as "codex" and the model as "gpt-5.6-Sol" at a high thinking level, and his July post calls the harness OpenAI's coding harness and says he is vetted for "Trusted Access for Cyber". OpenAI sells those tools, so it benefits when AI-assisted research looks fast and cheap; it is not the source of any figure here, and it was not asked.

Two cost figures appear. Slide 17 is a table of tokens priced at rates the slide states and totals an estimated $906.04, of which $615.72 is cached input (derived sums match the slide to the cent, apart from one-cent rounding in two rows). Slide 18, headed Actual Cost, shows 103 euros. The slides do not say why the two differ, what the 103 covers, or whether either covers only this flaw: slide 15 lists other findings, among them flaws in other services of the same kind of device. No conversion between the two is attempted here. The honest reading is a range with unstated scope, not a price for this flaw.

What this does and does not establish. It does not establish that a human could not have found the flaw cheaply, or that the model, not the researcher's steering, did the decisive work: the July post says the human acted as validator. It bears on defenders in the way the researcher's July post argues: serious flaws will be found in chips and SDKs that are no longer supported, at a fraction of the earlier cost. One case does not prove a trend. It does show the shape to expect (an old component, a supplier who calls it obsolete, a device in service, no CVE and no fix date), and that is inference, not a finding.

UK exposure: no UK device is named, and UK rules do not require a fix for this

What is known about the UK is nothing, and this briefing does not guess. The README's deployment column names 67 provider spellings (derived), among them Optus, KPN, SFR, Movistar, Türk Telekom, Proximus, Orange Belgium and VOO. None is identified as a UK provider. One entry, "Sky Telecom", is given no country and was not matched to any UK provider. Twelve Cisco models are listed as confirmed with no provider attached. The maker names on the list (Cisco, Netgear, TP-Link, Zyxel, Huawei, ZTE, Nokia, Sagemcom, Askey and others) sell worldwide, and the page says firmware and hardware revisions differ within a model. A UK customer cannot conclude either way from a vendor name, and cannot conclude safety from a UK provider's absence from a list that its owner calls incomplete.

What can be stated is what UK rules and guidance say about a flaw of this shape. They fall into two groups: rules on the products and their makers, and rules on the providers. Neither requires a fix for a flaw with no CVE. The table gives each instrument as read, with the negative column.

UK instruments read in full or in the relevant parts on 19 October 2026, with what each requires of a flaw like this and what it does not. Quotation marks are the instrument's own words.

Instrument and date	What it requires or says	What it does not require or say
Product Security and Telecommunications Infrastructure Act 2022, Part 1 and Regulations 2023, Schedule 1. In force 29 April 2024 (903 days before this reading, derived). Enforced by OPSS for the Department for Science, Innovation and Technology.	For UK consumer connectable products, manufacturers must meet three security requirements: no universal default or guessable passwords; publish a contact for reporting security issues with when an acknowledgment and status updates "until the resolution" will come; and publish the minimum security update period. Penalty: the greater of 10 million pounds and 4 per cent of qualifying worldwide revenue (section 38).	It does not require a maker to fix a particular flaw or to obtain a CVE: a "compliance failure" is a failure to meet one of the three requirements. The guidance pages speak of new products and do not say how they treat a gateway first supplied before 29 April 2024. Section 55 leaves hiring out or lending outside "supply" unless the maker does it, so the pages read do not settle whether a provider-lent gateway is covered.
Telecommunications Security Code of Practice, version 1.1, issued 14 July 2026, under the Telecommunications (Security) Act 2021 and the 2022 Regulations. Ofcom oversees.	For large and medium public telecoms providers, provider-supplied and managed routers are in scope, for business customers as well as consumers (3.31). Providers "shall take proactive measures that are likely to result in CPE devices being replaced once they go out-of-support" (3.37). Measure M9.02: customers "shall be informed prior to, and once the equipment goes out of support, and proactively offered a replacement as soon as reasonably practicable".	It is guidance, and 0.20 says it is "not the only way" to comply. The smallest tier of providers is not expected to follow it (0.15). It does not mention WPS, Broadcom or this flaw, and does not say what a provider must do for a gateway that is in support but unpatched. Ofcom's security report for October 2024 to October 2025 praises better management of end-of-life assets and, in the text read, says nothing about provider-supplied routers.
Cyber Essentials Requirements for IT Infrastructure v3.3, April 2026.	Software on in-scope devices must be licensed and supported, removed when it becomes unsupported or put in a defined sub-set that blocks all traffic to and from the internet, and updated within 14 days of release where the fix is critical or high, or scored 7 or above. A router the organisation gives a home worker is in scope.	Wireless devices are out of scope if they are part of an ISP router at the home or remote location, or if an attacker cannot attack directly via the internet: "the Cyber Essentials scheme isn't concerned with attacks that can only be launched within the signal range". The 14-day clock needs a released update. So the scheme, on its scope text, is not built to catch this flaw as described (this briefing's reading, not an NCSC statement).
NCSC guidance: obsolete products (reviewed 13 May 2025), smart devices in the home (reviewed 23 February 2024) and the 7 April 2026 alert on routers exploited for DNS hijacking.	Treat obsolete devices as untrusted with constrained access. Avoid unsupported smart devices; install updates. In April the NCSC advised using modern systems and software and keeping devices and networks up to date, after a state actor exploited vulnerable routers.	None of the pages mentions WPS, Broadcom or this flaw. The router alert is about internet-side exploitation of known flaws, a different threat. No NCSC alert on this flaw was found in its feeds.
UK GDPR security principle and the ICO's guide to data security.	Measures must be "appropriate" to the risk, taking account of the state of the art and cost. "A good starting point" is Cyber Essentials, and home working must not compromise security.	The ICO says the UK GDPR "does not define the security measures" required, and that Cyber Essentials is "only intended to provide a 'base' set of controls". The page says it is under review because of the Data (Use and Access) Act.

Two things follow from the table, both readings rather than findings. First, the legal gap is at the point where the flaw sits: the PSTI regime makes a maker say how a flaw can be reported, when the reporter will hear back and how long updates will last, but it does not require the maker to resolve a report, least of all when the chip maker calls the component obsolete. Second, the provider rules are the only text read that speaks to the shape of this problem, equipment that has gone out of its supplier's support, and they are guidance for large and medium providers. A UK customer's route to a fix is a request to a provider or maker, not a legal claim.

A word on radio range, because it is the comfort in the story. The researcher says the attack "works over long distances", and that the close antenna in his demonstration video does not limit it. Proximity attacks on Wi-Fi are not new: Volexity's report of 22 November 2024 describes a 2022 intrusion in which a Russian state actor reached a target's Wi-Fi by first compromising neighbouring organisations. That intrusion used stolen credentials, not a router flaw, and is no evidence about this one. It is a reminder that radio range is a barrier an attacker has gone round before. For a UK site, the question is who can stand within range: shared offices, ground-floor shops, hotels and rented flats are different from a detached house.

What to do, in order

The order puts the cheap questions first, because the sources give no UK device list and no fixed firmware version. Items 6 and 7 are this briefing's inference: no source tests them against this flaw.

The question that exposes the gap

Broadcom says its replacement code dates from 2018. The researcher says tested gateways did not have it in October 2026. Between those two statements sit a maker, a provider and a customer, and the record names none of them as responsible. So the question for any UK organisation or household with a provider's gateway is a simple one: which of Broadcom, the maker and your provider holds the fix for the box on your shelf, and which of them has said so in writing?

Key facts