The Pain in the Cold Chain: How Weak Firmware Made Warm Freezers

Note to editors: Finite State follows coordinated vulnerability disclosure. We test systems and devices safely, in controlled lab environments, and report any new security flaws we find, with remediation recommendations, to the affected vendor before anything is made public. The vulnerabilities discussed here were previously disclosed by their original researchers and patched by the vendor.

On the night of October 11, 2026, attackers reached into the refrigeration systems of hundreds of French supermarkets and turned the cooling off. In stores across chains including Intermarché and Coopérative U, defrost cycles reportedly ran without stopping, driving some units as high as 50°C (122°F) and spoiling fresh and frozen stock. France's national cybersecurity agency, ANSSI, reportedly identified a refrigeration controller vulnerability in Danfoss software and urged operators of Danfoss AK-SM and AK-SC controllers to disconnect them from the internet.

"This is a low-effort, high-impact flaw in equipment that protects the food supply. An unauthenticated attacker can take over a store's refrigeration and quietly turn it off. The technical barrier is low, the exposed population is large, and the fix depends on an update path that many operators find hard to walk. Treat it as urgent. Inventory these controllers, get their management interfaces off the public internet, and move to patched or current-generation firmware now." —Jermaine Logan, Staff Product Security Engineer, Finite State

Early discussion of the attack has centered on poor password hygiene, but the weaknesses underneath run deeper. The controller that keeps your food cold is a small networked computer running firmware, and when that firmware is weak, the damage lands in the physical world. The same class of controller runs cold-storage warehouses, food processing plants, and pharmaceutical cold chain, where a forced temperature excursion can mean spoiled medicine and failed food-safety compliance, turning a store problem into a supply-chain one.

What should worry you most is the timing. Run blind against this controller's firmware, our agent workflow re-found two of its three disclosed flaws within hours, yet Danfoss's fixes reportedly hadn't reached the older units the attackers went after. Finding a firmware flaw now takes hours, while getting the fix onto fielded devices still takes months, and that mismatch is the risk to plan around.

Reverse Engineering Is No Longer the Hard Part

When the Danfoss advisories became public, we ran a simple test. We pointed an agent-driven analysis workflow, built on our platform, at a vulnerable pre-fix build of the AK-SM 800A firmware and configured it blind, with the known CVEs withheld so nothing could steer it toward the answer. The agents worked from the compiled binary alone rather than a source tree or dependency manifest, and every candidate finding had to survive an adversarial review designed to throw out false positives.

Within hours, the workflow independently re-found two of the three disclosed flaws: the authentication bypass that provides entry and the command injection that provides code execution. We then confirmed in a controlled lab that the command injection executes, carrying attacker-controlled input through to a system shell. A Finite State engineer set up the run and reviewed the results; the agents did the finding.

The limits matter as much as the hits. The workflow did not flag the lower-severity denial-of-service, which falls outside the failure patterns this pass was tuned to find, and we confirmed the authentication bypass through analysis and review rather than live exploitation. Confirming one flaw in a lab also stops short of demonstrating the full remote attack. We did not reproduce an end-to-end chain, and we are not claiming that these specific flaws, this firmware build, or any AI tooling played a confirmed role in the French incident.

What the result does show is how far the barrier has fallen. Binary analysis that once demanded rare expertise and sustained effort is getting faster and cheaper, pushed along by increasingly capable open-weight models and open-source projects such as REA (Reverse Engineer Anything), which gives coding agents reverse-engineering tools for native binaries and firmware. Not every vulnerability will surface within hours. Still, you can no longer assume your firmware is too complex or too time-consuming for an adversary to pick apart; the safer assumption is that serious adversarial analysis can begin the moment someone obtains the file.

A Patch Available Is Not a Fleet Protected

Here is the asymmetry that should concern every manufacturer. Finding a flaw and turning it into a working exploit keeps getting faster, while producing a patch, validating it, and deploying it across an installed base does not. AttackClock, which aggregates open-source data from CISA, Mandiant, and others, puts the median time from disclosure to exploitation at about five days, against an average of roughly 137 days to patch a critical vulnerability, citing Bitsight. Those are cross-industry figures drawn largely from enterprise IT, where restarting a server doesn't put a freezer's contents at risk.

In refrigeration and other operational technology, the fix runs up against perishable goods and physical safety, and the reasons operators lag on updates are structural:

• Uptime and perishables. You can't casually reboot the system that keeps a store's food cold.
• End-of-life hardware. Some affected units no longer receive updates and can only be replaced, which is a capital project rather than a patch window.
• Scale and distribution. Pushing firmware to hundreds of scattered sites, often without central management, is genuinely hard.
• Change control. Regulated and safety-sensitive environments must validate changes before deploying them.
• Visibility gaps. Many operators have no current inventory of which firmware runs where, and you can't patch what you can't see.

Danfoss fixed all three CVEs in AK-SM 800A firmware R4.3.1, and later releases carry those fixes. Reporting on the incident nonetheless indicates the attackers targeted older software versions. The fix existed and the exposure was real at the same time, and in a large OT fleet, that is the normal condition. In refrigeration, the window between the two carries real physical and economic consequences.

Under the CRA, an Incident Like This May Trigger Reporting Obligations

