From Freezer Hacks to Developer Compromise: Ordinary Weaknesses, Extraordinary Consequences

Executive Summary

Nobody has proven a shared attacker behind three incidents from the last four weeks, but they follow a pattern every product security team should take personally, especially now that Cyber Resilience Act reporting puts a 24-hour clock on exploited vulnerabilities.

Start with the supermarkets. Attackers used internet-exposed refrigeration controllers, many years past end of support, to push freezers towards 50°C across roughly 700 French stores. Three weeks later it happened again: according to SecurityWeek, over 100 stores in at least six European countries were hit overnight into 2 November.

Then Binance. A developer ran a coding assignment from a fake job interview, and that one machine became the first hop to a wallet-signing service. Binance’s 3 November report says approximately USD 6.34 billion in digital assets were impacted. Separately, a tampered “Claude Code”-branded extension in Cursor’s marketplace tried to plant an SSH backdoor on every developer machine that pulled the update.

None of these needed a novel exploit. Each started with an ordinary access path (an exposed web interface, a laptop, an IDE extension) and ended with extraordinary authority: store-wide control of refrigeration, signing rights over hot wallets, persistent shell access to developer workstations. Low-hanging fruit, here, means avoidable exposure and excessive permission. It has nothing to do with CVSS scores or attacker skill. The crews in these three cases were patient and well resourced.

The question to ask of any asset is what someone controlling it can make the organisation do. Under the Cyber Resilience Act, whose reporting duties have applied since 11 September 2026, that question now has a 24-hour clock on it for anyone who makes and sells software or connected products into the EU. This article walks through the three incidents, explains why containment means revoking authority, sets out what the CRA does and does not require, and shows how we run the 24-hour response in Phoenix Orange.

Key Takeaways

• The October and November refrigeration attacks hit internet-exposed controllers, mostly on unsupported firmware. No CVE has been officially tied to them, and nobody has published which weakness, if any, was used.
• Binance’s report traces the theft to a fake recruitment process, a malicious coding assignment, lateral movement through an internal AI tool, a stolen container deployment token and access to the wallet-signing service. The FBI attributes it to North Korea.
• Stopping the visible action did not stop the attack. Pausing withdrawals left malicious on-chain authorisations live, and CERT-FR warns that a factory reset leaves an exposed end-of-life controller ready to be compromised again. Containment means revoking authority.
• ENISA has confirmed that CRA reporting covers end-of-life products still in use, while the duty to ship fixes covers only the support period. Nobody has to patch a 2016 controller. Someone may still have to report its exploitation within 24 hours.
• The CRA trigger is active exploitation, and severity scores move. On the day, an exception register with a signed exploitability position per component is worth more than a raw SBOM.

The Problem

Incident 1: supermarket refrigeration, two waves

Overnight on 11 to 12 October 2026, attackers reached remote refrigeration controllers in French supermarkets and forced units into defrost, some of them reaching 50°C. The Paris prosecutor’s office told Recorded Future News it had received about ten complaints and put the number of victims at around 700. Finance Minister Roland Lescure gave Parliament the same figure: about 700 of the country’s 10,000 supermarkets.

Intermarché, Carrefour, Monoprix, E.Leclerc and Coopérative U all confirmed stores were hit. Groupement Mousquetaires told AP that 300 of its Intermarché and Netto stores were affected. Carrefour counted 80, and Coopérative U’s chief executive said 80 of its 2,000.

CERT-FR published alert CERTFR-2026-ALE-012 on 12 October, naming Danfoss AK-SM and AK-SC series controllers. On 13 October it added Copeland xweb and Dixell xweb, and on 16 October it updated its recommendations. The alert says exposing a management interface to the internet goes against good practice, and warns that attack campaigns are probably still under way.

The second wave came overnight on 1 to 2 November. More than 50 stores were identified in Belgium, with others in Sweden, Ireland, Estonia, the Netherlands and Luxembourg. In Belgium:

• Delhaize told The Register it had identified an IT incident affecting the refrigeration systems in several dozen of its stores. Belgian outlets VRT and Le Soir put the number at about 40.
• Carrefour Belgium counted 15 of more than 700. Spokesperson Mich Vergauwen told Euronews “It’s a cyberattack, there is no other reason” and said the impact was very limited.
• Colruyt said five franchised Spar shops were hit.

