On June 11, 2026, CISA’s industrial control systems team published three advisories in a single day. The products could hardly be more ordinary: a smart doorbell and camera platform, a line of network cameras, and a connected outdoor robot. None of them is exotic infrastructure. All of them are the kind of device that ends up on an office network through facilities procurement, a tenant build-out, or someone’s good intentions — and none of them is reliably tracked by the security team responsible for the network they sit on.

The three advisories carry different CVE numbers and affect unrelated vendors, but they describe the same failure. In each case, the authentication that was supposed to keep attackers out was never really there: a cryptographic key hardcoded into firmware, a password shipped as the default, a credential handed to anyone who connects. This is the oldest and most stubborn defect in connected devices, and seeing it documented three times on one day is a useful, uncomfortable snapshot of where office IoT security actually stands.

Advisory 1: Naxclow IoT Platform (ICSA-26-162-02)

The Naxclow advisory covers the Smart Doorbell X3, the X Smart Home hub, the V720 outdoor camera, and the ix camera line, across all firmware versions. It bundles seven CVEs spanning the full spectrum of credential and authorization failures.

The critical one is CVE-2026-28742 (CVSS 9.8): the platform uses a uniform request-signing scheme built on a hardcoded, platform-wide secret embedded in every firmware image (CWE-321, use of a hardcoded cryptographic key). Because the same secret is baked into every device, an attacker who extracts it from one unit can forge signed requests across the entire platform. Close behind is CVE-2026-42947 (CVSS 8.8), an authorization bypass through a user-controlled key (CWE-639): by replaying the device’s onboarding “confirm-then-bind” sequence, an attacker can silently reassign a device to an arbitrary account, with no user interaction, while the device stays online and gives no sign anything has changed.

The remaining five fill in the picture. CVE-2026-50101 is a per-device relay credential that never rotates, is reissued on every boot, and cannot be reset or revoked. CVE-2026-50108 and CVE-2026-50244 are missing-authorization flaws (CWE-862) in the platform API. CVE-2026-42932 covers predictable, enumerable device identifiers — fixed manufacturing prefixes plus sequential counters. And CVE-2026-50099 exposes the host network’s SSID, pre-shared key, and negotiated WPA keys in cleartext on an accessible UART console.

Independent analysis adds two sobering data points. A Shodan search for Naxclow reportedly returns over 120,000 devices exposing their HTTP interfaces to the public internet, and security researchers have described how a compromised camera can be used to pivot into a Windows network — running ARP spoofing to intercept traffic, capturing NTLM hashes during authentication, and attempting pass-the-hash toward domain controllers. (That lateral-movement chain comes from third-party analysis rather than CISA’s own text, but it describes exactly the kind of foothold an unmanaged camera provides.) Naxclow did not respond to CISA’s coordination attempts, and there is no firmware patch available.

Advisory 2: Brickcom Cameras (ICSA-26-162-03)

The Brickcom advisory covers the Cube, Dome, Bullet, and Box camera lines running firmware 3.2.3.5.6, with two CVEs. CVE-2026-50005 (CVSS 7.7, CWE-1392) is the use of default credentials: the cameras ship with a known default login, and an attacker can use it to access feeds and administrative control. CVE-2026-50245 (CVSS 7.7, CWE-306) allows unauthenticated retrieval of live snapshot images through the /ONVIF endpoint, with no authentication required at all.

It is worth being precise about the severity here, because early coverage circulated a 9.8 figure for CVE-2026-50005 that the authoritative record does not support — NVD scores it 7.7 under CVSS v3.1 and 8.3 under v4.0, with a local attack vector that pulls the base score below the typical default-credential “critical” band. High, not critical. The practical risk is real regardless: these cameras are deployed across commercial facilities, critical manufacturing, financial services, and healthcare worldwide, and an unauthenticated attacker can view live video and alter configuration.

The harder problem is that the Brickcom devices are end-of-life. There is no patch, and the vendor did not respond to CISA’s request for coordination. CISA’s guidance reduces to two options: change the default credentials and isolate the devices, or disconnect them. For an end-of-life camera with a public-facing snapshot endpoint, replacement is the only durable answer.

Advisory 3: Yarbo Robot (ICSA-26-162-01)

The Yarbo advisory covers the Yarbo mobile app below version 3.17.4 and the Yarbo cloud MQTT infrastructure. The critical flaw, CVE-2026-10557 (CVSS 9.8, CWE-798), is a set of hardcoded MQTT broker credentials — identical for every user and device, embedded in the app binary, and extractable by anyone who decompiles the app. Those credentials grant access to real-time device telemetry and the ability to publish commands. The companion flaw, CVE-2026-7368 (CVSS 8.1, CWE-862), is missing authorization in the cloud: with no per-device or per-user access control, a credential holder can subscribe with a wildcard to every robot’s telemetry topic globally and publish commands to any robot using only its serial number. The combination means fleet-wide visibility and fleet-wide control, with the attendant risk of unexpected equipment operation, property damage, and safety hazards.

