On the night of 11 October 2026, attackers forced the refrigeration controllers of hundreds of French supermarkets into defrost. Three weeks later, the same kind of attack hit nine more European countries.

Somebody built those controllers, and that team now faces the questions every fleet incident raises. Would we notice an attack, and which devices are exposed? Is this crash a bug or an exploit? Does this vulnerability actually apply to our product? Has the fix reached the field?

Since 11 September 2026, those questions have a deadline. The EU Cyber Resilience Act (CRA) requires manufacturers to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability in their product, and the obligation also covers products that are already on the market.¹

Below are four real cases from 2025 and 2026 involving devices that run in fleets, each with the question it forced and how Spotflow helps you answer it.

1. Sabotage of an Exposed Fleet: Supermarket Refrigeration Controllers

On the night of 11 to 12 October 2026, attackers gained remote access to the refrigeration management systems of supermarkets across France and manipulated their defrost settings. Economy Minister Roland Lescure put the number of affected stores at about 700, and temperatures rose as high as 50°C.² France’s national CERT named Danfoss, Copeland, and Dixell controllers and told operators to take them off the internet.³ On the night of 1 to 2 November, the same kind of attack hit more than 100 stores in nine more countries, along with cold rooms at three sites of the French blood service.⁴⁵⁶ Irish food wholesaler Musgrave said its monitoring systems alerted it to the issue.⁷ The Hacker News thread on the first wave drew more than 1,000 comments.

Officials haven’t explained how the attackers got in, and nobody has claimed responsibility. Security researcher Kevin Beaumont said, citing people he had spoken with, that every freezer hit in the second wave had a management interface reachable from the internet, and Danfoss said most hacked units were legacy products it no longer updated.⁵ Known flaws in its AK-SM 800A series, including the authentication bypass CVE-2025-41450, were fixed in firmware releases R4.2 and R4.3.1, but no CVE has been confirmed as the way in.⁸

How Spotflow helps. Spotflow wouldn’t have stopped this attack: the exposed interfaces sat on operators’ networks, outside the manufacturer’s control. But the manufacturer is the party that can ship a firmware fix, and Spotflow gives it devices that report their own state.

• Report what the device controls. Publish cabinet temperature, setpoints, and defrost state as metrics, through the device module on Zephyr or spotflowd’s custom metrics socket on Embedded Linux. A per-device alert rule fires when a controller’s temperature crosses a threshold, and a no-data condition flags controllers that go silent. A joint US government fact sheet on 5 November recommended alerting on setpoint deviations.⁹
• Keep a record of changes. Spotflow collects logs from Zephyr and, on Embedded Linux, from journald or a syslog file. If your firmware logs setting changes, you can search the fleet for who changed a defrost setting and when.
• Monitor without an inbound port. The device module and spotflowd connect outbound over MQTT with TLS and don’t open a listening network port on the device.

Spotflow - An example alert rule that evaluates a metric per device and fires when any device crosses the threshold.

This is the kind of event the CRA’s Article 14 is built for, though whether it applies here stays open while the entry point is unconfirmed.¹ From December 2027, new products also need a support period of at least five years (or the expected time of use, if shorter), with its end date stated at the time of purchase, so a controller that leaves support while it’s still in the field is a risk you plan for, not a surprise.

2. Memory Corruption Over the Air: Zephyr’s L2CAP Bug (CVE-2026-5068)

On 9 June 2026, the Zephyr project published advisory GHSA-qrcq-hxwj-mqxm.¹⁰ A remote, unauthenticated Bluetooth LE peer could trigger a two-byte out-of-bounds write in the Bluetooth host while it reassembled L2CAP credit-based channel SDUs. Exposure depends on the application: it requires segmentation enabled through chan_ops.alloc_buf and an RX buffer pool whose user_data_size is below 2 bytes. Without sanitizers, the result is heap corruption or a fatal error. NVD rates it 8.8 (High), the Zephyr project 7.6, and the advisory lists fixes for the main branch and the v4.3 branch.

In the field, this doesn’t look like an attack. It looks like a device that occasionally crashes, and without crash data it becomes a “cannot reproduce” ticket.

Don’t count on an SBOM scanner to settle this one. west spdx gives the Zephyr tree a versioned CPE identifier only when your checkout sits exactly on a release tag such as v4.3.0. On any other commit, it records the git commit, which a scanner that matches by version range can’t place. And when a scanner does raise the CVE, it can’t see your configuration. For the Zephyr core, follow the project’s GitHub security advisories and check them against your application: if it doesn’t meet both conditions above, the advisory’s scenario doesn’t apply to it.

