Synology warns of ransomware on outdated devices and 5 more

What people are saying

It drew 207 points and 83 comments. Commenters described scam emails that contained full booking details, and the thread treats those emails as a sign of a fresh compromise.

What holds up

Frontier has a documented earlier incident. In our reading, according to that report, exposed data included contact details, Social Security, passport and driver's license numbers, and date and place of birth. A law firm recruiting plaintiffs puts the count at 11,482 individuals.

Who did it is contested. A lawsuit filed July 15 in Denver federal court named a responsible group. A member of ShinyHunters told DataBreaches.net it had nothing to do with attacking Frontier. A newer extortion group, ExfilSquad, claimed to have taken 43 gigabytes and 2.4 million records. The same report cautions that attackers regularly make false claims, including about victims. A researcher had earlier flagged exposed data in Frontier's mobile API and website, and the airline fixed most but not all of those flaws by mid-June.

None of this establishes a new breach behind the current scam emails. In plain words: unconfirmed.

Inside the threads

The top comment opened by saying it "seems early to speculate," and much of the thread stayed in that register. Another commenter raised a claimed exposure at Amadeus, a major airline booking backend. One practitioner guessed that a flight status lookup was abused to enumerate itineraries, reasoning that an attacker with full access would do something more lucrative than phishing. Others recalled a misconfigured Microsoft Power Pages site that leaked Frontier data earlier this year, and one suggested checking email headers for SPF, DKIM and DMARC alignment. In our reading, the shared vendor and Amadeus links are guesses that have not been verified.

Our take

We think two stories are being merged: a summer breach that was notified and litigated, and a current phishing wave that may or may not stem from it. The scale figures in circulation come from a lawyer's marketing page and an extortion group's own claim, and neither should drive your response. What is underrated is the phishing risk itself. Itinerary data is enough to make a lure look genuine, whatever its origin. A shared booking or customer service platform, if one is involved, would matter more to your third-party program than any single airline. We would treat this as a phishing event now and a vendor question later.

What to do

• Warn employees who travel that emails quoting real booking details can still be fraudulent, and route them to report rather than click.
• Confirm your own mail domains enforce DMARC at quarantine or reject, not monitoring only.

What people are saying

Supermarket refrigerators and freezers warmed up during the night of 1 to 2 November, according to CyPro. An X post described the disruptions as spreading across Europe, with Sweden and Belgium affected.

On Hacker News, the lead comment noted that this first hit France more than three weeks earlier. The same commenter blamed chains for failing to update their software in time.

What holds up

The BBC reports that dozens of supermarkets across six European countries were hit by a suspected cyber-attack on their refrigerators and freezers. Around 40 Delhaize stores in Belgium and Luxembourg were affected, with smaller numbers in Sweden, Ireland, the Netherlands and Estonia.

Company statements confirm the disruption. A Delhaize spokesperson told the Guardian that cooling temperatures had risen and that the incident was being investigated. ICA said a small number of its stores operating outside its central network were affected. Coop said seven of its 800 Swedish stores were hit. Musgrave Group confirmed a cyber incident limited to a specific refrigerator model. Danfoss said systems at at least 17 companies in the Netherlands were attacked.

Attribution is less settled. The chief executive of Sabcobel, which operates Delhaize's systems, called it a cyber-attack. Delhaize has confirmed only an IT incident, and the cause remains under investigation. It is unclear who is behind it, and the national cybersecurity agencies of Belgium and Sweden said they were monitoring the incident.

The patching claim does not hold as stated. The Sabcobel chief said the units needed physical modifications, not just software updates. Nothing confirms that a Danfoss flaw played a role in Belgium. Delhaize has also not confirmed reports of temperatures reaching 70 degrees Celsius.

For context on France: Danfoss said the affected units there were running outdated firmware, according to Reuters.

Our verdict: partly confirmed.

Inside the threads

The largest camp on Hacker News blamed the chains, and many commenters asked why freezers are on the internet at all. Some asked why the units are not on their own virtual local area network.

