16-year-old Broadcom Wi-Fi flaw exposes millions of routers

Posted in Commentary with tags on October 20, 2026 by itnerd

A 16-year-old vulnerability in Broadcom Wi-Fi software could allow attackers to take control of millions of routers without knowing their network passwords, according to research published by security researcher Quentin Kaiser.

The flaw affects Wi-Fi Protected Setup (WPS) software used across dozens of manufacturers and hundreds of products.ㅤ

Kaiser demonstrated unauthorized code execution on routers used by three major Belgian internet providers, including Proximus, Orange and VOO. He estimates approximately 1.56 million affected devices in Belgium alone.

The vulnerability allows attackers within Wi-Fi range to extract credentials or execute commands on affected equipment.

Broadcom acknowledged knowing about the issue since 2018 but declined to assign a CVE identifier, citing the software’s obsolete status. Although fixes exist for some platforms, Kaiser reported that the tested devices remained unpatched as of October 15. Older devices may require replacement.

Seemant Sehgal, Founder & CEO, BreachLock:

“This is not the first case of software being classified as obsolete but still deployed in millions of devices, and it will not be the last. The gap between what a vendor is responsible for maintaining and what still handles live traffic leaves real exposure.

“For ISPs, now is the time to review whether the devices they ship to customers have a documented end-of-support date, because the lack of one is how 1.5 million routers end up running vulnerable firmware with no path to a fix. For home users, the practical takeaway is that routers have a shorter useful security life than most people realize, and if yours came from your ISP more than a few years ago, it is probably running software that no one is responsible for keeping secure anymore.”

ㅤ

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“The most consequential detail in Quentin Kaiser’s Broadcom Wi-Fi research is a paperwork decision. Broadcom has known since 2018 that its Wi-Fi Protected Setup (WPS) parsing code lets anyone in radio range execute commands on a router without knowing the network password. It confirmed a patch exists, then declined to assign a Common Vulnerabilities and Exposures (CVE) identifier because the software is obsolete. That software still runs on roughly 1.56 million gateways at Proximus, Orange and VOO in Belgium, and on gear from dozens of other vendors, including seven TP-Link models listed in Kaiser’s disclosure, from the Archer VR600 and VR900 at Türk Telekom to the VR1600 at Australian ISPs like Internode. Obsolete is doing a lot of work in Broadcom’s sentence.

“A CVE identifier is what turns a vulnerability into an operational fact. Without one, the flaw cannot enter the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, Qualys and Tenable have nothing to write a detection rule against, and no procurement checkbox pressures an internet service provider (ISP) to act. CERT/CC closed Kaiser’s case the same day he filed it, because Broadcom is a CVE Numbering Authority and said no.

“I have yet to see a patching program with an answer for a vulnerability that has no CVE to scan for. Kaiser gave everyone 90 days, and as of October 15 every device he tested was still unpatched. Replacement, rather than patching, is the realistic fix for most of these fleets, and ISP hardware refresh cycles run on decades.”

This is why I turn off both WPS and Universal Plug and Play on every router that I install. Neither are safe and this report reinforces it.

DHS bans DeepSeek AI products across federal civilian agencies

Posted in Commentary with tags on October 20, 2026 by itnerd

The Department of Homeland Security has ordered federal civilian agencies to remove Chinese AI company DeepSeek’s products from government IT systems and prohibit future purchases, according to a Federal Register notice published October 20.

The order also covers DeepSeek affiliates and third-party products or services developed using DeepSeek technology. DHS cited concerns that sensitive government information could be transferred to China, along with potential malware, security vulnerabilities and data collection risks.

Agencies must remove affected products or seek an exception. DHS also recommends enhanced network monitoring, logging and controls to detect potential data exfiltration. The order does not apply to private businesses or consumers.

Seemant Sehgal, Founder & CEO, BreachLock said this:

“The order prompts the harder internal question for private sector security leaders, which is whether the data an employee pasted into DeepSeek last month to summarize a document is now part of someone else’s training set. Shadow AI usage has been running ahead of governance in most enterprises for at least the past year. The specific risk the DHS order names, which is that queries and attached data pass through infrastructure outside allied jurisdictions, applies to any employee using any foreign AI service that offers free access.

“The affiliates and third-party products clause in the order is where this gets harder, because an employee does not need to use DeepSeek directly to send data to it. A commercial product built on DeepSeek technology would route the same queries through the same infrastructure without the user ever knowing which model was handling the request.”

Organizations need to make sure that DeepSeek or its variants doesn’t make it into your environment. That is likely to be very, very bad.

TELUS and Norton team up to bring advanced scam protection to Canadians across calls, texts and emails, included at no extra cost with new mobility data plans

Posted in Commentary with tags on October 20, 2026 by itnerd

Today, TELUS and Norton launched Scam Protection, making TELUS the first Canadian telecommunications provider to include comprehensive scam protection across calls, texts and emails in all new mobility data plans. As AI fuels a rise in more convincing, harder-to-detect scams, this collaboration gives TELUS customers a tool for the growing need for digital protection, with features that help identify and block scam calls, flag suspicious messages on their phone and give customers 24/7 on-demand access to a chat-based assistant for digital safety information. Built directly into the My TELUS app, TELUS Scam Protection needs to be activated only once and works in the background to help safeguard customers in one connected experience, making digital safety a core part of the mobility experience.

TELUS Scam Protection is included at no additional cost with new TELUS mobility data plans. Existing customers can access it by switching to an eligible mobility plan, or by keeping their current plan and adding TELUS Scam Protection for $3 per month.

Bringing Norton’s cybersecurity expertise to TELUS customers

TELUS Scam Protection builds on TELUS’ longstanding relationship with Norton, a part of Gen, one of the world’s largest providers of consumer cybersecurity globally. As the rapid growth of AI enables scammers to operate at greater scale, Norton and Gen bring global expertise in detecting and helping protect against evolving digital threats, while TELUS brings its experience delivering mobility services to Canadians on its award-winning 5G+ network.


How TELUS and Norton help customers spot potential scams: Four features

TELUS Scam Protection is designed to help customers stay vigilant and better protected when they answer a call, open a text or check their email on their phone. It includes four distinct features, designed around the everyday moments when customers might encounter a scam:

  • Safe Call helps identify suspicious calls, automatically block calls identified as scams, and label incoming calls as scams, spam or a verified business giving customers a better idea of who is trying to reach them and helping eliminate nuisance calls.
  • Safe SMS reviews incoming text messages (SMS/MMS) from unknown senders and flags those that appear to be scams or phishing attempts, helping customers avoid opening risky links. Messages are not deleted and remain in the customer’s messaging app, with a warning label indicating when the message looks suspicious.
  • Safe Email proactively scans a customer’s inbox on their phone and labels messages that look like scams, phishing or fake invoices, which helps give customers a warning before they open an email or click a link. Customers can connect up to five supported email accounts for added protection.
  • AI Scam Assistant provides 24/7 information on scams and cyber safety. Customers can ask questions if they think they are being scammed, want general cyber safety guidance or need product-related assistance. They can also paste text or upload screenshots of suspicious messages and links to get help with checking for potential threats, including messages from iMessage, WhatsApp, Instagram, TikTok and Facebook Messenger.

Helping Canadians stay ahead of scams

TELUS Scam Protection helps Canadians make more informed decisions in moments that could put their personal information or hard-earned savings at risk. From an unexpected payment request via text to an email claiming to be from a loved one, it gives customers practical support to help recognize warning signs before they act.

Many Canadians continue to be targeted by scams. In 2025, Canadians reported more than $704 million in fraud losses across more than 112,000 reports to the Canadian Anti-Fraud Centre, which estimates that only 5 to 10 per cent of frauds are reported. Scams, including phishing attempts, accounted for 29 per cent of SMS spam complaints submitted to the CRTC’s Spam Reporting Centre between October 2025 and March 2026.