How Spotflow helps.

• Crash reports. On a fatal error, Zephyr stores a core dump in a flash partition, and the Spotflow device module uploads it after reboot, linked to the exact firmware build. Spotflow extracts the stack trace and register values, and AI analysis explains the probable root cause. An out-of-bounds write can crash later, in unrelated code, so don’t expect every stack trace to point at l2cap_chan_le_recv_seg. The signal is similar traces from many devices on the same firmware version. The Zephyr crash debugging walkthrough shows the workflow.
• Reset causes. The boot_reset metric reports why each device restarted, so you can chart resets across the fleet and alert when they rise after a release.

Spotflow - A crash report with the firmware build, the stack trace, and an AI summary of the probable cause.

3. Severity Out of Context: The ESP32 “Backdoor” and a 9.8 in Mbed TLS

In March 2025, Tarlogic reported undocumented HCI commands in the ESP32’s Bluetooth controller that can read and modify memory. A widely shared headline called it a backdoor in a chip used by a billion devices (Hacker News thread), and Tarlogic later said “hidden feature” was the more appropriate term. Espressif responded that these are debug commands, present only on the original ESP32, that can’t be triggered over Bluetooth, radio, or the internet without another vulnerability, and committed to an ESP-IDF patch that removes access to them.¹¹ NVD counts 29 hidden commands and scores CVE-2025-27840 6.8 (Medium), with physical access and high privileges required.¹²

Scanners create the same problem from the other side. On 30 June 2025, Mbed TLS disclosed CVE-2025-47917: before version 3.6.4, mbedtls_x509_string_to_names() frees memory through an argument its documentation describes as an output, so callers can end up using freed memory.¹³ NVD scores it 9.8 (Critical),¹⁴ but the advisory is narrower: applications that don’t call the function directly aren’t affected, and the library’s internal uses of it are safe.

Severity lives in the CVSS vector, the advisory’s conditions, and your architecture, not in the headline or the score.

How Spotflow helps. Upload the SBOM your build generates to each firmware version. Since Zephyr 4.0, west spdx records Mbed TLS with a versioned CPE identifier, so a firmware version built on Zephyr 4.0 or 4.1, which ship Mbed TLS 3.6.2, gets a finding for CVE-2025-47917, with the dependency chain that pulls it in. The short video below shows the workflow, from uploading an SBOM to the Security overview.

Spotflow - A security issue in Mbed TLS, included in the firmware through Zephyr, with its CVSS score, assessment state, and timeline.

Every security issue then has an assessment state: Not Assessed, In Triage, Affected, or Not Affected. Following the Vulnerability Exploitability eXchange (VEX) approach, “Not Affected” requires a justification, for example that the vulnerable code is not invoked at runtime, and “Affected” requires a response, such as updating the component or applying a workaround. Every change lands in the audit timeline with who made it, when, and why, which supports the CRA’s requirement in Annex I, Part II to identify and document the vulnerabilities in your product.¹

Spotflow - Marking a security issue as Not Affected with a VEX justification and a detail note.

Triage doesn’t replace updating: a finding you marked Not Affected today is still worth removing in the next regular release.

4. A Fix Every Device Has to Receive: Zephyr’s DNS Parser (CVE-2026-1678)

On 5 March 2026, the Zephyr project published advisory GHSA-536f-h63g-hj42 for its DNS resolver.¹⁵ dns_unpack_name() checked the remaining buffer space once and then kept appending labels, so a DNS response with long labels could write past the default 255-byte name buffer. The advisory calls remote code execution plausible, depending on memory layout. Zephyr rates the flaw 9.4 (Critical) and NVD 9.8.¹⁶ Builds from before the fix that enable CONFIG_DNS_RESOLVER with the default CONFIG_ASSERT=n are exposed, and enabling assertions only turns the overflow into a crash.

The advisory describes the flaw as network-reachable and unauthenticated: an attacker needs to get a crafted DNS response to a device that uses the resolver. NVD lists Zephyr 3.7.2, 4.2.2, and 4.3.1 as the first fixed releases on their branches. On nRF Connect SDK, which ships its own Zephyr fork, take the fix from the nRF Connect SDK release that includes it.

As with the Bluetooth bug, an SBOM scanner only raises this one when your Zephyr checkout sits on a release tag. Either way, the Zephyr version or commit your SBOM records for every firmware version tells you which releases predate the fix.

