# The Fridges Were Working Fine: Why You Need a Technology Inventory
> Fridges across Europe were tampered with remotely. Why every business needs a technology inventory and an update policy.

*4 November 2026* · Jamie Taylor


The cover image for this post is by [Brittani Burns](https://unsplash.com/@brittaniburns) on [Unsplash](https://unsplash.com/photos/grayscale-photo-of-glass-window-LNBXK6AUs3w)


> [!IMPORTANT] An evolving situation
> This post was written on Wednesday, November 4th, 2026, and its sources were last checked at 11:30 GMT that day. Investigations into the refrigeration incidents are still going on in several countries, and no authority has yet confirmed how the attackers got in across all of them; France's early assessment is covered below. This post will be updated, with dated notes, if anything material changes. Before acting on any detail here, check the linked sources for anything newer.

Somewhere in the back of most supermarkets there's a small box on a wall that nobody in the shop ever thinks about. It's a refrigeration controller: it keeps the chillers and freezers at the right temperature, runs the defrost cycles that stop ice building up inside them, and raises an alarm if anything drifts. It was probably fitted by a refrigeration contractor when the cabinets went in, and connected to the internet so that the contractor's engineers could check on it without driving out. Then, because it worked, everybody forgot about it.

Every business has its own version of that box, whether or not it thinks of itself as a technology business. The door entry system, the CCTV recorder and the heating controls that the building management company looks after are all examples; so are the phone system, the router the internet provider fitted years ago, and the website an agency built and handed over. Each was bought to do a job, each still does it, and very few of them have a name next to them on anyone's list of responsibilities.

> We are horrified to discover that most people do not actually care how healthy a piece of technology is as long as it performs the function they need it to with a reasonable degree of accuracy in a timeframe that doesn't exhaust their patience. In technology, "good enough" reigns supreme.
>
> — Marianne Bellotti, [Kill It With Fire: Managing Aging Computer Systems](https://app.thestorygraph.com/books/3adfa207-a857-4e9f-b607-05bf56b9e696)


Marianne Bellotti wrote that about software, in a book I've [written about before](/blog/continual-professional-development/kill-it-with-fire-lessons-from-legacy-systems-for-modern-leaders/), and it applies just as well to the box on the wall. "Good enough" is a perfectly reasonable test of whether something works. It's a poor test of whether it's safe, because the two can drift apart for years without anyone noticing, and October and November showed how far apart they had drifted.

## What Happened in October and November


Overnight on October 11th to 12th, 2026, hundreds of French supermarkets found that their chilled and frozen equipment had been tampered with remotely: defrost cycles forced on, and temperatures raised, through the controllers' own management pages. France's Economy Minister, Roland Lescure, told Parliament that "approximately 700 stores had been affected", according to [SentinelLABS](https://www.sentinelone.com/labs/defrost-and-disrupt-an-assessment-of-europe-s-refrigeration-attacks/). France's national computer emergency response team, CERT-FR, published [an alert](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-012/) the same day, naming controllers from Danfoss and from Copeland and its Dixell brand.

The cost of that kind of tampering is mostly food. In England, Wales and Northern Ireland, chilled food must legally be kept at 8°C or below, and [the government's guidance](https://www.gov.uk/food-hygiene-businesses/chilling-and-freezing) recommends setting fridges to 5°C or lower; France has its own equivalent rules. Once a cabinet has been warm for hours, a shop can't show that the food in it stayed safe, so it goes in the bin. A spokesperson for Les Mousquetaires, which owns Intermarché and Netto, told [Reuters](https://www.timeslive.co.za/news/world/2026-10-12-hackers-heat-french-supermarket-fridges-sparking-fires-and-food-losses/) that the group "had thrown all the food away to avoid any sanitary risks".

A second wave followed on Monday, November 2nd, 2026, across Belgium, Estonia, Germany, Ireland, Italy, Luxembourg, the Netherlands, Portugal and Sweden. According to [CNBC](https://www.cnbc.com/2026/11/02/cyberattack-on-fridges-hits-supermarkets-across-europe.html), Musgrave said 13 of its SuperValu stores in Ireland were affected, adding that "our monitoring systems alerted us to the issue and we took immediate action". Colruyt Group said five shops had their fridge systems attacked, and the Swedish grocer ICA said a "limited number of stores" were affected.

The UK was touched too, though lightly. [The Grocer](https://www.thegrocer.co.uk/news/meat-suppliers-hacked-in-latest-round-of-fridge-cyberattacks/725432.article) reported that several meat suppliers found their fridges had been changed overnight: one supplier's set to defrost every hour, another's set to 100°F, about 38°C. The fridges ran Dixell's XWEB software, and the Association of Independent Meat Suppliers urged its members to check their own as a "matter of urgency". Alex Pearce of Langridge Organic told [The Record](https://therecord.media/british-businesses-caught-in-europe-wide-supermarket-fridge-attacks) that he was "pretty sure that I interrupted a live hacking event".

On November 3rd, 2026, the National Cyber Security Centre's (NCSC) Director of Operations, Paul Chichester, described the UK impact so far as "minimal", and said the first-wave attacks used vulnerabilities that "absolutely have been out there for a long period of time", [according to The Record](https://therecord.media/british-businesses-caught-in-europe-wide-supermarket-fridge-attacks). The NCSC's Chief Technology Officer, Ollie Whitehouse, added that staff had been "surprised to see some of these things being connected to the internet still in 2026."

Two things aren't known yet, and I don't want to guess at either. The first is how the attackers got in. Security researchers had published flaws in Danfoss's controllers, and early reporting assumed those were used. But on October 21st, 2026, the director of ANSSI, France's national cybersecurity agency, told the French Senate that "those vulnerabilities were not the ones exploited", and pointed instead to "exposed administration and weak passwords", according to SentinelLABS. That doesn't necessarily contradict Chichester: a management page left on the internet behind a weak password is a long-standing vulnerability too. Whether the same is true of the November incidents isn't yet known. The second is who did it. Nobody has claimed responsibility, no government has attributed the attacks, and a spokesperson for Belgium's cybersecurity agency [told The Record](https://therecord.media/british-businesses-caught-in-europe-wide-supermarket-fridge-attacks) that "it may never be possible to identify" the people behind them. For any business reading this, the how matters more than the who, and so far the how looks ordinary.

## The Fixes Already Existed


Every flaw that researchers had found in these controllers was published, with a fix, months before the first wave:

| Controller | Flaw published | Fixed in | Time before October 11th |
| --- | --- | --- | --- |
| Danfoss AK-SM 800A series | [May 8th, 2025](https://nvd.nist.gov/vuln/detail/CVE-2025-41450) (a way to bypass the login) | Version 4.2 | About 17 months |
| Danfoss AK-SM 800A series | [August 22nd, 2025](https://nvd.nist.gov/vuln/detail/CVE-2025-41451) (two further flaws) | Version 4.3.1 | Almost 14 months |
| Copeland XWEB Pro | [February 26th, 2026](https://www.cisa.gov/news-events/ics-advisories/icsa-26-057-10) (23 flaws, including a login bypass) | A fix was available at publication | About 7.5 months |

Some controllers will never receive a fix at all, because their manufacturers stopped supporting them years ago. CERT-FR's alert singles these out: it warns that end-of-life equipment, with no security fixes, carries a very high risk of compromise if it can be reached from the internet. Danfoss [told Reuters](https://www.timeslive.co.za/news/world/2026-10-12-hackers-heat-french-supermarket-fridges-sparking-fires-and-food-losses/) that the affected units "were running outdated firmware", and that it had "long advised customers to keep supported systems updated with the latest firmware and to migrate legacy systems to current-generation solutions."

On October 22nd, 2026, researchers at Forescout [reported](https://hackread.com/refrigeration-controls-exposed-online-99-countries/) finding 12,976 refrigeration services exposed to the internet across 99 countries, and that about 80% of the Danfoss management services they could see were running firmware older than 4.3.1. Those figures count services visible on the internet, not individual devices, so they aren't a precise count of vulnerable fridges; they do show how much of this kit is still online and out of date.

If ANSSI is right, the attackers in France didn't even need those flaws. A management page on the internet and a weak or default password was enough, which is why CERT-FR's advice includes making sure that default passwords have been changed. Whichever door was used, the common factor is the same: equipment that was connected, out of date, and not being watched by anyone. That makes this a question of ownership and upkeep, which is good news, because ownership and upkeep are things every business can do something about.

## The Same Pattern in Web Software


Fridges aren't special here. In late October, I wrote about [php2shell and the Brotli flaw](/blog/who-is-patching-your-software-why-a-support-contract-matters/) (CVE-2026-111497, nicknamed both HTTP2Shell and Node2Shell), serious flaws in PHP and in a compression library used by Node.js, .NET and many other platforms, and the same pattern showed up there.

[Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities), a security company, looked at 156 million PHP installations with a known version across more than 10,000 of its customers, and found 110 million of them (71%) running PHP 5.4 to 8.1: versions the PHP project no longer supports, so none of them will receive an official release with the fix. For Node.js, Qualys [summarised](https://blog.qualys.com/product-tech/2026/10/23/node-js-patches-brotli-remote-code-execution-flaw-find-vulnerable-runtimes-before-attackers-do) its findings bluntly: "nine in 10 Node.js installations are either unpatched or on lines that will never receive these fixes." Those numbers come from businesses that already pay for security scanning, so I'd be surprised if the wider picture were any better.

Two dates are close enough to plan for now. [.NET 8 and .NET 9](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/) leave support on November 10th, 2026, and [PHP 8.2](https://www.php.net/supported-versions.php) stops receiving security fixes on December 31st, 2026. If either is running anywhere in your business, the time to plan its upgrade is before those dates arrive.

## Who Owns the Fridge?


Ask most businesses who updates their refrigeration controller, or their door entry system, and the answer is a chain of reasonable assumptions. IT assumes facilities looks after it, because facilities bought it. Facilities assumes the contractor does, because the contractor installed it. The contractor maintains the equipment under an agreement that says nothing about software updates, because nobody thought to ask. Each of them is right about their own part, and nobody is responsible for the whole.

CERT-FR's alert advises operators to check the terms of their insurance contract before cutting a controller's connection to the refrigeration contractor. The equipment in those stores was sending data to someone outside the business, and cutting that link could affect the business's insurance; the national cybersecurity agency had to remind operators to check before they acted.

If you lead a technology team, it's tempting to read all this as a supermarket problem, or a facilities problem. I'd gently suggest it's more likely to be yours than you think. An asset register usually lists what IT bought. The things that facilities, operations, a landlord or a supplier connected, sometimes through their own internet connection in your building, often aren't on it; the vulnerability scanner only sees what it's pointed at; and nobody is watching advisories for a product nobody knows you own.

Even on the systems a scanner does see, it can only report what the advisories tell it to look for, and a vendor's advisory lists the versions that vendor still supports. When Microsoft fixed HTTP2Shell in .NET in October, its advisory covered .NET 8, 9 and 10. As I explained in [a short episode of The Modern .NET Show](https://dotnetcore.show/season-9/the-october-2026-brotli-security-update-who-it-affects/), I read the source code for the final release of every version from .NET Core 3.0 to .NET 7, and every one of them ships a version of the Brotli library that Google lists as affected. Those versions are out of support, so there's no fix for them, and a scanner working from Microsoft's advisory has no reason to flag them. Only applications that decompress Brotli data from outside the application are exposed, which isn't the default, so the first step for anyone on those versions is to check whether their code does that at all. The same thing happened last year with the ["Funky Chunks" vulnerability](/blog/cve-2025-55315-understanding-funky-chunks-and-why-your-organisation-needs-to-act-now/). A clean scan report means that nothing the scanner knew to look for was found; for anything past its end-of-support date, that tells you very little.

Remote access is the other blind spot. There are real, public cases of a contractor's login being stolen or leaked and then used to reach a client's systems. [Target's 2013 breach](https://krebsonsecurity.com/2014/02/email-attack-on-vendor-set-up-breach-at-target/) is one well-documented example among many: the attackers stole the credentials Target had issued to a contractor, whose access was meant only for billing and project management. Cases like it aren't hard to find, and they're worth reading if you've ever given a supplier a way in.

## Start With a Technology Inventory


The fix starts with a list. It sounds unglamorous, and it is, but everything else depends on it. Even the NCSC's Cyber Essentials scheme, which focuses on five specific technical controls, makes the same point in [its requirements](https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf):

> Asset management isn't a specific Cyber Essentials control, but effective asset management can help meet all five controls, so it should be considered as a core security function.
>
> — NCSC, Cyber Essentials: Requirements for IT Infrastructure v3.3, https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf, accessed November 4th, 2026


For each thing your business runs that's connected to a network, whether it's software, a device, or a service someone else hosts, it helps to record:

- ✅ **What it is and where it is.** "The freezer controller in the back office at the Leeds site" is more useful than a model number on its own.
- ✅ **Who supplied it, and who maintains it.** A named person at a named company, with their contact details.
- ✅ **Whether it can be reached from the internet, and by whom.** Including any remote access you've given a supplier.
- ✅ **Which version it's running.** Whatever the manufacturer calls it: software version, firmware version, or release.
- ✅ **How it gets updated.** Automatically, during a contractor's visit, or by someone doing it by hand.
- ✅ **When the manufacturer stops providing fixes.** Cyber Essentials counts software as supported only when its vendor has committed to regular vulnerability fixes, and adds that "the vendor must provide the future date when they will stop providing these." If a supplier can't tell you that date, that is useful information in itself.

You don't need a perfect list on day one; a shared spreadsheet is a fine start. Begin with anything that can be reached from the internet, because that's what was hit in October and November. Then ask each of your suppliers one question: what have you connected on our premises or to our systems, and how do you keep it updated? For the software you build or commission yourself, a [software bill of materials](/blog/the-5-minute-investment-that-could-save-your-company-millions-a-developers-guide-to-sboms/) does the same job for every library and framework inside it.

## Update It, Even When It Works


An inventory tells you what you have. An update policy decides what happens to it, and it only works if someone enforces it; left to whoever has time, updates are the first thing to slip.

"It's still working" is the most common reason I hear for leaving something alone, and it answers a different question. Whether something works and whether it's [safe to keep running as it is](/blog/why-your-stable-software-is-a-ticking-time-bomb/) are separate things, and only one of them shows up on a normal working day. In practice, a policy means a few concrete commitments:

- ✅ A regular window for applying updates, monthly for most things, and a faster route for anything the manufacturer marks as critical.
- ✅ For equipment that can only be updated by hand or by a contractor's visit, those visits scheduled, and firmware updates written into the maintenance agreement.
- ✅ For anything past its end-of-support date, a replacement plan with a date and a budget; until then, take it off the public internet. CERT-FR's advice for the controllers was to remove their internet exposure entirely, and to allow access only through a secure virtual private network (VPN) or a protected network.
- ✅ For the larger upgrades, such as moving to a new version of a framework, a plan that's [worked out before anyone starts](/blog/why-upgrade-and-pray-cost-my-client-140-engineering-days-and-how-to-avoid-it/), so that it doesn't turn into weeks of rework.

None of this replaces security testing, but a yearly test won't help with the box nobody listed. As I've argued before, [security can't be the last step](/blog/stop-treating-pentests-like-final-exams-why-security-cant-be-your-last-step/); it has to be part of how the business looks after what it owns.

## Who Does the Work


Once you know what needs updating, someone has to do it, and there are two routes.

The first is your own engineers, if you have them. That usually means reprioritising: pausing some feature work so that upgrades get done. It's a business decision, and it needs to be made by leadership, so that engineers aren't left choosing between the roadmap they're measured on and the patching nobody asked them for. The second is an external team under a [support contract](/blog/who-is-patching-your-software-why-a-support-contract-matters/), someone whose job includes watching for advisories, keeping your inventory current, and doing the work when a fix is published. Many businesses end up with a mix: their own team for the systems they know well, and outside help for the rest.

Over the past year, several of my clients turned out to be vulnerable to the same request smuggling flaw I described in the support contract post, CVE-2025-55315. All of those fixes are covered by non-disclosure agreements, because very few businesses want it known that they were exposed to a publicly disclosed flaw. That's understandable, and it's one reason the fridge attacks are worth learning from: they're public, and they happened to someone else.

Since HTTP2Shell was disclosed, I've been contacting former clients whose systems I built on the affected technology. Each of them has two options: my team builds the fix, or I lay out a plan that their own engineers can carry out internally. Either way, the aim is to fix it with as little downtime as possible. That work is still going on.

## Questions to Ask This Week


You don't need to understand the technology to ask these, and you don't need all the answers straight away:

- ✅ What do we have that's connected to the internet, including things we didn't buy ourselves?
- ✅ For each of those, who updates it, and when did they last do it?
- ✅ Which suppliers can reach our systems or equipment remotely, and how?
- ✅ What's past its end-of-support date, or will be within the next year?
- ✅ Who decides when updates and replacements happen, and whose budget pays for them?

> [!THOUGHT]
> If your refrigeration contractor, alarm company or IT supplier rang tomorrow to say that a device of theirs on your premises needed an urgent update, would you know which device they meant?

## Know What You Have


The fridges in October and November were working fine, right up until someone else changed their settings. The businesses affected weren't careless; most of them were relying, reasonably, on a chain of people who each assumed someone else had it covered. Nobody needs to become an expert in refrigeration firmware to fix that. What it takes is knowing what you have, who looks after each part of it, and when each part stops being supported, and then making sure the updates actually happen.

If you'd like help building that first inventory, or deciding which of the work your own team should take on and which needs outside help, [I'd be happy to talk it through](/schedule-consultation).