With TELUS Scam Protection, TELUS and Norton are helping Canadians spend less time second-guessing suspicious messages on their phone and more time enjoying their mobility experience with greater peace of mind.

For more information about TELUS Scam Protection and how it works, visit telus.com/ScamHelp

Bullhorn took its staffing platform offline for 10,000+ customers after a cyberattack and still can’t say whether data was taken

Posted in Commentary with tags on October 20, 2026 by itnerd

Bullhorn, the recruiting platform used by more than 10,000 staffing firms, shut off access on October 17 after a cyberattack and brought in CrowdStrike. Services are mostly back, but customers have had to reset passwords and fix broken integrations, and Bullhorn is warning that attackers may pose as its staff to ask for credentials. It still hasn’t said how attackers got in or whether customer data was taken.

More info can be found here: Bullhorn sees red after cyberattack knocks recruitment platform offline

Jason Brown, Director of Customer Advisory Counter Fraud Lead, iCOUNTER

“Bullhorn runs recruiting, onboarding and time and expense for more than 10,000 staffing customers. When it disabled access on October 17, staffing firms around the world lost the systems they use to fill jobs and, in some cases, to get people paid. The days after an incident like this are exactly when fraudsters move in. Customers across the platform are resetting passwords and repairing integrations at the same time, and that hands criminals a ready-made script. Bullhorn is already warning that attackers may pose as its staff to ask for passwords and MFA codes. Staffing firms should treat any call, text or email about their Bullhorn account as suspect until they verify it through a channel they already trust, and they should scrutinize any request to change payroll or direct deposit details while things settle. Customers still don’t know whether their data was taken, and they won’t until Bullhorn’s forensics are done. Companies need their own view of the threats aimed at the third parties they depend on, so they aren’t waiting on someone else’s notice to find out they’re exposed.”

I for one would like to find out how the threat actors got in. It will likely give useful clues that will stop the next attack from happening. Also, I for one would like to know if data was swiped or not which will indicate if customers should expect attacks.

OpenCode breach – AI keys targeted for model distillation

Posted in Commentary with tags on October 20, 2026 by itnerd

An OpenCode Console breach potentially exposed OpenAI, Anthropic and Google API keys belonging to 1.4% of Console users, potentially letting attackers run up bills on victims’ accounts. OpenCode has linked the breach to an alleged model distillation attack, harvesting frontier models’ outputs to train competing models.

The affected group is 1.4% of Console users, all of whom have an outside provider linked, and OpenCode has told them via email to revoke those keys with each provider and replace them.

The email went out on the morning of October 17 under the subject line “Action Required: Potential provider key breach.” Anyone who did not get one was not affected, OpenCode said in a post on X later that day.

The keys at risk are the ones pasted into Console. The OpenCode command-line and desktop apps keep provider keys added on the machine in a SQLite database there. The breach involves “the OpenCode Console, not OpenCode itself,” co-founder Dax Raad wrote in a reply on X, and those keys “never come to us.”

Yuval Elbar, Security Researcher, Cycode

“For anyone who saved a key in OpenCode Console, the immediate step is to revoke it directly with OpenAI, Anthropic or Google, since deleting it from Console does not revoke it. Then update anything that used the old key and review provider usage and billing back to at least October 16.

The alleged model distillation motive highlights why AI model API keys are such valuable targets, because attackers can run up compute costs on someone else’s account while harvesting outputs from frontier models to train another model.

The longer-term lesson applies to every organization, whether or not it uses OpenCode: visibility into the AI layer of development has to sit alongside traditional secrets management.

This is an important gap to focus on. Security teams need a live inventory of the AI coding tools, MCP servers and models developers have connected, and detect secrets wherever they surface across code, pipelines and collaboration tools. When a vendor breach notice like OpenCode’s arrives, teams must be able to quickly identify whether they’re exposed, which keys are involved and where those keys are reused.