How Spotflow helps.

• Size the job. The Spotflow device module reports each device’s build ID, and Spotflow matches it to the symbol file you uploaded for a firmware version, which links each device to the version it runs. The device count on each firmware version built before the fix tells you how many devices need the update.
• Roll out in cohorts. Upload the patched build as a new firmware version and deploy it over the air to a small cohort selected by device tags, such as model or hardware revision, then expand. Each device moves through pending, in progress, and succeeded or failed. You can retry failed updates, stop the rollout, or create a rollback deployment.
• Watch the new build. A network stack update can break connectivity. An alert rule with a no-data condition flags devices that stop reporting after the update, and boot_reset and crash reports show whether the new build is stable before you widen the rollout.

Spotflow - Deployments to a production cohort, with device counts by update status and Stop and Rollback actions.

The Four Cases at a Glance

Limits Worth Knowing

• What runs on the device depends on the platform. SBOM findings and triage work for any platform. Logs, metrics, and crash reports come through the Spotflow device module (Zephyr, nRF Connect SDK, ESP-IDF), spotflowd (Embedded Linux), or the MQTT interface on any other platform. OTA updates run through the device module on Zephyr and nRF Connect SDK, or over MQTT.
• SBOM matching is only as good as the SBOM and the CVE data. Spotflow matches packages by their CPE identifiers, so check that the packages in your SBOM carry them. Where a match is ambiguous, such as a package with no vendor in its CPE, it reports the finding, because a missed vulnerability costs more than a false positive you can mark Not Affected.
• Monitoring signals indicate, they don’t prove. A temperature anomaly or a crash cluster tells you where to look, not that a device is compromised.
• Tools don’t make a product compliant. Spotflow supports CRA work, but your organization decides which requirements apply and what to report.¹⁷

An Incident-Readiness Checklist

1. Keep management interfaces off the public internet, and have devices connect outbound.
2. Report the values your device controls as metrics, with per-device alert rules that include a no-data condition.
3. Generate an SBOM in every release build (for example west spdx for Zephyr, create-spdx for Yocto 5.1 or later, or idf.py sbom-create for ESP-IDF), check that packages carry CPE identifiers, and upload it to the firmware version together with the ELF symbol file.
4. Collect crash reports and reset causes, and review new security findings on a fixed schedule, recording every decision.
5. Test your OTA path before you need it, and roll out security fixes in cohorts.
6. Define each product’s support period, and plan for devices that are still in the field after it ends.
7. Write down your CRA reporting procedure, including who decides and who files the 24-hour early warning.

Conclusion

A sabotaged refrigeration fleet, a Bluetooth bug, two misleading severity signals, and a DNS fix that still has to reach the field all came down to the four questions this post started with.

If you can answer them from data, the first hours of an incident go into decisions. If you can’t, they go into rebuilding the answer from old build logs and store reports, and under the CRA the reporting clock keeps running while you do. Device telemetry with per-device alerts, an SBOM for every firmware version, a recorded triage decision for every finding, and a tested OTA path close that gap.

FAQs

Does the Cyber Resilience Act require an SBOM? Yes. Annex I, Part II requires manufacturers to identify and document the components in their products, including a software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies. The SBOM is part of the technical documentation, and Annex II leaves it to the manufacturer whether to make it available to users.

What do I have to report under the CRA, and when? Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents through the CRA single reporting platform: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available (one month after the notification for severe incidents). It applies from 11 September 2026, including to products placed on the market before December 2027.

Which SBOM formats does Spotflow accept? Tag-value SPDX 2 and JSON SPDX 3 files. You can upload several SBOMs to one firmware version, for example the separate SPDX documents that west spdx generates.

How does Spotflow find new vulnerabilities in releases we shipped long ago? Spotflow syncs CVE data from NVD every two hours and re-matches every stored SBOM against new and changed CVEs. A firmware version uploaded last year gets a new finding once NVD lists the affected products for a matching CVE, without a rebuild or a new upload.

Ready to get started? Sign up for Spotflow, no credit card required.

Explore the documentation to go deeper:

• Track security issues across your devices
• Comply with CRA
• Over-the-air (OTA) updates
• Crash reports & core dumps
• Metrics
• Alert rules
• Spotflow for the Cyber Resilience Act

Want to go deeper on the 24-hour clock? Join our webinar CRA: Could Your Team Report a Vulnerability in 24 Hours? on 25 November 2026.

Questions or feedback? Reach out on Discord or email hello@spotflow.io.

Citations