Information securityOT and industrial systems

The Intermarché Supermarket Case: The Problems Are Always the Same

16 October 2026

The cyberattack that hit hundreds of French supermarkets in October 2026 is easily told as a story about software vulnerabilities: a vulnerable controller, a predictable password, a hacker who gets in and drives the refrigerators to 50 °C. It is a convenient reading. It is also an incomplete one. The most serious problem is not a bug: it is the architecture with which remote management of refrigeration systems has been organized for years.

There is endless talk about the risks of artificial intelligence: agents that find vulnerabilities on their own, automated attacks, models turned into weapons. None of that was needed here. To drive the refrigerators of Intermarché and the other supermarkets to 50 °C, it was enough to find management interfaces left reachable from the Internet, end-of-life controllers never replaced, remote access designed for the convenience of maintenance. These are all human choices: of design, of installation, of management. Before the AI risk, there is the human risk.

What happened

During the night of 11 to 12 October 2026, the refrigeration systems of many French supermarkets were tampered with remotely. Fridges and freezers were driven as high as 50 °C, in some cases by forcing a continuous defrost cycle, leading to spoiled goods and even a few fires. According to Economy Minister Roland Lescure, about 700 stores were hit, out of roughly 10,000 supermarkets in the country: Intermarché and Netto, Carrefour, Coopérative U, Monoprix and some E.Leclerc stores. The Paris prosecutor opened an investigation and ANSSI was tasked with analyzing the incident. There is no attribution yet.

CERT-FR published an alert on 12 October and updated it the next day: the targeted systems are Danfoss AK-SM and AK-SC series, Copeland xweb and Dixell xweb controllers. Different manufacturers, different product families.

The refrigerator controller became an Internet server

Take the most studied case, the Danfoss AK-SM 800A. It is not a thermostat: it is a System Manager installed in the store, the control center of the whole refrigeration plant. From a single console you monitor the circuits, change temperature thresholds, read alarms, modify defrost schedules, manage users and do remote maintenance.

To make service easy, the controller embeds a real web server: the StoreView Web interface, reachable from an ordinary browser at the unit’s address.

PHYSICAL PLANT
      │
      ▼
OT controller (AK-SM / AK-SC / xweb)
      │
      ├── temperatures
      ├── compressors
      ├── defrost
      ├── alarms
      └── configuration
      │
      ▼
WEB SERVER  →  IP NETWORK  →  REMOTE ACCESS

The problem is not that a web interface exists. The problem is where the trust boundary is placed. If the same interface that governs a cyber-physical system becomes reachable from the public network, an industrial device has been turned into an Internet service. And an industrial refrigerator should not have the same threat model as a website.

The Internet should not be the maintenance network of an OT plant

In August 2026 researchers at Claroty’s Team82, studying the AK-SM 800A, searched for these interfaces with Internet scanning engines: with Censys they found 2,765 reachable from the public network.

It is probably the most important figure in the whole affair. In a well-built network an attacker would have to cross the corporate firewall, the corporate network, the store network and then the OT segment before reaching the controller. With an exposed interface, the path becomes:

Internet
   │
   ▼
controller management interface
   │
   ▼
physical process

All defensive depth disappears. The attacker does not need to compromise anything first: they only need to find the device and talk directly to its management application. It is a choice that radically changes the blast radius of any vulnerability, present or future.

The vulnerabilities are there, and more will come

Claroty’s study itself is almost a textbook case. On the AK-SM 800A, Team82 documented three issues:

CVE-2025-41450: a hidden authentication mechanism based on a “code of the day” derived from the device date, which made it possible to bypass the login once the algorithm was reconstructed;
CVE-2025-41451: a post-authentication command injection through an alarm email configuration field, leading to command execution on the system;
CVE-2025-41452: the ability, for an authenticated user, to inject directives into the Nginx web server configuration, up to making it unusable.

Danfoss fixed the issues and Claroty recommends updating to release R4.3.1 or later. It has not been shown that these specific CVEs were used in the October attacks. But that is not the point.

A CVE is an event. The exposure of the management plane is an architecture. If a new pre-authentication vulnerability appears tomorrow, an Internet-exposed controller immediately turns it into a door to the physical process. And then again with the next one.

