Update — November 2026: It happened again. A second wave of refrigeration attacks hit supermarkets across Sweden, Belgium, Ireland, Finland and Estonia — same vendor, weeks later. Read Part 2 →
In October 2026, refrigeration units across more than 300 French supermarkets — Intermarché, Netto, Coopérative U, Carrefour and others — warmed to around 50°C overnight. Aisles of spoiled food greeted staff the next morning. In several stores, the overheated units caught fire. Intermarché’s CEO estimated the damage in the tens of millions of euros, and the attack reportedly spilled over into Spain, Portugal, Germany, Poland and Belgium.
Writing in the Financial Times, security researcher Tarah Wheeler summed up the lesson in one line: security through obscurity is not a good cyber defence. (Financial Times — Tarah Wheeler)
But there’s a second lesson underneath it, and it’s the one that should keep every IT and security leader awake: this was not a sophisticated zero-day. The affected Danfoss refrigeration controllers had a known vulnerability. The vendor had flagged it and shipped a software update roughly 18 months before the attack. The update simply was never applied.
The window between “patch available” and “actively exploited” is collapsing
Wheeler makes a point we see confirmed every week: the time between a weakness becoming known and it being turned into a working exploit is shrinking from years to days — accelerated now by AI, which can chain together exploits against well-known flaws faster than human attackers ever could. The same week as the supermarket hack, millions of websites briefly went dark over a vulnerability in PHP, a decades-old language still running critical business systems everywhere.
The uncomfortable truth is that most damaging breaches don’t come from exotic new attacks. They come from old, known, already-patchable vulnerabilities that nobody got around to remediating. The patch existed. The exposure was optional.
So why do patches sit unused for 18 months?
Not negligence — scale and complexity. The organizations most at risk run:
- Thousands of systems across dozens of operating systems — Windows, a dozen Linux distributions, and legacy Unix like Solaris and AIX that still underpin energy, finance and government.
- Hundreds of distributed sites — stores, branches, plants — each with its own back-office servers, gateways and connected equipment.
- Segmented, DMZ and air-gapped networks, where opening a firewall rule for every endpoint is a project in itself.
- OT-adjacent environments, where the embedded controllers rely on a surrounding layer of IT infrastructure — and that layer is usually where attackers actually get in.
Patching one server is trivial. Patching all of them, in the right order, across isolated networks, without downtime, and proving it to an auditor — that’s the problem that lets an 18-month-old fix fall through the cracks.
Closing the gap at scale
This is the problem JetPatch is built for. From a single console, JetPatch automates patch orchestration across 20+ operating systems, prioritizes by real CVE risk and business impact, sequences rollouts from test to production, validates results and rolls back failures automatically.
For the distributed and isolated environments that mirror the French supermarket scenario, the key is architecture. JetPatch’s JetProxy gateway lets one console reach and patch endpoints across remote sites, DMZs, hybrid cloud, and segmented networks — without per-device firewall exceptions to the internet. For the most sensitive zones, JetPatch supports patching isolated and air-gapped networks directly. The result: when a vendor ships a fix, it reaches every affected system in days — not never.
But could JetPatch patch the fridge controller itself?
It’s a fair question, and the honest answer sharpens what patch management can and can’t do. JetPatch applies fixes through mechanisms a general-purpose server understands — a lightweight agent, or agentless access over SSH and WinRM, pulling signed, catalogued packages from Windows Update, WSUS and the Linux package managers. An embedded refrigeration controller has none of that: no agent, no shell, no package format, and often no IP path at all — just vendor-signed firmware flashed over a fieldbus through the manufacturer’s own tool. Putting the update file on a gateway was never the hard part; a trusted way to execute it on the device is — and for most OT controllers that path simply doesn’t exist today.
That’s why the durable win is the layer around the controller: the HMIs, engineering workstations, historians, jump hosts and DMZ servers an attacker actually pivots through. Those are standard IT, and they are continuously patchable with JetPatch — which is exactly where the French supermarket intrusion lived.
Where an organization does need to push firmware into a segmented zone, JetPatch can orchestrate the job rather than replace the vendor. Its Self-Packager wraps the manufacturer’s update utility into a managed task, runs it from a host that can reach the device, and uses JetProxy to deliver the firmware image into an air-gapped segment with no internet exposure — all wrapped in the scheduling, approval and compliance reporting that OT change windows demand. JetPatch drives the host and the vendor’s tool, under governance; it does not re-sign or replace the manufacturer’s firmware. The bytes are easy — the control, the timing and the proof are the point.
The takeaway
The French supermarket fires weren’t caused by a brilliant hacker. They were caused by a patch that existed and wasn’t applied — while the window to apply it quietly shrank from months to days. Obscurity didn’t save those stores, and it won’t save anyone else.
Patch hygiene, done automatically and at scale, is no longer back-office housekeeping. It’s fire prevention.
See how JetPatch automates patching across your entire estate — including segmented and air-gapped networks. Request a demo →
