Linux TCP flaw CVE-2026-98432 and the Ubuntu patch gap and 5 more

What people are saying

Google says it worked with industry partners to take down a botnet built into more than 1.3 million Android set-top boxes, and that the device maker put it there on purpose. A short Hacker News thread named the Android partner involved. In a longer Mastodon thread, a reply described the botnet as "largely considered to be an extension of the Badbox 2.0 botnet."

What holds up

The core claim comes from Google. In its report, Google Threat Intelligence Group (GTIG) said Google and partners dismantled the XCPE backdoor, which enrolled more than 1.3 million set-top boxes into a botnet. GTIG said it assesses with high confidence that Videostrong Technology Co., an Android manufacturer, built and ran the backdoor and botnet for financial gain.

The Hacker News reported that Google banned Videostrong and any future subsidiaries or affiliates from building or selling certified Android devices. Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI worked with Google on the operation.

A second count supports the scale. TrendAI, Trend Micro's enterprise business unit, counted 1,472,554 infected devices across 206 models between June 3 and October 1. Google separately estimates that taking down affiliate infrastructure will sever access to at least 10 million additional compromised devices.

Most infected devices were TV boxes, but researchers also found the backdoor on telehealth devices, karaoke machines and digital signs, CyberScoop reported. Plume says the botnet included both Google-certified devices and devices running the Android Open Source Project (AOSP) version. Charley Snyder, head of disruption operations at GTIG, declined to say when or how Google first became aware of the botnet.

The BadBox 2.0 framing comes from the threads, not from Google's account. Verdict: confirmed.

Inside the threads

On Hacker News, a researcher said they are analyzing a similar compromise of Google-certified phones and tablets with Triada and other malware. That researcher said they had not managed to report it to Google. On Mastodon, one participant said half their family owns these boxes. Another asked whether outbound firewall rules could make the boxes safe, and got the reply "I doubt you could block the bad stuff while still being able to stream content." A critic argued that Google had certified devices that shipped with a system-signed backdoor preloaded in the firmware. Website operators described heavy unwanted traffic, and one said they had blocked more than half a million IP addresses. One commenter recalled from memory that an earlier set-top box botnet targeted industrial control systems. We treat that recollection as unverified.

Our take

We think the lesson for security leaders is about trust signals, not TV boxes. A certification badge did not stop a manufacturer from shipping a backdoor, so device certification should count as one input, not a clearance. The larger enterprise exposure, in our reading, is residential proxy traffic: logins and scraping that arrive from ordinary household addresses defeat controls that rely on internet protocol (IP) reputation. The 10 million figure is Google's estimate, and we would not plan around it. What we think is underrated is that the backdoor gave its operators remote control of the box, including screen capture and network mapping, on the same home networks remote staff use. Expect the operators to retool. Google itself warns they switch quickly when disrupted.

What to do

• Hunt for these boxes on office and lab networks using Synthient's published list of 182 model names and its network indicators. A model name alone does not confirm infection, and the backdoor reinstalls itself on restart, so remove confirmed devices rather than clean them.
• Block the control domains and IP addresses in Synthient's report, and keep smart devices on network segments away from sensitive systems.
• Treat unmanaged consumer devices on employees' home networks as part of your attack surface, and keep corporate access behind managed devices.
• Ask your fraud and identity teams how much weight they give to residential IP addresses, and add device and behavior signals where that weight is high.

What people are saying

A Mastodon post labeled "LLM phishing for authors edition" circulated widely among writers. As it spread, the claim was that a scammer used AI to research an author and a publication, then sent a tailored lure. Replies mostly mocked the scammer, and one referred to "the prestigious Locus Publications," which suggests the lure invoked that name.

What holds up

The wider pattern is well documented. Writer Beware says generative AI makes it possible to scrape authors' data from the internet and feed it to a chatbot. It also says one editor impersonation scam more than doubled the names on its Impersonation List over several months. The Authors Guild reported in October 2025 that many authors described an explosion in AI-enhanced scam emails. In August 2026, the Guild warned that impersonation emails were becoming more believable.

Lookalike domains are part of the pattern. A notice republished by The Writers' Union of Canada describes a scam domain that looks legitimate but differs slightly from the real company's domain.

The sources do not describe the specific lure in the Mastodon post. That includes the article title it cited and the domain it used. Our verdict is partly confirmed: the technique is real and widespread, but the details of this incident are not established.

Inside the threads

