On 8 July 2026, the Zero Day Initiative published ZDI-26-398 as a zero-day. The advisory covers CVE-2026-15680, a remote code execution flaw in the Lorex 2K Indoor Wi-Fi Security Camera. The technical summary is short: the camera’s sonia service parses JSON requests and passes a user-supplied string straight into a format specifier. An attacker on the adjacent network needs no credentials and gets code execution as root.

CVSS is 7.5 (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) — a score held down entirely by the adjacent-network vector and the attack complexity. Strip those two away and this is a 9.8. Which is worth sitting with, because “adjacent network” is not a meaningful barrier in most offices.

The Disclosure Timeline Is the Story

ZDI’s own timeline reads:

  • 8 July 2025 — vulnerability reported to the vendor
  • 3 September 2025 — ZDI requests a status update
  • 12 March 2026 — ZDI asks the vendor to confirm a fix
  • 25 June 2026 — vendor indicates remediation is “underway”
  • 26 June 2026 — ZDI notifies the vendor it will publish as a 0-day
  • 8 July 2026 — public advisory, no patch

That is 365 days from report to publication with no shipped fix. ZDI’s only mitigation guidance is the one it gives when there is nothing else to say: restrict interaction with the product.

Compare that to the reporting clock the EU is about to impose on exactly this class of device. From 11 September 2026, a manufacturer aware of an actively exploited vulnerability in a product with digital elements owes an early warning in 24 hours, a fuller notification in 72, and a final report within 14 days of a fix being available. A vendor that takes twelve months to acknowledge a root RCE is not operating anywhere near that cadence. We wrote about that deadline in June; this advisory is what the pre-CRA baseline actually looks like.

Why “Adjacent Network” Is Not a Mitigation in an Office

AV:A means the attacker has to be on the same network segment as the camera. Security teams read that as containment. In practice, in a typical connected office, it means:

  • Anyone on guest Wi-Fi, if guest and IoT share a VLAN — and in offices where the cameras were installed by a facilities contractor rather than IT, they very often do.
  • Any compromised endpoint on the same segment. A phishing payload on one laptop puts the attacker adjacent to every camera on that subnet.
  • Any other compromised IoT device. Cameras rarely sit alone; they share space with badge readers, door controllers, thermostats, and TV sticks.
  • Any contractor’s laptop plugged into a conference room port.

Root on a camera is not just a privacy problem. It is a Linux box with a NIC, inside your building, running as root, with a legitimate reason to talk to internal infrastructure and no EDR on it. That is a beachhead. Compromised cameras were the pivot point in the Naxclow platform advisories CISA published in June, where reporting described exactly this pattern — camera foothold, then ARP spoofing and NTLM hash capture against Windows hosts on the same LAN.

The Part That Should Actually Worry You: Who Wrote sonia?

The vulnerable component is sonia, the camera’s main service binary. It is not Lorex code. As the Midnight Blue researchers who found the bug documented, sonia is Dahua firmware — Lorex was a Dahua brand for years, and the shared lineage is well enough known that hobbyists routinely flash Dahua firmware onto Lorex hardware and vice versa.

This is the normal state of the camera market, not an exception. A relatively small number of ODMs write the firmware; a much larger number of brands put their logo on the box. When a bug lands in the shared binary, it lands in every rebadge simultaneously — and only the brands whose researchers happened to look at their specific SKU get a CVE. The rest inherit the vulnerability with no advisory, no CVE, and no way for a defender to search for it.

Concretely, this means your asset inventory answering “we have twelve cameras, brand X” is not enough information to determine your exposure. The question you cannot currently answer is: what firmware lineage do our cameras run, and what else shares it?

The CRA Angle Is Sharper Than It Looks

Annex III of the EU Cyber Resilience Act names “smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems” as Class I important products. A Wi-Fi security camera lands squarely in that bucket — and the same product sold into an office lobby carries the same classification.

Class I is where self-assessment gets conditional. A manufacturer may self-assess only by applying harmonised standards or an approved certification scheme. As of July 2026 no CRA harmonised standards had been formally cited in the Official Journal, which leaves notified-body involvement — EU-type examination — as the realistic route for Class I devices.

An unauthenticated root RCE also runs directly into two Annex I essential requirements: products must be placed on the market without known exploitable vulnerabilities, and must protect against unauthorised access with appropriate control mechanisms. A twelve-month-old unpatched root bug fails both tests as plainly as it is possible to fail them.

What To Actually Do

  1. Segment cameras onto their own VLAN, today. Not “IoT VLAN” shared with guest Wi-Fi and the smart TVs — a dedicated segment with an explicit allowlist. If the only thing that needs to reach a camera is the NVR or VMS, that is the only thing that should be able to.
  2. Deny cameras outbound internet by default. Most office cameras have no legitimate need to originate connections to the internet. Cloud-managed ones do; make that an explicit, allowlisted exception per destination, not a blanket rule.
  3. Record firmware lineage, not just brand. Add a field to your asset inventory for the underlying OEM/ODM where you can determine it. When the next shared-binary bug drops, that field is the difference between a targeted patch cycle and a guess.
  4. Make disclosure responsiveness a procurement criterion. Ask vendors, in writing, for their mean time from third-party report to shipped fix, and for two recent examples. A vendor that cannot answer has told you the answer.
  5. Budget for replacement of unresponsive vendors’ hardware. When ZDI’s advice is “restrict interaction with the product,” you are being told the device is unmaintained. Isolation buys time; it is not a destination. This is the same conclusion the end-of-life Brickcom cameras forced in June, and it needs a budget line rather than a hope.

The Pattern

Three things converged in this one advisory: a trivially exploitable memory-safety-adjacent bug in a device sold as a security product, a vendor process that could not turn a report into a patch in a year, and a supply chain where the vulnerable code belongs to a company whose name is not on the device.

None of those are new. What is new is that from 11 September, the second one becomes a reportable regulatory failure rather than a private embarrassment. The organisations that come out of the next twelve months well are the ones treating vendor responsiveness as a security control they can measure — because the alternative is discovering, a year late, that the camera watching your lobby has been shipping root to anyone on the same VLAN the whole time.