Elsewhere, Musgrave confirmed 13 of its 223 SuperValu stores in Ireland. Stephan Moelans, chief executive of the refrigeration installer Sabcobel, which runs Delhaize’s systems, told Belga the mechanism was exactly the same as in France. He said he knew of about twenty affected units among the hundreds Sabcobel manages. In Sweden, ICA spokesperson Gustaf Nilsson told the TT news agency that a limited number of stores were affected. ICA did not confirm a cyberattack. It said the affected stores used an outside supplier connected to a network outside ICA’s central one, and told AFP those stores ran a Danfoss refrigeration control system.

The same night, someone used a refrigeration provider to tamper with the cold-room supervision and control systems at three regional sites of France’s blood service, the Établissement français du sang (EFS). EFS said temperature and defrost thresholds were pushed to very high values. Monitoring and fast intervention meant no blood products were lost, and no health impact has been identified.

Incident 2: one developer machine, one signing service

Binance’s report of 3 November describes a campaign built over months. It started in June, when a Wallet DevOps engineer looking for an AI coding tool installed a tampered copy of Homebrew. Binance caught that one, replaced the device and rotated credentials, but by then the engineer’s role and his wallet-team colleagues had been mapped.

In September the attackers came back through a different door. Posing as a project director, they approached a wallet software engineer on a legitimate job platform and ran him through interviews with a fake HR contact and a fake CEO. Then they asked him to download a coding assignment and set it up on his work machine. That assignment carried the malware. By 20 October they had pivoted through that machine and an internal AI tool to two more wallet engineers, picking up credentials and a container deployment token. On 29 October they deployed a container, ran a malicious script and reached the signing service, submitting 50 signing transactions to manipulate the account nonce and set up malicious EIP-7702 delegations.

About USD 2.85 billion has been frozen or intercepted. The FBI attributes the operation to North Korea, and researchers place it in the TraderTraitor and “Contagious Interview” tradecraft. Binance also says it detected and stopped 57 suspected North Korea-linked attacks during 2026, many using the same fake-interview and malicious-tooling approach.

We covered the signer side of this on 2 November in Binance $6.3B Hack: How a Compromised DevOps Laptop Reached the Hot-Wallet Signer (No CVE). The point from that analysis still stands: no key leaked and no CVE exists. The signer signed what a trusted caller asked for.

Incident 3: the IDE extension as a delivery channel

On 29 October, Cursor reported that tampered versions 2.1.312 and 2.1.313 of the anthropic.claude-code extension had been served from its marketplace. Its security notice gives the window as between about 2:27am and 1:35pm PT that day. Cursor first estimated at most 5,000 affected users and later dropped that figure.

Microsoft’s analysis found injected JavaScript that runs on module load and:

• collects host details and the names of environment variables matching KEY, TOKEN, SECRET and similar
• appends an attacker SSH key tagged svc-telemetry
• opens a reverse SSH tunnel
• writes startup persistence on macOS, Linux and Windows

Microsoft states the packages were never on the Visual Studio Marketplace or npm, and that Anthropic confirmed its systems were not compromised. Cursor reports that errors and permission requirements blocked SSH access on most macOS and Windows hosts, though the keys and persistence could still be written. Our technical breakdown is in Claude Code Extension 2.1.313 Backdoor.

This was a marketplace distribution incident. It is not evidence of an Anthropic compromise, and nothing links it to Binance. It belongs in this article because it has the same shape. An ordinary developer action, an automatic extension update, granted shell-level authority over the machine that holds kubeconfigs, cloud sessions and SSH keys.

Ordinary weaknesses, extraordinary consequences

The refrigeration attacks did not need a zero-day. Danfoss told AFP that most affected units were legacy controllers that no longer receive security updates: the AK-SM 800 (end of life since May 2021) and the AK-SC 355 (phased out in 2016). Danfoss also said some current AK-SM 800A units were running outdated firmware.

The weaknesses in this family have been public for years:

• In 2023, Synacktiv published an authentication bypass in the SM800 and SC255 System Managers. The check_code_of_day function derives a “code of the day” from the date alone, which an attacker can read without authenticating. Danfoss classed those models as end of life and advised restricting network access.
• In March 2025, Danfoss published DSA-2025-03-01 for CVE-2025-41450, an improper-authentication flaw in the AK-SM 8xxA series, fixed in version 4.2. CISA covers it in ICSA-25-140-03.
• In August 2025, release 4.3.1 fixed CVE-2025-41451, command injection through the alarm-to-mail SMTP password field, and CVE-2025-41452.
• In August 2026, Claroty Team82 showed how the hidden daily code and the command injection chain to remote code execution on the AK-SM 800A, and counted 2,765 exposed devices via Censys.