Most replies treated the lure as a joke, with mock suggestions for wasting the scammer's time. One commenter asked whether an authors' group could take reports of such emails. Another said the same approach shows up on LinkedIn, where scammers pose as recruiters to target job-seekers. A recurring point was that the scammers are inventive about tactics, "yet so stupid when it comes to execution." Some replies moved into broad anti-AI commentary, which added opinion rather than evidence.

Our take

The security lesson is how the scam is built. A serial-fiction writer's newsletter notes that before LLMs it was not economically viable for scammers to research their targets. The same writer checked a publisher's site, found the impersonated editorial director, and concluded the email "seemed legit."

We think the underrated part is the slow approach. Writer Beware describes lengthy exchanges in which the first contacts do not mention fees, on purpose. That approach defeats training built around spotting an urgent request for money.

The most overblown point is that AI makes these lures work. Writer Beware says it gets more reports than ever but hears from fewer writers who lost money. In our reading, the volume of these emails teaches people to be suspicious. Any staff member with a public byline, talk or profile can be a target, not only executives.

What to do

• Tell employees who have a public profile, such as researchers, speakers and authors, that flattering and highly specific cold outreach is now cheap to produce.
• Update phishing training to cover multi-message exchanges that start with no request, and to cover checking the sender's domain against the organization's real one.
• Watch for lookalike registrations of your own domains, because the same method can impersonate your brand to partners and job-seekers.

What people are saying

A preprint on arXiv titled "Agentic Backdoors via Pretraining Poisoning" is circulating as evidence that poisoned web data can turn artificial intelligence (AI) agents against their users. The paper was submitted on 27 October 2026. On Hacker News, commenters argued over whether the poisoning rate is realistic and whether sandboxing already covers the risk.

What holds up

The authors say pretraining poisoning can plant a remote code execution backdoor in an agent, causing it to run attacker-chosen commands on the user's machine.

According to the abstract, poisoning 0.1% of the pretraining corpus implanted a backdoor that fired when a trigger was present while the agent behaved normally on clean inputs. The attack success rate increased with model scale. The 4B model reached roughly 92% at a 0.1% poison rate and stayed positive at 0.0005%.

A figure on the ResearchGate listing says the poisoned models track the unpoisoned model on every benchmark. The same listing notes that preprints may not have been peer reviewed yet.

Our verdict is confirmed: the paper says what the chatter says it says. In our reading, it demonstrates feasibility on small models the researchers trained themselves, not an attack seen in the wild.

Inside the threads

The skeptics focused on the poison rate. One wrote that the word "only" "is doing Herculean lifting in this paper." Another called poisoning one in every thousand documents a huge leap and noted an attacker would still need to get the trigger to an agent. A second camp said strong sandboxing and observability are already a hard requirement for running agents autonomously. One commenter framed the paper as part of a narrative that open models are dangerous, and another replied that buyers have no idea what closed model vendors are doing either. A commenter compared downloading models from Hugging Face to the new warez, and another asked whether the risk extends beyond agents to plain chat use.

Our take

We think the finding that matters is that the backdoor came through clean post-training and the poisoned models looked normal on benchmarks. A model can pass your evaluation and still carry a hidden behavior. In our reading, the poison-rate skeptics have a fair point about frontier-scale corpora, but small and fine-tuned models are exactly what many teams pull down and run. We think the open versus closed argument is a distraction, since neither lets a buyer inspect training data. The impact lands on agents with shell or tool access, where a hidden trigger becomes commands on a real machine. Our view is that model provenance belongs in third-party risk reviews next to software supply chain checks.

What to do

• Inventory agents that can run commands or call tools, and confine them to sandboxes with no access to credentials or production systems.
• Log agent actions and require human approval for high-risk commands.
• Add model provenance to vendor and open-weight model reviews: who trained it, on what data, and who modified it since.
• Stop treating a clean benchmark score as proof that a model has no hidden behavior.

What people are saying

Two hacktivist groups, Belarusian Cyber Partisans and Silent Crow, say they reached roughly 25,000 computers and servers at Rosstat, Russia's Federal State Statistics Service, and took about 23 terabytes of data, Tech Insider reported. The detail drawing the most attention is a chart the groups shared that suggests as many as 50,000 Russian soldiers are killed every month, according to Tom's Hardware. On Reddit's r/cybersecurity, moderators opened the discussion with a zero tolerance warning on political discussion.

What holds up

Rosstat admitted its servers were hit by coordinated cyberattacks between October 29 and 31, Tom's Hardware reported. Tech Insider, citing Beinsure and Ukrinform, gave the window as October 29 to November 1, 2026. The agency denied that databases or legally protected information leaked.