Incidents like this now sit inside a changed regulatory picture. Under the EU Cyber Resilience Act, reporting obligations have applied since September 11, 2026. When manufacturers of products with digital elements become aware of an actively exploited vulnerability or a severe incident affecting their product, they must send an early warning within 24 hours through the single reporting platform, which routes it to the coordinating CSIRT and to ENISA. The broader product-security and vulnerability-handling requirements, including secure-by-design expectations and a coordinated vulnerability disclosure policy, apply from December 2027.

We aren't characterizing any manufacturer's compliance, and we aren't suggesting this is the first event of its kind. The direction is what matters. Awareness of what is in your firmware, prompt reporting, and coordination with national authorities and ENISA are becoming legal obligations under the CRA. The manufacturers that can see their own firmware clearly, and move quickly when something surfaces, will meet those obligations without scrambling.

What the Refrigeration Controller Vulnerability Looks Like in Firmware

The affected product is Danfoss's AK-SM 800A System Manager, the controller that supervises refrigeration across a store. CISA's advisory scopes the flaws to the entire AK-SM 8xxA series: the 820A, 850A, and 880A are variants of the same System Manager software line, so the same firmware and the same CVEs ship across all of them. Security researchers at Claroty's Team82 identified three vulnerabilities, which Danfoss addressed in firmware updates in 2025. Claroty published a detailed technical analysis of the vulnerabilities in August 2026. They were assigned three CVEs:

• CVE-2025-41450: authentication bypass. The controller accepts a "code of the day" in place of a user password, and that code derives entirely from the device's current date, with no per-device secret. Anyone who knows the reverse-engineered formula can compute today's code for any unit, which makes it, in effect, a universal skeleton key.
• CVE-2025-41451: remote code execution via command injection. The controller passes a configuration field, an email setting, into a system shell command without sanitization, so a crafted value runs arbitrary commands on the device.
• CVE-2025-41452: denial-of-service. An authenticated attacker can overwrite the controller's web-server configuration and crash its management interface.

Chained, the first gets an attacker in without credentials and the second gives control of the device. From there, an attacker can reach the functions that regulate temperature: forcing defrost cycles, changing setpoints and schedules, and silencing the alarms that would otherwise flag the problem. Code execution also provides a foothold on the operational network the controller sits in. Public reporting has not established whether that chain was the mechanism in the French stores, and we don't assert it.

Two facts make this practical rather than theoretical. The authentication bypass needs no stolen credentials and no per-device setup, just the current date. And the exposed population is large: Team82's review of internet-wide scan data found roughly 2,700 AK-SM 800A management interfaces directly reachable online, the kind of exposure commodity scanning surfaces with no sophistication at all.

Team82's research this year found similar classes of flaws in other manufacturers' refrigeration and building controllers, so the risk isn't unique to one vendor. Supervisory controllers for critical functions are quietly everywhere, and the risk concentrates wherever there are many small sites and little on-site IT.

Signs of Exposure and Tampering to Watch For

If you operate these controllers, the first moves are straightforward. Inventory them and the firmware versions they run. Get their management interfaces off the public internet and behind network controls, as ANSSI urged, which blunts the whole attack class regardless of patch status. Then move to patched or current-generation firmware, and migrate end-of-life units to current products, as Danfoss advises.

The following are recommended detections based on how the flaws work, not indicators we have observed in this incident; we have no telemetry on in-the-wild activity. Watch for:

• Defrost cycles or temperature excursions outside the normal schedule, and alarm settings changed or silenced
• Access to the controller's web, XML, or CGI authentication endpoints from unexpected sources or at unusual hours, and successful logins that don't match a known user
• Unexpected configuration changes, such as email or SMTP settings, web-server configuration, or new scheduled tasks
• Any management interface reachable from outside the operational network
• Outbound connections the controller initiates to unfamiliar destinations

In the coming days, expect more opportunistic scanning for exposed controllers. With the vulnerabilities public and a real-world impact on the record, the issues are easy to understand and easy to weaponize, a combination that tends to attract copycats and, eventually, automation. None of that requires a nation-state, and the prudent assumption is that exposure equals risk.

Where Manufacturers Should Put Their Effort Now

If discovery is fast and deployment is slow, your leverage sits at both ends of the cycle. First, identify readily discoverable flaws before release. Every firmware release should face sophisticated adversarial testing against the actual binary that ships, which is what a binary teardown from Finite State is built to do. It won't eliminate every vulnerability, but it materially reduces the chance you ship a serious issue an attacker can now find in an afternoon. Catching an authentication bypass before release is a different job from monitoring a running network, and pre-ship analysis and runtime defense are two halves of one stack.

Second, treat firmware already in the field as an open question. Reassess fielded images against current analysis techniques rather than trusting that a past review still holds, and work to shorten the whole finding-to-fix-to-deployment cycle, because the discovery side of that cycle just got shorter without you. Build the reporting and coordinated-disclosure practice the CRA expects in the same motion.

The Finite State Platform reads the compiled firmware, not just the manifest, and ranks what it finds by what an attacker could actually reach, so your team reviews the findings that matter instead of every candidate.

Every sufficiently complex device has bugs; we saw the same pattern in a 20-year-old flaw still shipping in a 2026 home camera. What has changed is the clock. The manufacturers that come through the next incident well will be the ones that can see their own firmware the way an attacker now can, and fix it faster than an attacker can use it. Bring us a firmware image you already shipped, and see what a blind analysis finds in it.

Finite State is a firmware security company, not the incident responder for this event. We have no visibility into who carried out the attack or what exploitation looks like in the wild, and our analysis does not draw on threat intelligence we don't have. This post is general information, not a substitute for guidance from your vendor or national authorities.