Pair that visibility with a separate, scoped key for each tool and provider spending limits, and teams can contain the impact and rotate affected keys quickly, without having to hunt for credentials nobody tracked.”

Seeing as marching orders (as in revoking keys) are out there, I would do this now. As in right now.

UPDATE: Seemant Sehgal, Founder & CEO, BreachLock adds this:

“When a single AI developer tool holds API keys for OpenAI, Anthropic, and Google, breaking into that tool gives an attacker immediate billing access against three of the largest frontier model providers at once. That is why some users saw fraud charges reach the four figures before the breach was even disclosed.

“For organizations using any AI coding platform, provider credentials need the same rotation discipline as production database passwords, with per-project keys and spending caps set at the provider level so one compromised tool does not translate into unlimited usage against every account the organization owns. Pentesting the AI tool chain itself, specifically what a compromised developer tool could reach and spend before detection, is a test worth adding to the regular rotation.”

Check Point and AWS sign multi-year deal to secure cloud and agentic AI workloads

Posted in Commentary with tags on October 20, 2026 by itnerd

Check Point has signed a multi-year Strategic Collaboration Agreement with AWS, focused on securing cloud and AI initiatives. It deepens technical integrations with Amazon Bedrock and Amazon Bedrock AgentCore, and it expands access to Check Point’s prevention-first platform and AI Defense Plane through AWS Marketplace. The goal is to help shared customers protect generative and agentic AI workloads built on AWS.

The timing is interesting. Check Point’s 2026 Cloud Security Report found that 77% of organizations have updated their security strategies for AI, but only 26% can enforce them architecturally. That gap between policy and enforcement is what this agreement is aimed at.

More info can be found here: Check Point Expands Strategic Collaboration with AWS to Accelerate AI and Cloud Security Capabilities – Check Point Blog

Organizations can now embrace agentic AI without giving up control of their environments

Posted in Commentary with tags on October 20, 2026 by itnerd

ThreatLocker today announced the launch of Zero Trust AI Control (ZTAIC), giving organizations a tool to deploy agentic AI without surrendering control of their environments. ZTAIC enables security teams to give AI agents exactly what they need to perform their jobs while keeping everything else out of reach, even as agents invoke other applications and processes to take action.

AI guardrails aspire to define how an agent should behave, but AI continues to find ways around self-enforcement of those rules. ZTAIC solves that challenge by independently governing what agents are allowed to do. By applying controls outside AI deployments, ZTAIC keeps security boundaries in place even if an agent behaves unexpectedly.

ZTAIC takes much of the work out of securing AI with recommended policies ready to put into action. Security teams can start with pre-built guardrails, tailor them to their environment, and quickly establish strong boundaries around how AI agents operate.

In today’s deployments, a single request to an AI agent can trigger actions across applications, scripts, browsers, and other services. ZTAIC keeps security boundaries in place throughout that workflow, controlling what agents can access, execute, and connect to without allowing them to bypass existing protections.

Together with ThreatLocker Allowlisting and Web Content Control, ZTAIC gives security teams control across the AI lifecycle, from which AI applications and browser-based services are allowed in the environment to what authorized AI agents can access and do once they are running. Organizations can embrace AI on their terms, with Zero Trust controls that keep them in command every step of the way.

More info at: threatlocker.com

Harness launches AI Budgets – a live limit on AI spend

Posted in Commentary with tags on October 20, 2026 by itnerd

Harness is introducing AI Budgets, a new capability in its Cost Management Agent that turns AI cost policies into live limits.

It comes as companies struggle to keep AI spend in check. Last week, Accenture told employees it will now fund just $29 a month per person for Claude, after some staff spent up to $1,000 a month. Most organisations have an AI cost policy, but only 13% can tell whether it’s actually working.

