What happened to the French supermarket fridges?

On the night of 11 to 12 October 2026, attackers remotely took over the refrigeration controllers of hundreds of French supermarkets, including Intermarché, Netto, Coopérative U, Carrefour, Leclerc and Monoprix according to press reports. They forced a continuous defrost, temperatures rose as high as 50°C, and whole stocks were lost. The Paris prosecutor opened an investigation and reported fires.

How did the attackers get in?

The exact entry point has not been confirmed. What is established: the affected controllers (Danfoss AK-SM and AK-SC, Copeland and Dixell xweb) had a management interface reachable from the internet, and Danfoss says most were end-of-life or missing available updates. Changing a defrost cycle does not necessarily need a vulnerability: a valid login is enough.

What does the French cybersecurity agency recommend?

CERT-FR says to remove the devices' internet exposure, check the whole configuration (defrost schedules in particular), restore access only through a VPN or protected network, and apply the manufacturer's updates. For compromised devices it adds a factory reset and full reconfiguration. Filtering by IP address is acceptable only as an emergency measure.

My business has no connected fridges. Does this concern me?

Probably, in another form. A web back office, a database admin tool, an ERP or a client portal that is reachable from the internet and runs on a version that no longer gets security fixes carries the same risk. The question is the same: what of ours can be reached from the internet, and who keeps it updated?

French Supermarket Fridge Hack: The Real Lesson

A refrigerated cabinet wired to a control panel open to the internet, next to a padlock closed on a private network

TL;DR: On the night of 11 to 12 October 2026, attackers heated the fridges of hundreds of French supermarkets to as much as 50°C. They probably did not need a sophisticated attack. The refrigeration controllers had an admin interface reachable from the internet, and most ran end-of-life or unpatched software. Neither cause is specific to refrigeration: both show up in plenty of small-business back offices, ERPs and internal tools. Here is what happened, what France's cybersecurity agency recommends, and how we handle both risks on the software we host.

What happened

Night of 11 to 12 October. The automatic defrost, normally about two hours a day, was replaced by a forced, continuous defrost. Temperatures rose to 50°C, mostly overnight while stores were closed (Next, in French).
More than 500 stores hit, according to Al Jazeera: at least 300 Intermarché and Netto, more than 100 Coopérative U, 80 Carrefour, about 5% of Monoprix stores, and some Leclerc. A single Leclerc store reportedly lost about €220,000 of stock (BFMTV, cited by Next).
The Paris prosecutor opened an investigation and reported fires.
The hardware: Danfoss AK-SM 800 and AK-SC 355 controllers, which Danfoss describes as end-of-life, and AK-SM 800A units that had not received available updates. On 13 October CERT-FR added Copeland xweb and Dixell xweb controllers (alert CERTFR-2026-ALE-012, in French).

The detail that matters most: back in August 2025, the security firm Claroty had already counted 2,765 AK-SM 800A interfaces reachable from the internet, and fixes existed for the flaws it reported, so the problem had been public for more than a year.

Fun fact: the Netherlands had its own supermarket incident that weekend, without the fridges. On Sunday 11 October, Albert Heijn's parent Ahold Delhaize took systems offline as a precaution after a cybersecurity incident. Work stopped at several of its Dutch distribution centres, delivery drivers were logged out of their planning app, and Albert Heijn, Etos and Gall & Gall went offline (NOS, Security.NL, in Dutch). No refrigeration was touched, and the Dutch cybersecurity centre NCSC says it sees no link with the French attack so far (Security.NL). Two very different attacks on the same weekend, and the same lesson: what a store depends on is now software.

No exploit needed

Nobody has confirmed the entry point yet, but as Next points out, changing a defrost cycle only takes a valid login. A default password nobody changed, a shared contractor account or a leaked credential will do, as long as the admin screen can be reached.

That is why CERT-FR states that exposing a management interface to the internet is contrary to good practice. Its recommendations come down to four points:

Remove the affected devices' internet exposure.
Check the whole configuration, defrost schedules in particular.
Restore access only through a secure VPN or protected network.
Apply the manufacturer's updates.

It adds that filtering contractor access by IP address is acceptable in an emergency but should not be considered permanent, and that an end-of-life device restored to factory settings stays vulnerable.

The same thing, in your software

Swap "refrigeration controller" for any business tool and the scenario holds. This is what we regularly find when we take over an application:

A back office or admin page at a public address, protected only by a password, sometimes the one set at delivery.
A database admin tool (phpMyAdmin, Adminer) left online "for troubleshooting".
An application on a version that no longer gets fixes: an unsupported PHP, Symfony or AngularJS, a CMS nobody has updated.
Contractor accounts opened years ago that nobody has reviewed.
Nobody watching configuration changes: like the defrost schedules, a malicious change can go unnoticed until the damage is done.

None of these needs a brilliant attacker, only a piece of software nobody is responsible for once it has launched.

How we handle these two risks

Because we host and run most of the software we build, both questions land on us. Here is how we answer them, as set out on our security page:

No admin interface on the internet. Admin tools and database access are reachable only from inside our private Tailscale network, never from the public internet. The servers themselves have no public IP addresses. Only the applications meant for users are public, behind Google's load balancer and Cloud Armor rules. That is the "access only through a VPN or protected network" model CERT-FR recommends.

Updates that don't depend on someone remembering. Dependabot watches every repository's dependencies, a scheduled scan regularly re-checks the main branch of every live application, and every change goes through automated security checks that block the merge when they find a problem. Findings become tickets, not lost emails.

No passwords in code. Credentials live in HashiCorp Vault and Google Secret Manager. They are mounted into the application at runtime and never written to the repository.

Versioned configuration. All infrastructure is code (Terraform), changed through reviewed pull requests, so we know who changed what, and when.

One limit, which the security page states too: our private network keeps admin access off the internet but does not yet restrict each person to individual services. A list of strengths with no limits would be a sales brochure.

Questions to ask this week

What of ours is reachable from the internet? Not just the website: the back office, the ERP, the client portal, the admin tools.
Which version is each of them on, and does it still get security fixes?
Who applies those fixes, and when did they last do it?
Which contractors have access, by which route, and with which password?
If someone changed a business setting tonight, who would notice, and when?

If you can't answer the first two, a short audit is the right starting point. If the third has no answer, what's missing is a maintenance contract: ours starts at €400 a month and applies security updates as they come out, instead of a scramble the day an incident makes the news.

The French Supermarket Fridge Hack: The Same Hole Is in Your Software

No sophisticated exploit needed: an admin interface reachable from the internet and software nobody updates anymore. That combination sits in many small-business back offices too.