Practitioners added context. One said vendors expose these units for convenience because a virtual private network (VPN) for every store is too complex for them to run. Another noted that connecting them was likely considered best practice at installation, and that "Their support contract required them to stay connected." Others questioned whether insurance would pay out if the exposure counts as negligent.

One comment drifted into broad claims about Europe's preparedness that the evidence does not address.

Our take

We think the story is less about refrigerators than about contractor-managed operational technology (OT) that sits outside the security team's view. The ICA detail about stores outside its central network points to the familiar gap: franchise and supplier-run sites.

If the fix requires hardware changes, patch cadence alone was never going to close this within three weeks.

What we think is underrated is detection. Food losses scale with the hours before anyone notices, so an independent temperature alarm matters as much as the patch.

This is a third-party risk problem as much as a vulnerability problem.

What to do

• Inventory every refrigeration and building controller across your sites, including franchise and contractor-run locations, and confirm none is directly reachable from the internet. CERT-FR recommends removing these assets from direct exposure.
• Ask refrigeration contractors in writing which controller families and firmware they run, and whether hardware changes are required.
• Add temperature alarms that do not depend on the controller itself. In France, attackers disabled alarm systems before changing settings.
• Review supplier remote access paths against your OT security baseline.

What people are saying

A post on X claimed that Anthropic's 14 trillion parameter Mythos-class model allegedly leaked on Hugging Face. It said an alleged internal Mythos-class checkpoint had surfaced on the platform.

What holds up

The X post that spread the claim also says there is no independent verification that these are genuine Anthropic weights. Commenters said the upload is almost 8 terabytes. In our reading, nothing establishes that the files came from Anthropic, that any Anthropic model was taken, or that the files are malicious. We rate the claim unconfirmed.

Inside the threads

The largest camp on Hacker News called the upload fake and a lure. One commenter wrote it was "just a way to get less knowledgeable people to run code." That commenter tied it to an earlier claim that a Fable 5 checkpoint was up for sale on a deep web forum.

A second camp argued the size makes casual downloads unlikely. Others debated the risk itself. One commenter said there is no malware concern if only the weight files are downloaded. Another raised poisoned weights as a separate concern.

Some commenters pointed to tensors seeded with deterministic pseudo random numbers as evidence of fakery, and another commenter questioned that reading. Speculation ran loose: some joked the AI uploaded its own weights. One reader asked whether Anthropic had decided to go open weights, which misreads an alleged leak as a release.

Our take

We think the question of authenticity matters less to most security teams than the lure. A file billed as a leaked frontier model is bait aimed squarely at the curious engineers and researchers inside your organization. That risk is not hypothetical: ReversingLabs researchers identified nullifAI, an attack technique used on Hugging Face. The 8TB size argument is reassuring for home users but less so for staff with access to company GPU clusters and storage, which is where a bad file would do the most harm. The "weights are just data" comfort is overstated in our view, since bundled code and loaders are part of what people actually run. We would not spend time on the intellectual property debate in the thread unless Anthropic confirms a loss.

What to do

• Remind machine learning and research teams that "leaked model" uploads are a known lure, and that downloading them onto company infrastructure needs security review.
• Require that third-party model files be opened only in isolated environments with no network access, no credentials and no production data.
• Treat any code shipped with a model, including reference implementations, as untrusted software subject to your normal review.

What people are saying

Posts are circulating that Synology has told customers to update DiskStation Manager (DSM), the operating system on its network-attached storage (NAS) devices, after ransomware attacks on old versions. A Bluesky post repeated the vendor's headline. A post on X from a technology news outlet tied the issue to a ransomware attack on an internet-accessible Synology NAS.

What holds up

In a press release dated October 29, 2026, Synology said it has identified threat actors exploiting a vulnerability patched in December 2024 to target devices running outdated DSM versions. It said the attacks aim to encrypt data and extort ransom, and it pointed customers to advisory Synology-SA-24:20.