The patch that will never come

Here the French case adds a decisive element. According to Danfoss, most of the affected units are models the company no longer updates: the AK-SM 800 has been end of life since 2021, the AK-SC 355 since 2016. Copeland, for its part, spoke of a vulnerability in a discontinued, end-of-life generation of controllers.

For these devices there is no patch to install. There never will be.

And this is the normal situation in OT, not the exception. Plants are not replaced every three years like a smartphone: they stay in service for ten, fifteen, twenty years. Meanwhile manufacturers change product lines, get acquired, end support, stop shipping firmware. Sometimes the patch exists but cannot be installed without stopping or requalifying the plant. Sometimes nobody even knows that controller is still there, configured by an installer years ago.

CERT-FR says it explicitly too: keeping an end-of-life device with no security patches exposed means a very high probability of compromise. And for devices that have already been compromised, even a factory reset is not enough: it removes the attacker’s possible persistence, but the device stays vulnerable and will probably be compromised again.

The conclusion is simple, and uncomfortable: you cannot entrust the security of a plant to a manufacturer’s willingness to patch. Not because manufacturers act in bad faith, but because their life cycle does not match the plant’s.

Filter first, trust later

If the device’s software cannot be considered reliable, and sooner or later it will not be, security has to exist before the request reaches it.

It is a change of perspective. Application security, meaning the controller’s login, its sessions and internal checks, remains useful, but it becomes the last line, not the first. In front of it there must be a layer that decides who can even talk to that interface, and that does not depend in any way on the firmware it protects.

That is exactly what CERT-FR asks for. The first measure in the alert is not “change the password” and not “install the patch”: it is to remove Internet exposure of the affected units and of all units published on a public IP address, because exposing a management interface on the Internet is contrary to good practice. Remote access should be restored only through a secure VPN or a protected network, while filtering technicians’ IP addresses is acceptable only as a temporary measure.

In other words: the problem is not solved by fixing the software. It is solved by changing how the service is reached.

            INTERNET
                │
                ▼
     access gate (identity, filtering)
                │
       strong authentication
                │
                ▼
     encrypted tunnel to the site
                │
                ▼
        local OT segment
                │
                ▼
     refrigeration controller
                │
                ▼
         physical process

The controller must not know the Internet. The Internet must not know the controller. In between there must be a controlled, authenticated, monitored and revocable access layer. And, where possible, the connection should start from the site towards the management service, not from the Internet towards the controller.

How we tackle it with ZTAG: the supermarket example

This is the reasoning behind ZTAG, the Zero Trust Application Gateway we have built at LaloSpace. Let us apply it to the French case, imagining a chain with a few hundred stores and a refrigeration controller in each one.

1. The controller disappears from the Internet. No inbound port is left open at the store. It is the store router that opens a WireGuard tunnel outbound to the ZTAG hub, and keeps it alive. The controller can only be reached through that tunnel: a scanner running on the Internet, like the ones that counted the 2,765 exposed devices, no longer finds anything to count.

2. The only exposed thing is the gate. The controller’s web interface is published behind ZTAG on a managed domain (for example one per store). Before a request reaches the firmware, ZTAG decides whether it may pass. Without a valid session, the request never touches the controller: an authentication bug like the “code of the day”, which only works if the attacker can talk to the interface, is still there, but it cannot be reached by anyone who has not passed the gate.

3. Filtering comes before identity. Every access gets a score: country of origin, network type (data center, VPN, Tor), presence in CrowdSec and fail2ban blocklists, request rate. Clean scores proceed; doubtful ones still have to confirm a code; clearly hostile ones land on a decoy page, which records what they try to do and, after a few attempts, gets them automatically banned down to the firewall. Filtering profiles are assigned per domain, so access to the controllers can have much stricter rules than an ordinary website.

4. Then identity, with a second factor. The refrigeration contractor’s technician must be an enabled user on that domain, with username and email, and confirm a one-time code. IP filtering is not the only defense, as CERT-FR rightly warns, but one of the signals: the maintenance company’s trusted networks can be recognized, but identity remains mandatory for everyone else.