The incident evidence published so far does not establish which vulnerability, if any, the attackers used. Neither CERT-FR nor Danfoss has tied a CVE to the compromises, and Danfoss itself points at devices too old to receive the fixes. Treat the 2025 CVEs as patch hygiene for the AK-SM 800A. The confirmed root condition is exposure.

The exposure numbers below count reachable dashboards, not confirmed victims.

• IPinfo, 6 to 7 October (five days before the first wave): 1,331 publicly accessible Danfoss dashboards in France, more than the other 72 countries and territories combined. About 85% (1,136) appeared to run software with known flaws, including 527 older controllers Danfoss no longer supports. Only 195 had every known fix, and 1,019 had sat at the same address since 30 March.
• Predicta Lab: Baptiste Robert counted 2,752 reachable Danfoss systems, 1,590 in France.
• After the first wave, IPinfo found only 316 of the 1,331 French dashboards still online on 14 October. Censys recorded French StoreView exposure falling from 1,825 to 220.

This has happened before. Danfoss’s October 2025 newsletter, as reported by Recorded Future News, records attacks in 2022 on AK-SM 800 systems at 16 Russian supermarkets and 40 Israeli stores, none with an adequate firewall or VPN. On 26 February 2022, the operator of the Selyatino agro-hub near Moscow reported that someone had logged into its main Danfoss controller and created an “Anonymous” user with full rights. The intruder moved temperature setpoints from −24°C to +30°C to spoil 40,000 tonnes of frozen goods. That account comes from the victim company’s own letter and has not been independently verified.

Nobody has established who carried out the 2026 attacks. NoName057(16) and Z-Pentest posted claims on Telegram, then deleted both channels before anyone could verify them. At least one researcher suspects the groups claimed activity after analysts named them. Katrien Eggers of Belgium’s Centre for Cybersecurity said it is not known who is behind the attack and that it may never be determined. She added that over the past six months the CCB has seen a sharp rise in vulnerabilities found and exploited with AI. The CCB does not know whether AI was used here, and neither do I.

Put the three incidents side by side and they share a shape. The entry point was never a crown jewel: a back-room web page installed by a contractor, a candidate’s take-home test, an extension update. What sat behind each one was enormous authority. “How important is this device?” gets you the wrong answer every time. The question that works is “what can someone controlling it cause the organisation to do?”

Containment: revoke the authority, not the symptom

Binance paused withdrawals and shut down hot-wallet services. The outflow continued. In its own words, the malicious EIP-7702 authorisations “existed on-chain and operated independently of Binance’s normal withdrawal infrastructure”, and suspending withdrawals did not automatically invalidate them. The hot wallet used multi-party computation, so no single key existed to sign an instant revocation. Binance cleared the Binance14 delegation at 00:10 UTC on 30 October by signing a new authorisation to the zero address.

CERT-FR says the same thing about fridges. On an exposed end-of-life controller, a factory reset removes the attacker’s persistence but leaves the equipment vulnerable, and it “will certainly be compromised again.” Its fix starts with removing internet exposure. Access then comes back only through a VPN or protected network, and filtering by contractor IP address is a stopgap.

Microsoft’s guidance for the extension incident follows the same logic. Uninstalling the extension leaves behind the SSH key, the tunnel identity and the startup entries written outside the extension directory. Cursor’s server takedown does not remove artefacts already on a device either.

In all three cases the visible symptom (the withdrawal queue, the warm freezer, the extension in the sidebar) is the least important thing to remove. What has to go is the authority: the delegation, the network path, the authorised key, the deployment token. Every containment runbook should start by listing the authorities the compromised asset held, and close each one explicitly.

What the CRA covers, and what it does not

CRA Article 14 reporting has applied since 11 September 2026. A manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements files through the ENISA Single Reporting Platform on a fixed cadence.

ENISA told Recorded Future News that the reporting obligation covers end-of-life products no longer sold in the EU but still in use, and that reporting continues to apply after a product is no longer supported. The vulnerability-handling duty, fixing and shipping free updates, applies only during the manufacturer-defined support period. It does not apply where the product was placed on the market before 11 December 2027 or its support has ended. Nobody has to patch the 2016 controller, but someone may still have to report its exploitation within 24 hours. ENISA declined to say whether any manufacturer has filed for these attacks, and CRA notifications are not public.

Danfoss saw this coming. Its October 2025 newsletter announced a “hard End of Service” for legacy products, citing recent European cybersecurity legislation. Continued support, it said, “would place Danfoss under new legal obligations to maintain security updates.” The revised Product Liability Directive applies to new products from this December. Under it, a product can be treated as defective if the manufacturer fails to provide security updates within its control. Neither the CRA design duties nor the PLD reaches back into the installed base.

