Research

Copeland XWEB EVO Refrigeration Controllers Have 14 New CVEs, Unauthenticated Root, Exploitation Within Two Hours and No More Fixes. Take Them Off the Internet Today

Patrick Duggan · · 5 min read

Copeland XWEB EVO Refrigeration Controllers Have 14 New CVEs, Unauthenticated Root, Exploitation Within Two Hours and No More Fixes. Take Them Off the Internet Today

If you have a Copeland (Dixell) XWEB EVO supervisor controller reachable from the internet, take it off the internet today. Put it behind a VPN or a firewall rule that admits only the addresses that need it, and close every port on it, not only the web interface. On November 12 and 13, VulnCheck published 14 vulnerabilities in these controllers. The worst give full control of the device to anyone who can reach it, with no password. VulnCheck saw two of them exploited within hours of publication. Copeland ended software support for the XWEB EVO family on 16 March 2026, so some of these flaws will never be fixed.

These controllers supervise refrigeration in supermarkets, warehouses and food distribution. CERT-FR named Copeland and Dixell XWEB among the controllers compromised in the French supermarket attacks of October 11 and 12, which we covered on November 2. Five US agencies warned about attacks on refrigeration controllers on November 9 without naming a vendor. These CVEs are what an attacker now has for this product line, in public.

What was published

VulnCheck is the CVE Numbering Authority for all 14. The first CVE records went live on November 12 at about 19:34 UTC, and VulnCheck's writeup by Valentin Lobstein followed on November 13. VulnCheck says it reported all 14 to Copeland's security team on October 17, and that on November 10 Copeland, citing end of support, left the CVE assignment to VulnCheck.

The five CVE records we read in full:

  • CVE-2026-124002 (CVSS 4.0 score 9.3): unauthenticated command execution as root through the login page. Affects 5.2.3 up to but not including 5.7.0.
  • CVE-2026-124004 (9.3): a hardcoded administrator password, giving full administrative access. Affects versions before 5.6.2.
  • CVE-2026-124007 (9.2): a second unauthenticated command execution path through the login page. Affects versions before 5.6.2.
  • CVE-2026-124010 (9.3): unauthenticated command execution as root through a console program on the device. Affects versions before 5.6.2. Exploited in the wild, per VulnCheck.
  • CVE-2026-124014 (8.8): an unauthenticated write to the system configuration file, enough to tamper with the controller's settings or stop it working. The record gives 4.3.0 through 5.8.8, which VulnCheck describes as the latest firmware. Exploited in the wild, per VulnCheck. No fix.

VulnCheck's writeup lists nine more. Among them are predictable daily administrator and operating-system passwords that, by VulnCheck's account, still reach the current 5.8.8 firmware. Because of those, closing only the web port is not enough. That is why we say close every port.

Exploitation

VulnCheck's own canary sensors recorded the attempts. Exploitation of CVE-2026-124014 began on November 12 at 22:00:05 UTC, an hour and forty minutes after the record reached NVD, with 125 requests from 202.61.138.117 (AS152194, CTG Server Limited, Tokyo). Exploitation of CVE-2026-124010 began on November 13 at 03:41:20 UTC, with four requests from 177.4.12.11 (AS140227, Hong Kong Communications International) through 04:09:55. VulnCheck reads both as opportunistic scanning acting on a fresh advisory, not a targeted operation. It added both CVEs to VulnCheck's own KEV list. They are not in CISA's Known Exploited Vulnerabilities catalog as of its November 13 release.

That is one company's sensors, so it is one source. It does not tell us whether any real controller has been hit with these CVEs since November 12, and we do not claim it has.

How many are exposed

VulnCheck counts roughly 1,663 internet-facing hosts on Shodan using a fingerprint that pairs the XWEB page title with an XWEB EVO page marker, which it uses to filter out decoy honeypots. It cites Onyphe's count of about 1,960 public EVO hosts.

On November 2 we printed a larger number, 7,570 hosts whose page title includes XWEB. That count was title-only and we said it would include false positives. VulnCheck's note that title-only searches pick up honeypots is the likely reason for most of the gap. Both counts are what scanners last saw, not how many devices are vulnerable.

What to do

  1. Take it off the internet. No management interface on a refrigeration controller should face the internet. Use a VPN or an allow-list firewall rule, and block all ports, including remote shell access.
  2. Check what version you run, and do not treat an upgrade as the fix. Builds from 5.6.2 and 5.7.0 close the worst command-execution flaws, but the configuration write, CVE-2026-124014, runs through 5.8.8 and will not be fixed. On the Copeland download page we read for the XWEB300D, 500D and 500 EVO, the newest build offered is 5.2.3 from 2018, which is inside CVE-2026-124002's affected range. Ask Copeland or your installer which build your model can run.
  3. Plan the replacement. VulnCheck's advice is to treat an XWEB EVO as a device that must never touch the public internet, and to plan a move to a supported platform. We agree.
  4. Look for signs of tampering. If a controller was internet-facing after November 12, check its configuration and set points against what you expect, change every password on it, and review its logs for access from addresses you do not recognize. VulnCheck's writeup includes request patterns and two detection rule names; pass them to whoever runs your intrusion detection.
  5. Block the two published addresses. Both are now in our feed (below).

How we know

We read the CVE records for CVE-2026-124002, 124004, 124007, 124010 and 124014 from the CVE Services API, VulnCheck's November 13 writeup, Copeland's software update pages, and the CISA KEV JSON feed (catalog release of November 13), all on November 15. A public proof-of-concept repository for the cluster appeared on GitHub on November 14, and our exploit harvester logged it on November 15 at 00:01 UTC. That is when an exploit went public, not a sighting of attacks.

Our edge instruments watch HTTP traffic to web properties, and we run no XWEB decoy. Across 432,608 edge-block records, 74,022 edge-canary records and 1,822 origin-honeypot records since October 1, none matched the XWEB request paths. That is a measurement of our own zones, not of the internet, and it says nothing about scanning of real controllers.

In our feed

We added both addresses VulnCheck published, cited to VulnCheck and not as our own observations:

  • 202.61.138.117, confidence 60. A rentable VPS address, so it is in the default feed but below our edge shield's blocking floor of 80. Spamhaus DROP already covered its /18 before this, which is block coverage from Spamhaus's list, not a detection by us.
  • 177.4.12.11, confidence 80. We already held it from October 15, from Huntress's research on AhsayCBS exploitation leading to cryptomining, and ThreatFox had listed it on October 3. A second, unrelated report puts it at 80.

Sources

If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register