5. Everything is logged and revocable. Accesses, attempts, sessions and administrative actions end up in a log. A user can be disabled with one click. For SSH access to the servers behind the tunnel, ZTAG opens the port only for the technician’s IP, for a limited time, after a one-time code, and closes it on its own when the time runs out.

6. Legacy stops being an emergency. The end-of-life controller, the one for which the patch will never come, can stay in service as long as the plant needs it, because it is no longer an Internet service: it is a device on a closed segment, reachable only through a controlled path. We have not made it secure. We have stopped asking it to be secure on its own.

It is fair to say what ZTAG does not do. It does not fix the firmware and does not replace updates, which should still be applied where they exist. And it does not stop a legitimate user, with valid credentials, from setting an absurd value: that requires a safety layer in the controller itself, as we will see shortly. What it does is remove the entire class of attacks that today starts from the Internet and goes straight to the management plane, which is exactly the class that hit the French supermarkets.

On-premise does not mean isolated

The incident also dismantles an increasingly misleading distinction, the one between cloud and on-premise. The devices that were hit were on-premise systems, installed in the stores’ technical rooms. But “on-premise” does not mean “offline”.

physically:     ON-PREMISE
logically:      INTERNET-FACING
operationally:  OT CONTROL
impact:         PHYSICAL

It is perhaps the worst possible combination: the impact of an industrial system with the attack surface of an Internet application.

Likewise, the solution is not “put everything in the cloud”. A compromised central platform can open the door to thousands of plants at once. The right question is a different one: where is the control plane, who can reach it and what authority does it have? Whether it is local or in the cloud, it must stay separated into distinct layers: Internet, identity, management, OT control, plant safety, physical process. When those layers collapse into one another, a stolen password becomes a changed temperature.

Operational convenience built the risk

This architecture did not happen by chance. Sending a technician to every supermarket is expensive; letting them connect remotely costs far less. From an operational point of view it is a perfectly rational choice.

The problem is that fewer physical visits meant more remote management, more connectivity, more attack surface and, in the end, total dependence on the security of a web panel. An interface that can change the behavior of a refrigeration plant is not a handy panel: it is a privileged OT console, and it must be designed and protected as such.

The privilege model also needs questioning

Then there is a second question. Why should a remote maintenance session be able to directly change parameters capable of causing such serious physical damage?

A cyber-physical system should distinguish at least between monitoring (readings, alarms, diagnostics), ordinary configuration (schedules, notifications) and critical control (extreme setpoints, defrost, protections). The greater the physical impact of a change, the higher the authorization level it should require.

This is the concept of a safety envelope: even an authenticated administrator should not be able to issue any command at all. The controller should reject configurations that are clearly incompatible with normal operation of the plant, and going beyond those limits should require something special: additional authorization, local presence, dual approval, a time-limited maintenance mode. Security must be tied to the physics of the process, not just to the login. That is the device manufacturer’s job, and it is complementary to the gate: one decides who can arrive, the other what those who arrive can do.

Who is responsible?

It is too early to assign technical responsibility to a single actor: the attackers’ exact path in each store is not yet public. But talking only about a “Danfoss vulnerability” would be reductive, not least because several manufacturers were hit.

The chain includes the controller manufacturer, the integrator, the refrigeration installer, the connectivity provider, whoever runs IT and OT, and finally the supermarket chain. If an OT console ends up on the Internet, someone made it possible, someone installed it, someone configured the network and someone kept running it that way. OT security is a shared responsibility. But “shared” cannot mean “nobody’s”.

The real incident happened long before the attack

The night someone drove the refrigerators to 50 °C is only the moment the problem became visible.

The architectural incident had begun years earlier: when it was decided that a controller responsible for a physical process could be administered like an ordinary web application, when remote access became part of routine maintenance, when devices that were no longer supported stayed connected, and when those interfaces ended up directly on the public network.

The same applies to everything that touches the physical world: air conditioning, building automation, elevators, generators, UPS units, pumps, water systems, access control. Remote management is necessary. But it must be built on the assumption that passwords will be stolen, CVEs will be discovered, firmware will become obsolete, a device will stay unpatched and someone will try to reach it from the Internet.

A good architecture prevents each of these events from automatically becoming a physical incident. As long as the current assumption stays in place, fixing the latest CVE will only mean waiting for the next one.