122°F in the Freezer Case: The Night Refrigeration Systems Turned Into Heaters

Attacks on refrigeration systems are forcing European supermarkets to throw away food. The incidents expose a disturbing possibility: even normal operating functions can cause damage.
The crucial question is not just how attackers get in, but what can still stop them once they do.

The first sign is a puddle.
On Monday morning, November 2, 2026, Mats Olsson walks into his ICA store in Böda, on the Swedish island of Öland, and finds water on the floor. He tells Swedish broadcaster SVT that his freezer system had reached 131°F (55°C) and that his refrigerated and frozen stock had been ruined. The store remains open, but the very products its systems were built to keep cold are missing.

In Stockholm, the incident also begins in the middle of the night. According to sales manager Engla Ingwall, the attack on her ICA store’s freezer systems starts around 2 a.m. It goes unnoticed for hours. Speaking to Reuters, she reports a temperature of 122°F (50°C) and ruined stock. By the time the digital tampering is discovered, physics has already done the damage.

Over the course of November 2, similar reports emerge from Belgium, Luxembourg, and Estonia. In the Netherlands, Danfoss confirms to NOS that at least 17 businesses were affected, including smaller grocery stores and a frozen-food warehouse. Three weeks earlier, a similar attack had hit hundreds of stores in France. At the time of writing, it was not publicly clear whether the same attackers were responsible.

But the immediate question does not depend on identifying the attackers: How does a system designed to cool become a source of heat? The answer lies in a function intended for normal operation.

The Machine Does What It’s Told. Just for the Wrong Person.

Ice can build up on a refrigeration system’s evaporator. It must be removed regularly to maintain effective heat transfer. Depending on the design, defrosting involves suspending cooling or actively adding heat through electric heating elements or hot refrigerant. A refrigeration system can therefore generate heat or deliberately introduce it. During a normal defrost cycle, that is not a malfunction.

The critical factors are duration, sequence, and limits. In the Belgian incidents, refrigeration service provider Sabcobel reported that evaporators had been switched into defrost mode remotely. The attackers did not need to invent a new machine function. They turned an existing one against the system’s purpose.

Behind a refrigerated display case, there is often an entire control hierarchy. Local controllers work with sensors and valves; a higher-level system manager gathers information and enables remote administration. The Danfoss AK-SM 800A examined by Claroty has an embedded web interface for managing temperature limits, schedules, alarms, and user accounts, among other functions. That saves a technician a site visit—and gives anyone with the necessary access considerable power.

Systems like these belong to operational technology, or OT: technology that monitors or affects physical processes. Here, a command does more than alter a data record. It can determine what a valve, motor, or heater does next.

Malicious process changes do not necessarily require taking over the operating system. Sufficiently privileged operator access may be enough. In its ATT&CK framework for industrial control systems, MITRE describes this attack pattern as “Modify Parameter” (T0836): altered operating parameters cause an otherwise functioning controller to carry out an unwanted sequence of operations. That alone does not establish whether malware was also used in these incidents.

The distinction matters. Anyone looking only for malicious files can miss a malicious control action. The command may be formally valid, the software may process it correctly, and the equipment may still do the wrong thing. A green status indicator tells you only about what it actually monitors. “The system is running” is not the same as “the process is under control.”

The dramatic temperature figures call for the same precision. Setpoints, evaporator temperatures, air temperatures, and product temperatures must not be confused. Changing a temperature setting to 122°F (50°C) does not prove that the food itself reached that temperature. An affected store in Estonia illustrates the point: despite a setting of 122°F, the reported rise in actual temperature was small. What mattered there was the speed of the response.

The Side Door Around Corporate IT Security

The path to the refrigeration system does not have to run through the central corporate network. ICA said the affected stores’ connections operated outside that network. That is not a complete forensic account. It does, however, explain why even professionally secured corporate IT does not automatically protect every store’s maintenance access.

A system can be separated from the point-of-sale network and still have an unprotected connection to the outside world. The UK’s NCSC explicitly warns about additional communication paths that service providers may install, such as their own cellular links. Anyone looking only at the company’s known connections may miss these access paths. What matters is the actual connection to the controller, not where one team’s responsibility ends and another’s begins.

Claroty’s Team82 documented the potential scale of this attack surface with a query that identified 2,765 publicly reachable devices on the platform it examined. That was a snapshot of exposure, not a list of hacked supermarkets. But it refutes the reassuring assumption that these management interfaces are always tucked away inside closed corporate networks.