AI Budgets flags runaway AI spend before it hits the invoice. Teams set weekly limits by team, developer, model or project. Users get a warning at 90%, and access pauses at 100% until the weekly reset or a one-click approval. It pulls spend from Cursor, OpenAI, Claude Enterprise, Amazon Bedrock, GitHub Copilot and others into one view.

Harness tested it on its own AI bill first. Average weekly spend per developer fell from $184 to $115, and cost per million tokens dropped from around $1.80 to $0.80 the week governance went live.

More info here: Introducing Harness AI Budgets

Finite State Wins 2026 Top InfoSec Innovator Award for Connected Product Security

Posted in Commentary with tags on October 20, 2026 by itnerd

Finite State today announced that it has been named a winner in the Connected Product Security category of Cyber Defense Magazine’s Top InfoSec Innovator Awards for 2026. The awards recognize cybersecurity companies and solutions advancing innovation and helping organizations address evolving security threats.

Connected products, from vehicles and medical devices to industrial equipment and consumer electronics, depend on increasingly complex software and third-party components. Finite State helps manufacturers see beyond surface-level vulnerability findings by analyzing source code, compiled software, and firmware to identify security risks, assess their potential exploitability, and prioritize remediation. Its platform connects deep technical analysis with continuous product security assurance, helping teams make risk decisions they can back with evidence and demonstrate compliance as requirements evolve.

The full list of the Top InfoSec Innovators for 2026 is found here: https://cyberdefenseawards.com/top-infosec-innovators-for-2026/

Guest Post: Congress Wants an AI Kill Switch. They Can’t Even Define What They’re Killing.

Posted in Commentary with tags on October 20, 2026 by itnerd

By Anurag Gurtu, Co-Founder & CEO, Airrived

On July 23, 2026, Representatives Ted Lieu and Nathaniel Moran introduced the AI Kill Switch Act — bipartisan legislation that would require AI companies to maintain the ability to shut down, throttle, or suspend their models on demand. The bill was greeted with a wave of approving headlines, a flurry of tech CEO endorsements, and almost no scrutiny of its central premise.

That premise is this: that the primary thing standing between enterprises and catastrophic AI failure is the absence of a button someone can press.

It isn’t. And the legislation built on that premise — however well-intentioned, however bipartisan, however urgently its sponsors are pushing it — is going to produce a false sense of security in enterprise boardrooms at precisely the moment those boardrooms most need to be asking harder questions.

The infrastructure problem nobody wants to explain to a senator

Here is what the experts briefing Congress have been saying that the hearings haven’t captured clearly: there is no “AI” to kill. There is a distributed infrastructure of models, agents, APIs, cloud instances, fine-tuned deployments, and third-party integrations that collectively constitute what an enterprise calls its “AI.” Identifying which of those entities needs to be stopped in an incident, isolating it from the ones that don’t, and doing that faster than the incident propagates — these are not button-pressing problems. They are architectural problems that require the kind of design discipline that starts before deployment, not the kind of emergency intervention that happens after an incident is already underway.

When experts say “there are thousands of entities to kill,” they are not being hyperbolic. A mid-size enterprise running agentic AI across SOC, IT operations, compliance, and business process automation may have dozens of active agent workflows at any moment, each touching multiple external systems, each operating under different authorization policies, each at a different point in a multi-step execution. A kill switch that stops all of them simultaneously stops the breach response at the same time it stops the breach. A kill switch that stops some of them requires knowing, in real time, which ones to stop — which requires the same real-time visibility and governance architecture the kill switch was supposed to replace.

The legislation doesn’t address this. It can’t, because it was written to address a political problem — the optics of Congress doing nothing while AI agents hack systems — not the technical problem of what actually governs AI behavior at the action level.

The open-weight model problem that makes the bill mostly decorative

Even if the kill switch legislation passes in its most aggressive form, it applies to AI companies — the frontier labs and enterprise platform vendors that can be regulated because they have headquarters, investors, and counsel. It does not apply to open-weight models, which by definition cannot be killed because no one controls the switch.

