Who left the fridge open to the internet?

If you’ve been anywhere near a news feed this week, you’ve seen the headlines about hackers cooking French supermarket fridges to 122°F overnight. Food spoiled, a handful of stores dealt with fires or sprinklers soaking the aisles, the Paris prosecutor opened a case, and the CEO of Coopérative U called the whole thing unprecedented. Les Mousquetaires alone is talking about several million euros in losses.

Some of that reaction is earned. Hundreds of stores dumping their fresh and frozen inventory in a single morning is a real hit, and anything that touches the food supply is going to get political attention fast.

Having read through the reporting and the early technical write-ups, though, the attack itself looks a lot less exotic than the coverage suggests. It’s the same internet-exposed device problem we’ve been complaining about for over a decade, and this time the outcome happens to photograph really well. A dumpster full of thawed frozen food does a hell of a lot more for a news cycle than a CVE number ever will.

What actually happened: an old IoT device security problem

The devices that got hit are the supervisory controllers grocery stores use to run every case, freezer and cold room in the building from one panel, which is a long way from the smart fridge in your kitchen. The first wave hit Danfoss AK-SM and AK-SC units, and by Tuesday the French government’s advisory (CERTFR-2026-ALE-012) had added Copeland and Dixell XWEB systems to the list.

These boxes exist so a refrigeration contractor can log in remotely, adjust setpoints and check alarms without rolling a truck to every store. That’s a perfectly reasonable business need. The trouble is how a lot of them were being reached.

Researchers have been finding these controllers sitting directly on the public internet for a while now. Claroty’s Team82 published research on the Danfoss AK-SM 800A back in August (and talked about it at DEF CON), and their scan turned up roughly 2,765 exposed units. France reportedly hosts close to 60% of the internet-facing Danfoss controllers out there, which goes a long way toward explaining why France is the country in the headlines.

That same research found a hidden login on the 800A that accepts a code generated from the current date (CVE-2025-41450, fixed in R4.2). That’s where the “the password is just today’s date” posts you may have seen came from. However, the reality is uglier than a weak password, because a strong admin password wouldn’t have kept anyone out and there was nothing an operator could change to close it short of updating firmware.

Danfoss says most of the compromised units were legacy models running outdated firmware, some of them end-of-life for years, with known vulnerabilities dating back to 2023. Some were hanging off 3G cards for remote monitoring, and the attackers reportedly found them with Shodan. What nobody has confirmed yet is how they actually got in; the date-code backdoor, a different bug, or plain default credentials are all still on the table, so take anyone claiming to know the exact exploit chain with a grain of salt for now.
Once they were in, the attackers didn’t need malware. They used the controllers’ own features: forced the units into a continuous defrost cycle with a 50°C target, and in some freezers and cold rooms stretched the defrost window from one hour to eight, which Le Monde reported was about delaying the alarms that would normally go off. Whoever did this understood how refrigeration supervision works and used the system exactly as designed, just with bad intentions. As of this writing, nobody has claimed responsibility.

The real IoT device security message under the hype

Strip off the “hackers are coming for your groceries” framing and what’s left should feel uncomfortably familiar to anyone who’s spent time on the defensive side.

Ask who owns the refrigeration controller in a supermarket and the honest answer is usually facilities, or more realistically the refrigeration service contractor facilities hired years ago. That box may not appear in any inventory the security team looks at, and when regulatory bodies and others talk about response, accurate equipment inventories and clear lines of responsibility between retailers, manufacturers and maintenance companies are right at the top of the list. If you can’t say what’s on your network, what it is, and what it talks to, you’ll find out about the exposed controller when somebody else finds it first.