In the Netherlands, the reporting so far points more to inadequate safeguards than to an unknown high-tech attack. A Danfoss spokesperson told NOS that the affected systems had used default passwords and had not been connected through a protected network. The spokesperson said the manufacturer had already advised removing direct internet access after the French incident. This is the vendor’s account, not an independent reconstruction of every case.

There are also documented product vulnerabilities. For the AK-SM-8xxA series, Danfoss lists CVE-2025-41450 as an authentication issue affecting versions before 4.2. In versions before 4.3.1, CVE-2025-41451 describes potential operating-system command execution, while CVE-2025-41452 concerns a web server configuration that can be manipulated, potentially causing a denial of service. The latter two vulnerabilities require successful authentication.

Team82 also described an alternative login mechanism, the “Code of the Day,” that could bypass the normal login process. The underlying problem: a strong administrator password does not protect against every flaw in an additional access mechanism.

The public sources reviewed do not establish which, if any, of these vulnerabilities were exploited in the current attacks. The product families must not be conflated, either: CERT-FR names Danfoss AK-SM and AK-SC systems, along with Copeland and Dixell XWEB systems. A single CVE therefore does not explain every incident.

Another problem remains invisible on the sales floor: aging equipment. According to the manufacturer, the older Danfoss AK-SM 800 reached end of life in May 2021. In October 2025, Danfoss reiterated that support had ended for the relevant legacy products. This system manager is not the same as the newer 800A platform. Updates for the newer platform cannot simply be applied to every older device.

The equipment may still work mechanically even after its digital controller is no longer supported. “It still keeps things cold” describes its current function, not the security of its maintenance access.

What Can Still Stop an Attacker Who Is Already Logged In?

The first line of defense belongs in front of the management interface: no direct internet exposure, secure remote access, individual accounts, and phishing-resistant multifactor authentication wherever possible. CERT-FR and the NCSC recommend this approach. It makes initial access harder. But a resilient architecture must then address a second question: What can an attacker actually do through a compromised access path?

Authentication verifies credentials. Authorization determines which actions an account may perform. Operating-parameter validation must ensure that a permitted change does not drive the process outside its approved operating conditions. These three functions are not interchangeable. MITRE therefore calls for both role-based permissions for making changes and validation of submitted values directly in the control logic.

For refrigeration systems, this means a maintenance account allowed to request a defrost cycle should not automatically be able to change every limit that constrains it. Viewing operating status, performing routine control actions, and changing protective settings require different permissions. A master key to everything turns a single compromised identity into a far larger problem.

These limits are not an abstract idea. The documentation for the Danfoss AK-CC 750 controller, for example, describes temperature- and time-based conditions for ending a defrost cycle. That does not establish that this controller was used in the affected stores. It does show what a technical review needs to ask: What limits exist, where are they enforced, and who can change them?

Checking each value in isolation against an allowed numeric range is not always enough. A robust protection strategy would also need to consider how duration, repetition, and system state interact. The applicable operating limits are those defined by the manufacturer and the system’s engineering design. A browser input form is not a sufficient security boundary: validation must be enforced where the controller actually accepts and processes changes.

Equally important is the degree of compromise the safeguards are designed to withstand. Misuse of an operator account and full compromise of a controller are different scenarios. A local software check can constrain an account with limited privileges. An attacker who also controls the software or its protective configuration, however, may be able to alter that same check. The implication for an architecture review is clear: safeguards must remain independent under the attack scenario being considered—not just on the organizational chart.

The deeper question is whether the protective functions are truly independent. If the same administrative access can both change the process and disable its limits, those functions are not independent layers of protection. If it can also alter alarm behavior, the same compromised access can delay detection. NIST explicitly warns against insufficient separation between control and protective functions in OT systems.

For a refrigeration system, this suggests a clear review criterion: additional temperature monitoring is especially useful when its configuration and alarm delivery path do not depend entirely on the same management system. Two sensors sharing a management interface that can be compromised do not, by themselves, provide two independent layers of protection. An alarm is also no substitute for a control that enforces process limits, it initially does no more than alert someone to a problem.

This also explains the limits of a network-only approach. A firewall can restrict connections to specific endpoints and services. That does not make every control action within an allowed connection appropriate. Inspecting commands more deeply requires an understanding of the protocol and access to their contents. Encryption protects data in transit; it does not establish that the instruction being transmitted is operationally appropriate.