Yarbo is the one vendor of the three that responded. The fix has two parts: update the mobile app to version 3.17.4 or later, and a server-side authorization control that was enforced automatically when the May 2026 backend update deployed, requiring no user action. The issue was reported by a researcher at Truesec. Among the three advisories, Yarbo is the model for how this is supposed to go — a vendor that engaged, patched the client, and fixed the cloud authorization centrally.

Why This Keeps Happening

Three independent vendors, the same defect, on the same day, is not a coincidence — it is the structure of the IoT market. Hardcoded and embedded credentials persist because they make mass provisioning simple: ship every device with the same key or the same default login and the manufacturing line never has to manage per-device secrets. The convenience that makes one credential work for a million devices is exactly what makes one extracted secret a skeleton key for the entire fleet. That is the direct cause behind Yarbo’s CVE-2026-10557 and Naxclow’s CVE-2026-28742.

Weak, guessable, and hardcoded passwords have sat at the top of the OWASP IoT Top 10 for years — it is the number-one item on that list — and the Mirai botnet demonstrated the consequences at scale by weaponizing default-credential cameras and routers. A decade later, the defect ships anyway, because until very recently there has been no commercial penalty for shipping it. That is precisely the gap regulators are now closing: the EU Cyber Resilience Act’s secure-by-default requirements and 24-hour reporting obligation, and the US Cyber Trust Mark labeling program, exist to make exactly these failures a market liability rather than a footnote.

The second recurring theme is the camera as a pivot. An IP camera is a small Linux computer with a network connection and, very often, a position inside the trust boundary of the network it monitors. Compromise it and you have an unmanaged, persistent foothold that traditional endpoint controls never see — a place to scan adjacent systems, intercept traffic, and move toward higher-value targets. Documented camera-based intrusions have followed exactly this path: initial access through the device, then a pivot inward. The 120,000 internet-exposed Naxclow devices are 120,000 potential footholds of this kind.

What To Do Now

The three advisories share a single remediation backbone, and it starts before any individual CVE:

  1. Discover the devices you do not know about. Two of these three advisories have no patch; one is fixed centrally. In every case the first action is the same — know that the device is on your network. Cameras, doorbells, and connected robots are routinely installed outside IT’s procurement path. A current asset inventory that captures devices bought by facilities, tenants, and individual teams is the prerequisite for everything else. You cannot isolate, replace, or even risk-rank a device you cannot see.
  2. Segment IoT onto its own network. CISA has been increasingly explicit that micro-segmentation is no longer optional. A camera on a properly segmented VLAN — unable to reach file servers, domain controllers, or other segments — has a contained blast radius even when it is compromised. Segmentation is the control that neutralizes the camera-as-pivot threat regardless of whether a given device is ever patched.
  3. Change every default credential, and verify it. The Brickcom default-credential flaw is remediated by changing the password. This is basic, and it is routinely skipped at install time. Treat default-credential elimination as a documented, verified step in device onboarding, not an assumption.
  4. Plan and budget for end-of-life replacement. The Brickcom cameras and several Naxclow products will never receive a fix. Isolation buys time; replacement closes the exposure. End-of-life connected devices need a line in the budget and a date on the calendar, not a hope that firmware will arrive.
  5. Make vendor responsiveness a buying criterion. Two of these three vendors ignored CISA entirely. The one that engaged shipped a fix and remediated the cloud side automatically. A vendor’s track record of coordinated disclosure and timely patching is a legitimate, predictive procurement signal — and one the coming regulatory regimes will increasingly formalize.

In Context

Three advisories in a day, all tracing back to credentials that should never have shipped, is a compact illustration of the office IoT problem: the devices are cheap and plentiful, the defects are old and predictable, the vendors are uneven in their willingness to fix them, and the security team often does not know the devices are there. The defensive response does not hinge on any single CVE. It hinges on the unglamorous program fundamentals — asset discovery, segmentation, credential hygiene, and a funded end-of-life plan — that contain this entire class of device whether or not a patch ever arrives.

The encouraging note is that the market is beginning to move in the same direction the security guidance has long pointed. Regulators are making secure-by-default a legal requirement, and buyers are gaining the standing to demand it. Until that shift fully lands, the burden stays with the organizations operating these devices, and the June 11 advisories are a reminder that the burden is real, current, and sitting on networks right now.