By Adrian Cheek, Senior Cybercrime Researcher
Overnight between October 11-12, 2026, refrigeration systems at several hundred grocery stores in France were driven into forced defrost. Temperatures in some cases reached 50 degrees Celsius, stock was destroyed, and equipment overheated. The French national CERT published an alert on October 12, naming two series of refrigeration system managers and telling operators to remove them from the internet or tightly restrict who can reach them. It revised that alert on October 13 to add further targeted equipment, and the affected list now covers two product families from a second vendor alongside the original two. French regional reporting on October 13 described that second vendor’s equipment being targeted in turn, with a store in the southwest left without refrigeration. The official and the reported scope of the incident both widened during the reporting period. No attribution has been published and the method of initial access has not been established.
This research does not attempt to answer how the attackers got in. It answers a narrower question that can be answered from outside: how many of these controllers are published to the internet, where they are, how old the software on them is, and what else is reachable at the same address. All of it was collected passively. No controller was authenticated to, scanned directly, or interacted with beyond what commercial internet scanning platforms had already recorded, and no exploit of any kind was attempted.
The answer reframes the incident. On the most complete single collection route, France accounts for 1,293 exposed controllers against 1,009 across every other country combined. That concentration helps explain why a campaign against this product family would produce its largest visible effect in France. It does not, by itself, establish why any individual system was compromised. The controller is also, at most of these addresses, one of several services the site publishes, and that has more defensive consequence than any single vulnerability does.
Table 1. Headline measures. Every population figure here is a floor rather than a total. Three independent collection routes each returned hosts the others missed, and two of the three were truncated by platform limits, so the true population is higher than 2,667.
Key Findings About French Refrigerator Exposures
- France’s exposure is not explained by older software. The share running the oldest observed build is 12.7% in France and 9.6% elsewhere, a gap of 3.1 percentage points. The public explanation for France’s hit points to old units. Our measurement doesn’t support that as the reason for France’s concentration.
- The freezer controller is rarely the only thing exposed. 65% of confirmed controller addresses (356 of 547) also publish at least one other service. These include remote desktop (72 hosts), camera and video recorders (42), and VPN concentrators (78). The freezer got noticed because spoiled food is visible, but a camera feed or remote desktop session at the same address gives no such signal. Defenders should scope their work to the address and everything forwarded to it, not to refrigeration alone.
- These devices can be found even when searches by model name come up empty. Searches on the model number return nothing on either scanning platform, because the device doesn’t name itself in its page title. It does name its own authentication header in its cross-origin response, and that string appeared on 547 of 786 target hosts and on none of 1,595 hosts from six other product families.
- Nearly every exposed interface tells any website it may send its requests. Of 1,026 responses with a cross-origin policy, 1,024 allowed any origin and permitted the device’s own authentication header. We did not test whether this enables authenticated control, and we did not establish whether it is a factory default.
- Most exposed units appear to predate the 2025 authentication fix. Software age can be read from the outside, without logging in, from the served front-end bundle’s timestamp. Of 786 hosts with a usable date, 76.8% serve a build older than the first 2025 release. This is a proxy for software age, not confirmed patch state.
- Stolen credentials are a possible second route, and keyword searches won’t find them. These controllers are reached by bare IP address and non-standard port, so saved credentials contain no product name to search for. Searching five infostealer exports (about 3,400 infected machines) by product name returned nothing. Starting from the exposed addresses instead surfaced one correlated credential, on a machine in southern Europe. Its validity and any link to the October incident are unestablished. The practical implication is that maintenance credentials held on contractor machines should be treated as potentially exposed.
- Every population figure is a floor, and the unit matters. At least 2,667 unique public addresses expose these controllers, built from three collection routes that each found hosts the others missed. A single platform’s headline count of 4,629 is service records, not devices, and 47.6% of those records come from eight addresses that answer on hundreds of ports. Any published figure needs to say whether it counts services or devices.
Identity-First-Threat Intelligence
Combine the Knowledge of Exposures with Flare’s Leaked Credential Database
Use Flare to access the infostealer credential database and check which credentials are circulating. Combine this with confirmed exposures to find and delete valid old passwords.
Counting What is Actually Exposed
The first counting problem is the distinction between service records and unique hosts. The primary fingerprint on the first platform returns 4,629 results, and that figure has circulated as a device count. It is a count of service records rather than devices, and in this population the distinction is unusually large.
Deduplicating those 4,629 records on address gives 2,302 hosts, a ratio of 2.01 records per unique public address. The inflation is not spread evenly. Eight addresses account for 2,205 of the 4,629 records, which is 47.6% of the total. The three largest answer on 950, 541 and 527 ports respectively, returning a byte-identical page on every one of them. Two of those three sit on consumer broadband in a single European city, and a third accounts for almost the entire reported total of one country in the southern hemisphere.
That behavior is well known in scan data and has nothing to do with the vendor. A device or an upstream appliance answers on every port it is asked about, and the scanner dutifully records each one. Any published figure for this device class needs to state whether it counts services or devices, because the two differ by a factor of two.
Table 2. Population by collection route. The second platform counts hosts natively rather than service records. Its result was truncated by a five-page result limit, so its 786 hosts are a capped sample rather than its full view, and the 254 new hosts it contributed were found inside that cap.
The practical lesson is that neither platform nor either fingerprint is sufficient alone. Each of the three routes returned hosts the other two missed, and two routes were truncated. 2,667 is therefore a floor, and a fuller enumeration of the second platform would be expected to raise it.
Table 3. Host and record counts by country on the most complete route. The host column is the meaningful one. Note that the country reported second by record count on this route resolves to a single device and does not appear here at all.
A Second Fingerprint, in the Response Headers
Searching either platform for the controller model number returns nothing. The devices are present. The model identifier simply does not appear in the page title, and the published guidance on finding these devices has pointed at the title.
A second identifier appears in the cross-origin preflight allowance returned by a substantial proportion of these devices. The device names its own authentication header there, and that header name carries the product family in it. Any host returning that header string was, in this dataset, a refrigeration system manager of this family regardless of what its title said. The converse does not hold, since roughly three in ten target hosts did not return it.
Tested for exclusivity, the header string returned no matches across 1,595 hosts drawn from six other refrigeration and building-control product families collected the same day. Within the comparison dataset the header was specific to the target product family. Zero observed false positives across a bounded comparison set is not a proof of absolute exclusivity, and the indicator should be read on those terms.
Table 4. Exclusivity test for the response-header fingerprint, run on the second platform. The six non-target families total 1,595 hosts and none returned the header. Two figures describe its reach and they measure different things. Within this sample 547 of 786 target hosts carried the header, or 69.6%, which is a coverage measure. On the first platform the header fingerprint returned 1,693 hosts against 2,302 for the page-title fingerprint, a ratio of 73.5% between two fingerprint result counts rather than a verified sensitivity. The two are close, and either way the header confirms that a device is in scope rather than sizing the population.
The Cross-Origin Policy is the Finding Inside the Finding
Of 1,026 observed responses carrying a cross-origin policy, 1,024 returned a wildcard origin. Two returned a same-origin policy. So a refrigeration management interface published to the internet is also, as shipped, telling any web page in any browser that it may make cross-origin requests to it, and is explicitly permitting the device’s own authentication header on those requests.
What that permits in practice is narrower than it first appears, and the distinction matters. Under normal browser enforcement a wildcard origin does not allow a credentialed cross-origin response to be read, because browsers reject the wildcard when credentials are included. What it allows is unauthenticated cross-origin requests and the reading of their responses. Separately, naming the device’s own authentication header in the allowance list permits that header to be sent on a cross-origin request. It does not supply a valid value for it, and nothing observed here demonstrates a route to authenticated control. No part of any such chain was tested. The configuration is recorded because it was observed across effectively the entire exposed population rather than on isolated units, and because an operational technology interface returning a wildcard origin is worth knowing about on its own terms. Whether it is a factory default or a deployment convention was not established, since that would require vendor documentation or an unconfigured unit to compare against.
Reading Software Age from Outside the Device
These controllers serve a static front-end bundle, and the response carries a last-modified timestamp and an entity tag for that bundle. The entity tag encodes the same timestamp in hexadecimal along with the content length, so the two corroborate each other. Taken together they give a build date for the web application without authenticating to the device or reading any version string.
Across the collected population, 786 hosts returned a usable build date, and the sample contained 156 distinct builds. Grouped against the two firmware releases that addressed the 2025 vulnerabilities, the distribution is as follows.
Table 5. Software age inferred from the served bundle. This dates the front-end build relative to the two 2025 releases. It does not establish the firmware patch state of any unit, and the figures should not be read as a count of unpatched devices. A minority of hosts return implausible dates, discussed under limitations.
France is not an Outlier on Software Age
This is the measurement that undercuts the explanation offered publicly after the incident. Comparing hosts in France against hosts everywhere else, on the oldest commonly observed web server build, gives 12.7% in France and 9.6% elsewhere. The observed difference is 3.1 percentage points. Because the measurement reflects a front-end build date rather than a verified firmware state, it does not support treating older software as the explanation for the concentration of incidents in France.
The host counts offer a more direct explanation for France’s prominence in the incident than the measured software-age distribution does. On the primary collection route France holds 1,293 of these controllers against 1,009 for every other country combined, on the same kind of consumer and small-business broadband connections, running a similar mixture of old and current builds. A campaign that swept this device class would have produced its largest visible effect in France on those grounds alone. Census figures cannot account for attacker targeting, maintenance-provider concentration or access paths, and no claim is made here about why the attackers chose what they chose.
The Controller is Rarely Alone on the Address
This is the result with the most defensive value, and it has not been reported. Taking the 547 hosts confirmed as refrigeration system managers by the header fingerprint, 356 of them, or 65%, publish more than one service at the same address. 191 publish only the controller.
At these addresses, the controller shares public exposure with services associated with remote administration, video recording, VPN connectivity, network management and edge device administration. The dataset establishes co-location at the same public address. It does not establish the internal topology behind that address, or that every service belongs to the same operator, since shared gateways and carrier network address translation can place unrelated hosts behind one address.
Table 6. Services recorded as responsive at the same public address as a refrigeration system manager, across 547 confirmed hosts. Counts are unique hosts rather than service records, and the three camera-related rows overlap, resolving to 42 distinct addresses rather than their sum. The three VPN rows likewise resolve to 78. This is a fingerprint-selected subset of the exposed population rather than a random sample of it, so the observed proportion of co-located services should not be assumed to hold across all 2,667 addresses. The scanning platforms recorded these services as responsive at collection time. Their current reachability was not independently validated here, nor was their authentication state, nor which operator each one belongs to.
The refrigeration controller became the visible part of this arrangement because spoiled stock is visible and a warm freezer aisle is noticed. A camera recorder or a remote desktop session at the same address produces no comparable signal. For an operator, the useful consequence is that the unit of work is the address and everything forwarded to it, rather than an inventory scoped to refrigeration alone.
What the Credential Data Did and Did Not Contain
Leaked credential sources were checked thoroughly for this device class, across five exports covering roughly 3,400 infected machines, because a credential route would require none of the published vulnerabilities. The result is close to a null, and the null is informative.
There were no saved credentials at all for the controller web interface by name, none for the vendor’s cloud access service, and none for three competing refrigeration supervisor products. What the corpus did contain was 199 unique credentials for the vendor’s customer portal and 27 for a competing vendor’s portals, which are sales and documentation sites rather than control interfaces.
The Single Exception, Reported in Full
One machine in the corpus connects the two datasets. It was a Windows host in southern Europe, compromised by a commodity infostealer in May 2025, carrying 92 saved credentials. Among them were logins to the vendor’s own front-end application across its production, development and staging environments, a login to an industrial remote-access platform, and two credentials addressed to bare IP literals on non-standard ports. One of those two addresses still served the refrigeration management interface when scanned sixteen months later, on a static business connection. The saved account names on that machine included the controller platform’s own supervisor role name.
The qualifications matter. The credential and the scan observation are 16 months apart and name different ports on the same address, so the possibility that the address changed hands is not excluded, although the connection is a static business line rather than a rotating consumer one. Nothing in this data establishes that the credential was used, that it remains valid, or that it has any connection to the October 2026 incident. What the correlation establishes is narrower. A saved credential addressed to a public IP appeared in a commodity criminal dataset, and a refrigeration management interface was subsequently observed at that same address. The two observations differ in time and in port, and neither the validity of the credential nor any access to the controller was established.
Why the Control Layer Does not Appear
One plausible explanation is structural. These controllers are reached by bare IP address on non-standard ports, so a saved credential for one may contain no product name, no vendor domain, no hostname and no certificate. There may be no product-specific identifier for a keyword search to match. The address and port remain available as pivots, which is the basis of the inverse method described below. This is a convention in how credential data is queried across the industry rather than a limitation of any one dataset, and it is worth naming because it means a keyword-led check of this device class will return a null for reasons that have nothing to do with whether the credentials exist.
The route that would work is the inverse. Enumerate the exposed population first, then query the credential corpus for those specific addresses. That is the next step on this research line, and the 2,667 addresses collected here are what makes it possible.
Published Vulnerabilities and Public Tooling
The vulnerability history for this platform is longer than the current coverage suggests, and it begins three years before the incident.
In January 2023, a European coordinated-disclosure body received reports of multiple web vulnerabilities in this controller family. Three identifiers were assigned, a vendor patch was issued, internet-wide scanning for vulnerable instances began in August 2023, and from September 2023 that body notified the owners of the instances it found. The case closed in December 2023. Owners of this device class were therefore contacted directly about internet exposure three years before the attack.
Table 7. Published issues affecting the two most exposed refrigeration supervisor families. Only one of the three 2025 issues is reachable before authentication. No authority or vendor has linked any of these to the October 2026 incident.
Two of these deserve emphasis:
- Only the authentication bypass is reachable before authentication, so any account of the incident implying three unauthenticated holes is wrong.
- The competing vendor’s unauthenticated arbitrary file read, published in mid-2026, received almost no attention at the time despite that vendor having the larger exposed population of the two. The national CERT’s revision of October 13 added that vendor’s products to the affected list, and regional reporting the same day described its equipment being targeted directly. That vendor is no longer adjacent vulnerability context for this incident. It is part of it, and the exposure figures measured here are consistent with that.
A Password that Changes Daily, and Changes to Something Predictable
The authentication bypass deserves its own explanation, because its mechanism is counterintuitive and it bears directly on the software-age measurement above.
The August 2026 research established that this controller family contains a second authentication path alongside the configured administrator password. That path accepts a code derived from the controller’s own current date. The code changes every day. Because the derivation is deterministic, anyone able to reproduce the algorithm can compute the accepted code for any given day and obtain an administrative session without holding the operator’s password at all. The vendor addressed it in the first 2025 release.
Changing an authentication code every day offers little protection when the next code can be calculated from a predictable value. Here the input is the controller’s own date rather than a secret, which allows anyone who knows the algorithm to generate the accepted code. The rotation changes the value without making it unpredictable, which is why the issue is an authentication bypass rather than a weak password.
Two consequences follow for this research:
- The software-age distribution matters more than a patch-currency statistic normally would, because the fix for this path landed in a specific release and most units in the dated sample serve a build predating it. That remains a proxy and still does not establish that any individual unit is vulnerable.
- The credential findings in section What the Credential Data Did and Did Not Contain, should be read alongside it rather than against it, because the two describe separate routes. One route requires no saved credential at all on affected firmware. The other requires a working maintenance credential and no vulnerability. Neither has been established as the method used in October 2026, and the published research on which this account rests deliberately withheld the algorithm itself.
Detection Content is Already Public
On October 13, a researcher published a detection-engineering repository for the three 2025 issues, containing a device emulator, network detection rules, host and log detection rules, a replay harness against captured traffic, and proof-of-concept scripts. It is framed as signature development rather than offensive tooling, the authentication algorithm in it is a deliberate stand-in because the original research redacted the real one, and the requests are reconstructed rather than byte-exact. Defenders can take the network and host rules from it today.
Detection and Inventory Logic
Everything below can be run by an operator against their own estate, and nothing requires a vendor relationship or a scanning subscription.
- Inventory by address, not by hostname or product. A refrigeration controller published through a port forward has no hostname and will not appear in any asset inventory keyed on names. Enumerate what every public address at every site answers on, across the full port range rather than the common ports.
- Look for the device’s authentication header name in the cross-origin allowance of any HTTP response from a site address. It is a high-specificity indicator for this product family within the comparison set tested here, and it will find units whose page title reveals nothing.
- Check the cross-origin policy on every control interface, not only refrigeration. A wildcard origin on an operational technology web interface is a finding in its own right.
- Read the last-modified timestamp and entity tag of the served front-end bundle to age the software from outside, then compare against the vendor’s release dates. This works without credentials and is a fast way to triage a multi-site estate.
- Enumerate every other service on the same address and treat the whole set as one exposure. In this population remote desktop and camera recorders were far more common companions than most operators would expect.
- Deploy the public network and host detection rules for the three 2025 issues, and alert on the date-derived credential pattern specifically rather than on exploitation outcomes.
- Follow the current national CERT guidance on isolating exposed equipment, assessing whether it has been compromised, and restoring affected systems. Review and rotate maintenance credentials alongside that work, particularly where accounts may have been held on contractor or operator machines.
Observed Exposure and Potential Technique Relevance
A passive census records conditions that exist on the internet. It does not record adversary activity, and a publicly readable disclosure establishes that information is available rather than that any actor collected it. The table below therefore separates conditions observed in the data from activity described in external reporting, and the first column should not be read as attacker telemetry. No command-and-control technique is listed, because a census cannot evidence one.
Table 8. Observed conditions and potentially relevant techniques. Only the first entry is a condition directly measured here. The second records that device information is publicly readable, which is not evidence that an adversary performed discovery. The third rests on infostealer evidence for a single machine and does not extend to the refrigeration correlation. The remainder are listed because incident reporting or a vendor advisory describes them, and are not claims about this dataset.
Key Judgments
High Confidence
- On the primary collection route, France holds a larger exposed population of this device class than every other country combined, at 1,293 against 1,009, while the software-age distributions differ by 3.1 percentage points. The dataset does not show France with a materially worse software-age profile. It does show a disproportionately large exposed population on that route.
- The exposed population is materially larger than any single platform or fingerprint reports. Three routes each contributed hosts the others missed, two of the three were truncated, and the union stands at 2,667 as a floor.
- The response-header string is a specific indicator for this product family within the comparison set tested, having returned no matches across 1,595 hosts from six other product families. Absolute exclusivity is not established by a bounded test.
Moderate Confidence
- Among the 786 hosts with usable front-end timestamps, 76.8% served builds dated before the 2025 authentication fix. The measurement is a proxy for software age rather than verified firmware status, it does not establish patch state, and how representative it is of the complete exposed population is unknown.
- The services co-located at these addresses widen the practical attack surface beyond the refrigeration controller alone, with 356 of 547 confirmed hosts publishing more than one. Co-presence was recorded directly by the scanning platforms. Reachability was not validated, nor authentication state, nor common ownership.
Low Confidence
- The near-absence of this control layer from leaked-credential sources is explained by bare-address access practice rather than by collection gaps. One counter-example exists in the corpus and alternative explanations are not excluded.
What Security Teams Can Do This Week
- Ask, for every site you operate, what the public address actually answers on across the full port range, rather than what the documentation says it should.
- Remove any controller of this class from direct internet reachability first, before anything else on this list. That is the step the national CERT leads with, and it is the only one that addresses the date-derived authentication path, which does not require a stolen credential.
- Put a credential review alongside the patching, after the exposure is closed rather than instead of closing it. Assume that a maintenance credential for any internet-reachable control interface may already be in a commodity criminal dataset, and rotate on that assumption. Rotation on its own does not address the date-derived path.
- Ask your refrigeration and building-control contractors in writing how they reach your equipment, what accounts exist for it, which of their own machines hold those credentials, and when those credentials were last rotated.
- Where remote maintenance is genuinely required, put it behind an authenticated gateway with logging rather than a port forward, and remove the forward afterwards.
What a Refrigeration System Attack Revealed About Exposures
The October defrost attack was visible because spoiled food cannot be ignored, but this census suggests the freezer was the least of what many of these sites exposed. At least 2,667 public addresses publish these controllers. France hosts more of them than the rest of the world combined, and nearly two in three sit beside cameras, VPN concentrators, or remote desktop services that would never announce a compromise as loudly. The data does not explain how the attackers got in, and it does not show that France’s software was older than anyone else’s. What it shows is how much of the problem sits in plain view, and that the useful unit of defense is the address and everything forwarded to it, not the refrigeration unit alone. Operators who close that exposure first, then rotate maintenance credentials on the assumption that some are already circulating, will have addressed the routes this research can actually see. Re-measuring the population against this baseline will show whether a national instruction to go offline changes anything, and the credential check against these 2,667 addresses will show how much of the second route remains unexplored.
Identity-First-Threat Intelligence
Combine the Knowledge of Exposures with Flare’s Leaked Credential Database
Use Flare to access the infostealer credential database and check which credentials are circulating. Combine this with confirmed exposures to find and delete valid old passwords.
Methodology and Limitations
Collection
All collection was passive. Device data came from commercial internet scanning platforms that had already recorded these hosts, and credential data came from leaked-credential sources already in the Flare dataset. No host was authenticated to, directly scanned, rescanned on request, or interacted with in any way, and no vulnerability was tested against any device. Commercial scanning platforms are not named in this piece as a matter of editorial convention; where the difference between them is itself the finding they are distinguished only as the first and second platform.
Why No Organization is Named
Collection identified the operators of a number of exposed estates, through address registration, reverse DNS, certificate data and the contents of credential records. None are named here. These are live exposures on third-party equipment in the middle of an active criminal investigation, and publishing an owner list would help an attacker considerably more than it would help a defender. Findings attributable to a specific operator were routed to the relevant national CERT and vendor instead. Vendors are named where the product and its published vulnerabilities are already a matter of public record.
Counting Basis
Device figures in this piece are unique public addresses carrying the product fingerprint, deduplicated on address. That is the precise unit of measurement, and it is not the same as a count of physical controllers. A single public address can front more than one unit behind network address translation, so the figures should be read as exposed addresses rather than as a device inventory. Where a record count is given it is labeled as such. The first platform reports service records rather than devices, at a ratio of 2.01 in this population, and 47.6% of its records for this fingerprint come from eight addresses that answer on hundreds of ports each. The second platform counts hosts natively. Mixing the two bases is the single most likely source of error in any published figure for this device class.
Truncation
Two of the three collection routes were truncated by platform limits rather than by the data running out. One bulk download capped at 1,000 records and a second at 300 before being re-run, and the second platform capped at five pages of results. Truncation was not geographically uniform: in one capped download a single country was fully captured while France stood at roughly 14% enumeration. Capped results were retained as observed subsets and were not extrapolated to estimate a total population. Population counts were constructed from observed unique addresses across the three collection routes. The co-location analysis in the section The Controller is Rarely Alone on the Address, is drawn from one of those capped subsets, and is reported on that basis.
The Software-Age Proxy
Build age is inferred from the last-modified timestamp of the served front-end bundle, corroborated by the entity tag, which encodes the same timestamp and the content length. This dates the web application rather than the firmware, and it is possible for the two to diverge. A minority of hosts return clearly impossible dates, one in 1981 and a cluster in January 2000. These are unlikely to represent genuine build dates and may reflect incorrect device clocks, timestamps inherited during firmware packaging, or other timestamp anomalies. Those inflate the oldest bucket slightly. They are independently interesting, because the 2025 authentication bypass derives its credential from the device date. Whether an incorrect or static clock makes that credential easier to predict is not established here. It would depend on how the date can be learned from outside and how the resulting code is validated, neither of which was tested.
Negative Results and Scoping
Several collection routes returned nothing, and they are recorded here so the scope of the exercise is clear rather than because the exercise failed.
- Searches on the controller model numbers against page titles returned zero on both platforms, as did the vendor’s refrigeration control brand name. The product does not identify itself in the title. This finding is what led to the response-header fingerprint.
- Within the credential corpus, searches for the controller interface name, both model series, the control brand, the vendor’s cloud service and three competing supervisor products all returned zero. One IP-literal match against 2,667 exposed addresses was the only connection found.
- Two product fingerprints returned only false positives and were discarded: one matched an unrelated manufacturing traceability product, and a model-number search against a device-vendor field returned nothing because that field is not populated for the vendor in question.
- Three short free-text fingerprints were rejected before use because they match ordinary text. One three-letter supervisor product name matched inside a surname, one matched an unrelated recruitment application, and one matched retail listings for televisions. Short product names are not usable as fingerprints in either scan or credential data.
What is not in this Piece
Collection produced two further bodies of material that are deliberately out of scope here. The first is a set of findings relating to vendor-side credential exposure, which was routed for notification rather than publication. The second is a substantially larger dataset on the industrial remote-access platforms used to reach operational technology generally, covering water utilities, building management, manufacturing and government. That material is a separate research line and will be published separately. Neither is required for, nor changes, the measurements reported above.
A note on the advisory text. The initial version of the national CERT alert, published on October 12, listed secret rotation and a review of existing accounts among its remediation steps. The revised version published on October 13 restructured that guidance into separate paths for equipment believed clean and equipment believed compromised, and those two steps no longer appear. The recommendation to treat maintenance credentials as potentially compromised is therefore presented in this piece as a conclusion from the research rather than as a paraphrase of the current advisory. The revised advisory does state that attacks are probably still ongoing, and that a factory reset alone is insufficient on end-of-life equipment because it remains vulnerable and is likely to be compromised again.
Figures in this piece were current on October 13, 2026. The advisory asks operators to remove these controllers from the internet, so the population is expected to move. Re-measuring it against this baseline will quantify how far a national instruction actually travels.