Public reporting does not fully document which of these safeguards were present in the affected systems or which failed. The architectural question nevertheless remains precise: What function can remote access trigger, and what downstream safeguard can still prevent a dangerous sequence of operations? More network segmentation helps block unauthorized communication paths. Defending against a dangerous but permitted control action also requires appropriate permissions and process limits.

The Minutes When Damage Is Still Preventable

In Estonia, the night ended differently. A Selver store was affected after attackers accessed the control computer of an older system. The service provider reported responding within about ten minutes. According to its account, the actual temperature rose by only 3.6 to 5.4°F (2 to 3°C), and no food was damaged. Selver said this was the last location where the newer system had not yet been deployed.

Ten minutes is not a universal safety margin. The case illustrates how much the time after an attacker gains access can matter. Planning must account for the entire response: detecting a deviation, assessing it, making a decision, and intervening effectively. Those steps must fit within the time the specific process still allows. An immediate alarm is of little use if no one is responsible for responding or able to act.

Detection should, wherever possible, begin before product loss becomes visible. A nighttime defrost cycle is not suspicious by itself. A change is more telling when it comes from an unexpected source, falls outside the approved operating range, or does not match a confirmed maintenance work order. MITRE recommends correlating such observations with subsequent process data. It is not just the new value that matters, but what the equipment actually does next.

For refrigeration systems, relevant signs to investigate could include unusual defrost durations, changed alarm thresholds, or simultaneous deviations across multiple devices. These are possible detection approaches, not a reconstruction of this attack wave. Operational context also helps prevent false alarms: an approved test should be assessed differently from an unexplained change. But a scheduled maintenance window must not become a reason to ignore all activity within it without review.

Logs must make that comparison possible. Useful records would identify the account used, the device affected, what changed, and when. Where available, the previous value and the associated maintenance work order should also be linked to the change. This reflects a principle emphasized by the NCSC: logging should support specific detection objectives, not merely accumulate data. Logs reviewed only after the damage is done are not a timely warning.

Someone must then be able to interrupt the sequence. The NCSC recommends tested isolation plans: Which connection may be blocked? Which functions must continue locally? How does the service provider take over when remote maintenance is unavailable? The correct response is not necessarily to cut power to the entire system. It must protect people and bring the process into a predefined, controllable state.

The plan must also establish what visibility remains after isolation. If disconnecting remote maintenance inadvertently cuts off the only alarm channel, the on-call team loses the very feedback it needs. The test is not just whether access can be shut down. It is also whether those responsible can still tell if their countermeasure is working.

There is an easily overlooked distinction here: network isolation does not automatically undo settings that have already been changed. It may prevent further access while the equipment continues to operate with the manipulated settings. Specialists must therefore check not just the access path, but also the actual operating state and configuration. “No longer reachable” is no more of an all-clear than “running again.”

Where this can be done without creating additional risk, relevant logs and configurations should be preserved before a reset. Evidence preservation, however, must not delay necessary protective action. Restoring cooling does not, by itself, resolve the security incident: CERT-FR explicitly warns against merely resetting vulnerable legacy devices and putting them back on the internet without protection. That can leave the original weakness in place.

Recovery therefore requires more than a successful restart. The configuration must match an approved baseline, and the physical process must again operate within its intended limits. Installing new firmware alone does not establish that the process is back within those limits. Closing the incident requires both technical and operational verification.

Preparation, then, is not just a technical matter. Before an incident occurs, operators and maintenance providers must know who is authorized to block access at night, who will take charge of the system on site, and who is responsible for updates or replacement. Outsourcing maintenance does not remove those responsibilities. It makes clear agreement about who does what even more important.

The next time you stand in front of a refrigerated display case, the first thing you see is food. Behind it is a chain of sensors, software, permissions, and decisions. The security question is not just what data a device stores. It is also what the device is allowed to change in its environment—and who can intervene in time to stop it from doing the wrong thing.

On Öland, a puddle made the incident visible. In Estonia, the operator reported that the food remained undamaged. Between those two outcomes lies the real security challenge: detecting an attack before the damage reveals it, and retaining effective safeguards even after an attacker has gained access.

A backup can restore a configuration. It cannot undo hours without adequate refrigeration.

A cyberattack does not have to destroy a machine. Sometimes, making it do the wrong thing is enough.