Hi, I work at IPinfo (former journalist here), and today I ran a few numbers and updates on the supermarket fridge situation. Mostly because of the news that supermarkets in four other European countries reported attacks on their refrigeration. These attacks were in stores in Belgium, Sweden and Estonia, and also in some stores in Portugal.

So I gave it a go. Our weekly Internet scans count Danfoss refrigeration dashboards that are open to anyone.

France, hit on October 11–12, took most of its offline: 1,331 on October 6–7, 149 on October 27.

The countries hit today didn’t move as much, given they hadn’t been attacked before. Between the same dates, Belgium went from 85 to 51 and Sweden from 73 to 64. Portugal dropped from 92 to 37. In Estonia, 3 of the 4 still online were an older model Danfoss no longer updates, but we don’t see many there.

So even after France made the news (maybe no surprise), many of these exposed systems in the countries hit next stayed online for weeks. Also, the counts are IP addresses on the ports we scan, so they’re a minimum (keep that in mind).

More detail (from a couple of week and regarding France and Europe): https://ipinfo.io/blog/france-fridges-hack

And today’s update with the chart: https://x.com/emot/status/2117232166262251810

I work at IPinfo, which runs weekly scans of the IPv4 Internet. After the October 11–12 attack that pushed refrigeration in hundreds of French supermarkets into defrost, we went back through those scans to count Danfoss StoreView dashboards, the web front end for the AK-SM controllers named in the reports.

What the October 6–7 scan found:

• 2,528 addresses with a StoreView dashboard, in 73 countries and territories
• France: 1,331 (53%), more than everywhere else combined. Then Poland 179, US 101, Portugal 92, Belgium 85
• 85% of the French ones ran software with known flaws: 527 end-of-life AK-SM 800 units, 280 missing the 2023 fixes, 329 missing the 2025 fixes. Only 195 had every fix. The rest of the world was about the same (84%), so France had more of them online, not worse patching
• 98% sat on telecom networks, not in data centers. That fits a controller on the store’s own line, opened up for a technician or head office
• Not new: 1,019 of the French addresses were already open on March 30

After the attack, the October 14 scan found 316 of the 1,331 French dashboards still online, a 76% drop against a normal 3–7% a week. Fully patched units dropped too (195 → 54), so stores disconnected rather than patched. Censys saw a similar 71% drop.

Method: the newer UI is matched on page title, the older AK-SM 800 on its web server plus the Flash loader page, and the firmware generation comes from the build date the dashboard shows. Counts are addresses on the ports we scan, so they’re a floor. AK-SC 355 units may be missing. We removed 16 non-Danfoss devices that share the old web server, and two honeypot-like hosts.

What we can’t say is how the attackers got in. Exposure isn’t proof that this was the way in.

Full write-up with charts: https://ipinfo.io/blog/france-fridges-hack

Author here, I work at IPinfo. some security-relevant highlights part of the post:

• The August 28 Virtualizor update attack used a forged-origin /24 inside Hetzner’s space. From what we saw, it was RPKI-valid because Hetzner’s ROA covered the /16 and allowed announcements down to /24, and no real /24 existed to compete with it.
• We also measured how common that setup is. In this case, of 855,217 RPKI-covered IPv4 routes, 138,698 (16.2%) have a ROA looser than the route announced and no more-specific route of their own filling the gap. For IPv6 it’s 20.9%. That’s roughly 18 million more-specifics someone could announce today and come out RPKI-valid and uncontested.
• Hosting providers also differ a lot: Contabo leaves 540 of 553 covered routes open, DigitalOcean 780 of 863, OVH 11.5%.
• Invalid routes are being dropped now: a typical valid route is seen by 596 vantage points, an invalid one by 2. So the remaining risk is routes that pass the check, not ones that fail it.
• There's also the fix in RFC 9319: leave maxLength unset, so a ROA only matches the block you actually announce.

Method is at the end of the post. Happy to answer questions