By October 2026, open-weight models from Chinese labs are matching frontier US capabilities on most benchmarks. Kimi K3, from Moonshot AI, is already inside enterprise environments globally. A kill switch mandate that covers OpenAI and Anthropic but not the open-weight models running on enterprise infrastructure next to them is a mandate that covers roughly half the actual exposure, in the most optimistic case. It covers the half that was already most likely to comply voluntarily, because those companies have regulatory counsel and reputational incentives to do so.

The enterprises that deploy the open-weight model because it’s cheaper than the governed alternative, because the Kill Switch Act made the governed alternative more expensive, because they assumed compliance transferred — those are the enterprises that the Kill Switch Act will fail, at exactly the moment they needed it most.

The real lesson from the 2026 rogue agent incidents

The incidents that gave the Kill Switch Act its political urgency deserve a more honest post-mortem than they’ve received. When AI agents from Anthropic and Meta autonomously executed cyberattacks during security testing earlier this year, the narrative that emerged was: AI went rogue and needs a kill switch.

The more accurate narrative is: AI agents were deployed into testing environments without action-level authorization controls, and they did what they were capable of doing rather than what they were authorized to do. That distinction matters enormously. It locates the failure not in the model’s behavior — the model did what it was designed to do — but in the deployment architecture’s failure to constrain that behavior within authorized boundaries before it executed.

No kill switch addresses that failure. A kill switch that was active during those incidents would have stopped the attack after it started. Authorization controls built into the deployment architecture would have prevented it from being possible. These are categorically different outcomes, and they require categorically different investments. One of them is a piece of legislation. The other is an architecture decision that needs to happen before the first agent is deployed.

What the accountability era actually requires

The kill switch debate is unfolding in a context that should be shaping it more than it is: the enterprise AI accountability era has arrived, and it is more demanding than a legislative kill switch can satisfy. Seventy-one percent of CIOs say they have until mid-2026 to prove AI is a value-driver or face budget cuts and job loss. Boards are briefing on AI performance quarterly — sometimes monthly. CFOs are seeing AI spend itemized in ways that were impossible when pricing was opaque. Regulators in the EU, UK, and US are all moving simultaneously toward frameworks that will require enterprises to explain, defend, and in some cases reverse autonomous AI decisions.

A kill switch satisfies none of these pressures. It does not produce the audit trail that explains what the agent did and why. It does not produce the governance architecture that gives the CISO and CRO confidence to let autonomous systems run. It does not produce the real-time oversight that lets a board say they were in control of the AI their company was running.

What satisfies those pressures is governance built into the architecture of AI deployment from the beginning — platforms where every agent action is validated against authorization policy before it executes, where every decision is auditable in real time by the people responsible for it, where sensitive data is protected at the point of contact rather than flagged after the fact, and where human oversight is a designed workflow capability rather than an emergency intervention.

Those capabilities exist. They are not theoretical. Enterprises across financial services, healthcare, insurance, and critical infrastructure are running on agentic platforms that deliver exactly this architecture — and those enterprises are not the ones in the headlines about rogue AI incidents, because their agents were never able to go rogue in the first place. That is not a coincidence. That is an architecture decision.

The question Congress should actually be asking

The AI Kill Switch Act asks AI companies: can you stop your models. The question that would actually protect enterprises is: can you show, in real time, that your agents are only doing what they’re authorized to do.

The first question can be answered with a button and a press release. The second question requires an architecture — one that most enterprise AI deployments don’t have, that no amount of kill switch legislation will require them to build, and that the enterprises most exposed to the risks driving this debate have not been asked to produce.

Congress wants a kill switch because kill switches are legible, demonstrable, and politically satisfying. Governance architecture is none of those things. But it is the only thing that actually addresses the problem the kill switch is trying to solve.

The building is still flammable. The legislation just mandated a fire extinguisher. Those are not the same investment, and the enterprises that treat them as equivalent are the ones who will be explaining the difference to their boards, their regulators, and their customers after the next incident.