[MEME PLACEHOLDER: two buttons] A sweating manufacturer with two buttons in front of him. Left button: “Patch the 2016 fridge controller”. Right button: “Report it to ENISA in 24 hours”. Original illustration in Phoenix brand style, not the stock meme template. Alt text: “Meme: a sweating manufacturer choosing between patching a 2016 fridge controller and reporting it to ENISA in 24 hours”.

The trigger is exploitation. CVSS does not decide whether you file, and scores move without the code moving. CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP code:

• It was fixed upstream before the CVE was published.
• The kernel CNA scored it 9.8 on 24 October.
• Red Hat rated it 5.9, then 8.1 on 29 October, then Critical 9.8 after exploit research was published.
• As of 3 November it was not in CISA KEV, and no in-the-wild exploitation had been reported.

Run your programme off severity thresholds and that CVE pages you three times without ever producing a reportable event. Run it off exploitation evidence and you watch the code, rank it on reachability, and stay ready.

The Phoenix Approach: the Orange-led 24-hour run

Phoenix is built for the parties the CRA puts on the clock: software vendors and makers of devices with embedded software selling into the EU, plus SaaS teams whose service forms part of such a product. It does not patch fridge firmware and it does not sit on a store network. If you are a manufacturer and one of your components is exploited in the field, you assemble the 24-hour response in Phoenix Orange. A human approves every exception, every fix and every report. Phoenix gathers the evidence and suggests the next move. The full flow is in From SBOM to Declaration: Closing the CRA 24-Hour Clock Across One Platform.

Why the exception register beats the raw SBOM

An SBOM tells you a component is present. It does not tell you whether the vulnerable code path is reachable in your build, whether a control already covers it, or who decided that and when the decision expires. Publish an SBOM without that answer and every CVE match becomes a customer ticket. The Orange exception register holds the answer: time-bound, approved and audited exceptions, each with an exploitability position attached. On the day a vulnerability is exploited, you file from that register.

Noise reduction is what makes the one exploited finding visible. ClearBank cut container vulnerabilities by 98% with Phoenix, from around 467,000 to around 8,000, and its criticals dropped from 1,470 to 48. With a queue that short, an owner sees an exploited component at T+0 before anything else.

The developer-machine lesson in Orange terms

The Binance chain maps onto three Orange actions:

• Attribute the vulnerable or over-permissioned asset to an owner, so the developer endpoint with standing production reach has a name against it.
• Prioritise by the authority it grants (deployment tokens, signing rights, SSH access) rather than by finding count.
• Revoke that authority through a campaign tracked to closure against runtime exposure, so the team finds the dangerous path before an attacker does.

Blue Shield adds prevention at install time on workstations, agent sessions and CI. That is where both the tampered extension and the fake assignment would have landed.

What to do this week

1. Run a timed 24-hour tabletop on a real past incident from your own history. Pick a malicious package or a developer-machine compromise rather than a CVE, because awareness and attribution break first there. Stop the clock at the point you could file an early warning, and write down what was missing.
2. Inventory every identity, human or workload, with a path to signing, deployment, release or publishing. Record whether each path is standing or just-in-time, and whether it is reachable from a developer endpoint. Remove the standing ones.
3. Check your exception register field by field: owner, justification, exploitability position, approver, expiry. Any exception without an expiry or an approver is a gap you will hit at T+24h.
4. For every product you still sell or support in the EU, write down the support period, plus the end-of-life date for older versions still in use. ENISA has told you reporting outlives support.
5. Look at your own internet-facing management interfaces, including the ones contractors installed. If something that should only answer through a VPN answers from the internet, take it off today.

FAQs

Does the CRA apply to products we no longer sell?

The reporting duty does. ENISA has confirmed it covers end-of-life products that remain in use in the EU. The duty to fix and ship free updates applies only within the support period you define.

Do we have to patch an end-of-life product that is being exploited?

Under the CRA, no, if the product is out of support or was placed on the market before 11 December 2027. You may still have to report the exploitation within 24 hours. The compensating measure you recommend (isolation, removal from the internet) belongs in the 72-hour notification.

What starts the 24-hour clock?

Awareness of active exploitation in your product. A CVSS rating does not start it, and a high score with no exploitation evidence does not oblige you to file.

Is an SBOM enough for CRA readiness?

No. An SBOM without an exploitability position per component turns every CVE match into a support ticket. You need the signed decision record behind it.

