# After France's fridge hack, 316 dashboards were still online

**Summary:** IPinfo found 316 French refrigeration dashboards still online on October 14 after the supermarket attacks. I would make protected contractor access and emergency disconnection explicit in maintenance agreements.

- Canonical: https://markhuang.ai/news/france-fridge-hack-316-dashboards
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-20
- Section: News
- Tags: Supermarket Refrigeration, Danfoss, Operational Technology Security, Remote Maintenance, IPinfo, CERT-FR
- Source: [IPinfo](https://ipinfo.io/blog/france-fridges-hack)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![An open refrigeration service cabinet with a network cable trailing toward the viewer, beside a supermarket freezer aisle](https://cdn.markhuang.ai/news/france-fridge-hack-316-dashboards/hero.webp)

*Remote maintenance needs a connection. Whether the public Internet can reach the controller is a separate choice. Conceptual illustration.*

After attackers disrupted French supermarket refrigeration on the night of October 11 to 12, 2026, most of the exposed dashboards in [IPinfo's scan data](https://ipinfo.io/blog/france-fridges-hack) disappeared. Its October 14 scan still found 316 at the same addresses, out of 1,331 French dashboards identified on October 6 and 7. Those are Internet addresses, not a count of compromised stores.

That finding makes me ask who owns the maintenance connection. Updating a controller matters. I also want someone responsible for deciding who can reach it and for closing public access. A refrigeration contractor's ability to help remotely should not depend on leaving the management page open to the Internet.

The maintenance agreement complicates that decision. [CERT-FR's alert](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-012/) recommends removing public exposure, yet also tells operators to check insurance terms before cutting the data sent to refrigeration contractors. I read this as a reason to put secure access and emergency disconnection into the maintenance agreement before the next incident.

## The exposure predates the spoiled food

[Reuters reporting carried by ABC News](https://www.abc.net.au/news/2026-10-13/french-supermarkets-hacked-causing-fires-and-food-loss/107258724) describes supermarkets discarding food after attackers raised refrigeration temperatures. It quotes the Paris prosecutor's office reporting food losses and fires. The consequences reached the food in the cabinets and the staff who had to discard it.

IPinfo's contribution is the history before that night. Of the 1,331 French dashboard addresses it identified before the attack, 1,019 were also reachable at the same address on March 30. Its scans found a persistent population of exposed management interfaces over roughly six months. An address appearing twice does not establish uninterrupted exposure between those observations. Even with that limit, I find this history hard to square with a brief setup mistake across the exposed population.

IPinfo classified 85% of the French dashboards as running software with known security flaws, using interface fingerprints and software build information. That included 527 older controllers it identified as unsupported. These are measurements of exposure and inferred patch status. IPinfo explicitly says its scans cannot establish which vulnerabilities the attackers used, who attacked, or which stores were compromised.

## A patch does not answer who can connect

IPinfo classified 84% of the dashboards outside France as having known flaws, almost the same share as France. France had more exposed dashboards than all the other countries and territories in its count combined. I am wary of telling this as a uniquely French failure to install updates. The data points more clearly to the size of the exposed population.

The store is also not the only party whose choices deserve scrutiny. [Claroty's AK-SM 800A research](https://claroty.com/team82/research/freeze-the-controller-defrost-the-food-uncovering-vulnerabilities-in-danfoss-refrigeration-controllers) documents an alternate authentication mechanism that could bypass the configured administrator password, alongside other vulnerabilities. It says Danfoss released firmware fixes. That research establishes a product security problem; it does not establish the route used in this attack.

I want explicit responsibility for both patching and access control, with a separate check for each. Installing the available fixes cannot tell me whether the management interface still accepts connections from anywhere. Restricting access cannot make an unsupported controller maintainable forever. Equipment that no longer receives fixes still needs a replacement plan after its public route is closed.

## Remote maintenance has a job worth preserving

The [Hacker News discussion](https://news.ycombinator.com/item?id=50159616) includes calls to isolate the controllers and questions about why refrigeration needs Internet access at all. I agree with the objection to public management interfaces. I find the broader objection less useful: Claroty describes a platform that lets technicians monitor refrigeration, review alarms, and change settings remotely. Stores and contractors have practical reasons to preserve those functions.

CERT-FR makes the distinction explicit. It recommends restoring access through a secure VPN or a protected network. Filtering connections to the contractor's source IP addresses is an emergency measure, not a permanent solution. For Danfoss equipment, its recommendations also include firmware updates, Strict security mode, and changing default passwords.

The insurance warning is easy to misread. CERT-FR does not say insurance requires a publicly reachable dashboard. It says to check contractual conditions before interrupting reporting to the contractor. I would ask the store and service provider to agree on a protected route and a fallback for monitoring when remote access is unavailable. That preserves the purpose of the connection while giving someone authority to close it.

## The 316 addresses belong on a follow-up list

I am glad the exposed count fell. I would not call that proof of recovery. Even dashboards IPinfo classified as having every known fix fell from 195 to 54 at the same addresses. IPinfo interprets that as evidence of disconnection rather than simply an update campaign. A dashboard disappearing from these IPv4 scans does not prove that its operator repaired the system or removed every other access path.

If I were buying refrigeration maintenance, I would ask for an inventory that identifies each controller, its support status, and the party responsible for its remote access. I would also ask who can revoke that access during an incident and how staff will monitor temperatures while it is unavailable. These are proposed requirements, not checks I have performed on the affected systems.

For an operator handling a suspected compromise, CERT-FR also warns that a factory reset alone is insufficient for an exposed device without security fixes: the vulnerability remains. I would follow its recovery guidance with the refrigeration contractor rather than treat a working dashboard as evidence that the job is finished.

The scan count stops on October 14; it cannot tell us how many of those 316 addresses remain exposed today. It does give me a concrete question for a maintenance review: can the provider demonstrate that remote service still works through the protected route, while the public route to the controller is closed?