Once you know the box exists, the next question is how outsiders get to it, and the usual answer is the lazy one. The contractor needs to get in, so somebody opened a port or bolted a cellular modem onto the panel, and that was the end of the conversation. The French government put it pretty bluntly this week: exposing a management interface to the internet is contrary to best practice, and if remote admin is truly necessary it should be locked to trusted IP addresses. I’d push that further. Vendor access should be tied to a named person, authenticated, granted for the session they actually need, and logged, and the rest of the time the controller shouldn’t be reachable from outside at all. The date-code backdoor makes the case better than I can: when you can’t trust the device’s own login, the control that really matters is who can reach it in the first place.

Even with access locked down, detection has its own headache here, because every action in this attack was a valid command. No signature fires on “run defrost,” because running defrost is what the thing does several times a day. What would have caught it is knowing what normal looks like for that device: who logs into it, from where, and when. A controller that gets touched a couple times a month by one contractor suddenly taking new logins at 2 a.m., across hundreds of stores at once, is about as loud as an anomaly gets, provided anyone is watching.

IoT device security was never a grocery problem

If you’re reading this from an office, a hospital, a school or a data center and thinking you dodged one, look around. Every building has its own version of this: HVAC and building management, badge readers, cameras, UPS units, the environmental sensors facilities installed without telling anyone. Most of it was bought by somebody outside security, installed by a third party, and set up for that third party’s convenience. A lot of it is running firmware nobody has looked at since the install date.

I’ll also be honest about where network-side controls run out. A panel with its own 3G modem never touches your network, so nothing you run on your network is going to see it, much less block it. The only fix there is policy and legwork: asking your vendors the question directly, and having someone physically check what’s hanging off the equipment. It isn’t glamorous, but it’s the gap the attackers drove through in at least some of these stores.

I’ve run into this exact thing. Years ago I took an operational role where the job was to build out a security program, and a big piece of that was asset discovery, especially on the companies we were acquiring. Every acquisition got a sweep, and every sweep turned up something nobody had on a list, sometimes a single forgotten appliance and sometimes an entire rack. Nobody was hiding anything; gear just has a way of outliving the people who remember installing it.

On one of those sweeps we’d already thrown everything we had at the network. Standard discovery scans came up clean, and so did the deeper recon tricks, like pulling ARP neighbor tables off the switches to catch anything too quiet to answer an active scan. Then someone on a site visit stuck their head into a server closet, spotted a small box with an antenna tucked on top of a cabinet, and asked the question you never want to hear on a site visit: “What’s this?”

It was a cellular remote access unit, put in years earlier for a vendor or project nobody could name anymore and never decommissioned. It wasn’t in any asset record, it never touched anything our scans could see, and for all we knew it had been sitting on a live connection to the outside world the entire time. Every tool we had said that site was covered, and what actually found the hole was a guy opening a closet door.

What I’d actually do this week to tighten IoT device security

Run your own public IP space through Shodan or Censys today, because the attackers already did, and anything with a management login on it that isn’t supposed to be there gets pulled. After that, go find every IoT and OT device on your internal network and figure out what it is and who owns it, which is harder than it sounds when half of them identify themselves as “Linux device” and nothing else.

Once you know what you have, put those devices somewhere they can only talk to what they need. A refrigeration controller needs to reach its head-end and its vendor’s access path, and it has no business being reachable from the guest Wi-Fi or a random laptop on the corporate VLAN. Swap “open port for the contractor” for access that’s granted per person and per session, and ask every facilities vendor, in writing, whether any of their equipment carries a cellular modem. Patch or retire the end-of-life gear, and if you can’t do either, wrap it tightly enough that it doesn’t matter.

This is the corner of security I spend most of my days in: knowing what’s actually plugged in, fingerprinting a device well enough to tell a refrigeration controller from a printer, and making network access depend on what a thing is and who’s asking rather than which port it happens to be connected to. None of that would have made the French attack impossible on its own, but it shrinks the target list a lot, and it means the 2 a.m. logins show up somewhere a human will see them.

Somewhere in your environment there’s a contractor with a login to a box you’ve never heard of. Better you find it before somebody with Shodan and a grudge does.