A developer laptop was compromised. Is that a CRA reporting event?

It depends on what the attacker reached. A compromised laptop on its own is an internal security incident. If the attacker used it to tamper with the build, signing or release of a product with digital elements, or to ship malicious code to customers, you are likely looking at a severe incident affecting the security of the product, and the 24-hour clock applies. Map the laptop’s authorities first. The answer depends on what those authorities could change in what you ship.

We halted the obvious action. Are we safe?

Not until you have revoked every authority the attacker obtained. Binance paused withdrawals, and the on-chain delegations kept working until it signed a revocation. CERT-FR says a reset controller that stays exposed will be compromised again. List the tokens, keys, delegations and network paths in play, and close each one.

Were the refrigeration attacks and the Binance theft carried out by the same group?

There is no evidence linking them. The FBI attributes the Binance theft to North Korea. For the refrigeration attacks, the only claims are unverified, deleted posts from NoName057(16) and Z-Pentest, and Belgium’s CCB says the perpetrators may never be identified. This article links the incidents by pattern only.

Was the Claude Code extension incident an Anthropic breach?

No. Microsoft reports that Anthropic confirmed its systems were not compromised and that the malicious versions were never on the Visual Studio Marketplace or npm. The incident was limited to Cursor’s marketplace.

Could you file in 24 hours?

Pick an incident from your own history and time how long it takes to name the affected products, versions and owners. If it’s more than a day, book a CRA readiness walkthrough and we’ll run the tabletop with you. More on our Cyber Resilience Act readiness page.

External References

1. CERT-FR, Alerte CERTFR-2026-ALE-012: Incident de sécurité ciblant les contrôleurs à distance des installations de réfrigération
2. Recorded Future News, EU cyber law won’t force fixes for fridge controllers hit in French attack (20 October 2026)
3. Recorded Future News, Second wave of suspected cyberattacks hits supermarket freezers across Europe
4. IPinfo, France’s Supermarket Fridges Were Vulnerable Online for Months
5. Synacktiv, Danfoss SM800 and SC255 authentication bypass advisory (2023)
6. Danfoss, DSA-2025-03-01 (CVE-2025-41450)
7. Danfoss, DSA-2025-08-01 (CVE-2025-41451, CVE-2025-41452)
8. Claroty Team82, Freeze the Controller, Defrost the Food
9. CISA, ICSA-25-140-03, Danfoss AK-SM 8xxA Series (Update A)
10. The Hacker News, Attackers Heat French Supermarket Fridges Up to 50°C by Hijacking Danfoss Controllers
11. The Hacker News, New Wave of Refrigeration Cyberattacks Hits Supermarkets Across Europe
12. SecurityWeek, Over 100 European Stores Hit as Supermarket Fridge Attacks Return
13. CBC News, A fridge hack spoiled food in hundreds of French supermarkets
14. CNBC (Reuters), New cyberattack on supermarket fridges sweeps across Europe
15. Euronews, Cyberattacks hit supermarket fridges and freezers in Europe, Belgium launches investigation
16. Cybernews, Russian hackers claim responsibility for attacks on European refrigeration systems
17. franceinfo, EFS cold-room cyberattack report
18. Établissement français du sang, press release
19. SecurityLab.ru, Selyatino agro-hub attack (2 March 2022)
20. Binance, 29 October Binance Security Incident: Initial Findings and Response Update
21. BleepingComputer, Binance says fake job interview led to $6.3 billion crypto heist
22. CoinDesk, Binance’s $6.3 billion hack began with a fake job interview
23. SecurityWeek, Rigged Coding Assignment, Abused AI Tool Opened Path to $6 Billion Binance Heist
24. The Block, Binance says hackers used fake job interview, internal AI tool in $6.3 billion breach
25. Phoenix Security, Binance $6.3B Hack: How a Compromised DevOps Laptop Reached the Hot-Wallet Signer (No CVE)
26. Microsoft Security Blog, Inside a malicious Claude Code-branded extension and its persistent SSH backdoor
27. Phoenix Security, Claude Code Extension 2.1.313 Backdoor
28. ENISA, CRA Single Reporting Platform FAQ
29. The Hacker News, Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions
30. The Hacker News, Red Hat Patches 9.8-Rated Linux TCP RCE Flaw While Ubuntu Releases Fixes for Testing
31. Phoenix Security, ClearBank case study
32. Phoenix Security, From SBOM to Declaration: Closing the CRA 24-Hour Clock Across One Platform
33. Phoenix Security, Cyber Resilience Act Readiness