A second Synology release says the threat targets end-of-life DSM versions. Synology found it during an impact investigation into the recently disclosed PHP2Shell vulnerabilities. That release says PHP2Shell affects only systems running certain PHP-dependent packages. Synology has shipped PHP updates for DSM 7.4 and 7.3 and for end-of-life DSM 7.2, 7.1, 7.0 and 6.2.

The claim is confirmed. The vendor states it directly.

Inside the threads

The visible chatter is mostly reposts of Synology's headline, with little technical debate. The news outlet's post framed the story around one owner's lapses, calling it "a series of catastrophic errors." That post also described the flaw as 18 months old. In our reading, that figure does not match a patch from December 2024, and the post may describe an earlier incident. We also see a risk that readers will treat this campaign as a PHP2Shell attack. In our reading of Synology's release, the exploited flaw is the 2024 one, and PHP2Shell is a separate issue.

Our take

The core point is simple, and it is not new. Attackers are using a patch that is close to two years old against devices nobody updated. We think the real exposure in most enterprises is the NAS that sits outside central patch management: a branch-office box, a departmental file share, or a backup target someone set up years ago. When that device holds your backups, ransomware on it removes the recovery path you would count on after an incident elsewhere. We think the coverage that blames a single careless owner understates the risk. End-of-life DSM versions are part of this campaign, and many organizations do not know where those devices are. The PHP2Shell work is a separate patch task, and teams should not assume one update closes both issues.

What to do

• Inventory every Synology device, including those in branch offices and those managed by third parties, and record its DSM version. Check each version against Synology-SA-24:20.
• Update vulnerable devices now. Plan replacement or a supported upgrade path for anything on end-of-life DSM, and enable automatic updates as Synology recommends.
• If you run any of the PHP-dependent packages Synology lists, update PHP through Package Center. MailStation needs a manual update.
• Remove direct internet exposure of NAS management interfaces. Keep at least one backup copy offline or immutable, off the NAS itself.

What people are saying

Savannah is where much of the GNU userland lives, including Bash and Coreutils. On Reddit's r/netsec, the post drew a commenter who questioned whether the research stayed within approved bounds.

What holds up

The Free Software Foundation (FSF) incident report says Hacktron researchers reported the flaw on May 11, 2026 and demonstrated an exploit against the live system. It describes the first finding as a command injection that allowed authenticated remote code execution. That flaw was introduced in the March 7, 2026 savane release and affected both savannah.gnu.org and savannah.nongnu.org.

The FSF also says the researchers then escalated to root using kernel bugs. It installed a fixed kernel on May 14, 2026, three days after the report.

The Bash claim rests on Hacktron's account. The researchers say they confirmed the maintainer's key page accepted edits and stopped there, without adding a key or touching the repository. The FSF says it believes neither sensitive project data nor credentials were accessed, and that Savannah's supply chain was not compromised. Tech Insider also stressed that nobody has shown attackers actually backdoored Bash.

Our verdict is partly confirmed. The FSF establishes the flaw, the root access and the fix. The route to Bash push access comes from the researchers alone.

Inside the threads

The r/netsec discussion is narrow. One commenter accepted the case for reducing attack surface but said the later steps looked like the researchers "didn't get pre-approval and just breached GNU for sensations." The FSF's announcement takes a cooperative tone and says the issues are now resolved. There is also a quieter gap on scope. Hacktron counts 26 confirmed vulnerabilities, while the FSF says some reported issues did not apply to its systems. In our reading, readers passing the headline along should keep capability and compromise separate.

Our take

We think the core risk is real and not overblown: one web input on a shared forge reached root. The more underrated detail is the kernel. As root, the researchers say they also found a key that reached a GNU backup host. In our view that is the classic pattern of one host holding too much trust. The authorization question in the thread is fair to raise for any unsolicited testing of live systems. For security leaders, the lesson is to decide in advance what outside researchers may do on your production systems.

What to do

• If you run a savane instance, apply the published fixes. The FSF contacted the operator of another known public instance to review its environment.
• Review where your builds pull upstream source and how commits and releases are verified.
• Update your vulnerability disclosure policy to state what testing on live systems is permitted and when researchers must stop.