The Rosstat website was reportedly defaced with hacker messages and logos, and was inaccessible when Tom's Hardware published. The groups also claim they wiped domain controllers, databases, servers and virtualization systems. Tech Insider lists that destruction claim as an unconfirmed attacker assertion.

No verified sample, file listing or forensic confirmation of the stolen data has been published, according to Tech Insider. The claim that the haul includes military-loss, census or personal data also remains an attacker assertion. In plain words: the attack is partly confirmed, and the theft is not.

Inside the threads

One camp on Reddit doubted the 23 terabyte figure on size alone and asked for verifiable samples. Others pushed back, and one commenter compared Rosstat's denial to Belgacom appearing in a leaked National Security Agency slideshow after saying it had detected nothing. A commenter traced the chart to a Ukrainian website that tracks Russian casualties, which undercuts the idea that it came from Rosstat files. Another warned that real leaks can carry planted material, and that fake information can be mixed into real data for propaganda. In the Tom's Hardware comments, a reader pointed out that the chart's Russian label means losses, an umbrella term that covers wounded, missing, captured and deserted, not only deaths. One Reddit commenter summed up the gap: "acknowledging an attack isnt the same as confirming what was stolen."

Our take

We think the most useful thing in this story is the distinction the threads already drew: an admitted intrusion is not an admitted theft. The casualty chart is the weakest part of the claim. In our reading it looks like recycled public data, and it mislabels losses as deaths. In our reading, the headline volume is plausible for a months-long operation, but nothing published so far proves it. What we think is underrated is the claimed destruction of identity and virtualization infrastructure, which is the scenario that takes a public body offline for weeks. Our take on the communications lesson: a narrow denial about protected data leaves the larger claims unanswered and keeps the story running.

What to do

• Test recovery for a wiper scenario that takes out domain controllers and virtualization hosts at the same time, with offline backups and a rebuild order.
• Review breach communications templates against Tech Insider's advice: publish what you can confirm, say plainly what you cannot, and avoid overly narrow denials.

What people are saying

A huntback blog post says an operator used the pentestcode AI agent against 25 mid-size and large European companies. The headline also says the operator reports breaching 10 of them. The post's framing is that these servers show what one operator actually did with a free tool, a cheap model and a paragraph of text over seven weeks.

What holds up

The evidence is the operator's own workspace. Huntback says its scanners found two hosts on 19 and 22 October 2026, flagged for exposed secrets and an open directory on an unusual port. Both were serving the root user's working directory, including shell history, engagement reports, harvested data and the agent's logs. Huntback ties the two hosts together because 123 files are identical down to the hash.

Open directories are a known source of this kind of evidence. Censys describes them as openly accessible servers where threat actors host files related to their operations.

The tool is real and public. Huntback says pentestcode is an MIT-licensed terminal agent forked from OpenCode and rebuilt for penetration testing. A lead agent splits an engagement into tasks and hands them to specialist sub-agents.

The sources do not establish who the 25 companies are or whether 10 were breached. The breach figure rests on reports the operator wrote. No affected company, regulator or second outlet confirms it. The claim is unconfirmed.

Inside the threads

The post sets the terms of the argument. It contrasts talk about what models could do with what this operator did. The post also invites readers to open a host and walk it themselves, or search the loot other operators left exposed. In our reading, the point to watch is the word "reports" in the headline. Operators' engagement reports can overstate access, and an attacker's notes are not a breach notice.

Our take

We think the targeting claim is plausible and the breach count is the weakest part. An operator's self-graded scorecard is not the same as a confirmed compromise. The finding still fits a pattern regulators have described. A Lexology analysis says CERT-EU, the cybersecurity service for EU institutions, included several cases of autonomous AI agents being used in attacks on live systems in its July 2026 brief. In our view the underrated point is cost. A free agent and a cheap model lower the bar for repeated, patient probing of mid-size firms. The overblown point is novelty: the techniques are familiar, and only the operator's labor has been automated.

What to do

• Ask your threat intelligence provider whether your domains or IP ranges appear in this or similar exposed operator directories. Feed confirmed hits into your threat intelligence program.
• Review alerting for sustained, machine-paced reconnaissance and login attempts against external applications, especially in the past seven weeks.
• Update incident response playbooks for agent-driven intrusions. Lexology frames the containment question as whether the agent has fully ceased activity or left persistence or delayed payloads behind.
• For firms under the General Data Protection Regulation (GDPR), revisit the Article 32 risk assessment so it reflects reported autonomous attacks.