As reported by CISA in advisory ICSA-26-274-06, two missing-authorization vulnerabilities in the Meari IoT Cloud Platform OpenAPI Service expose deployed IoT devices to configuration tampering and full device-shadow disclosure — and the vendor has not responded to coordination attempts, leaving customers with no vendor-supplied remediation path.
Vulnerability Summary
| CVE | CVSS v3.1 | Severity | Impact |
|---|---|---|---|
| CVE-2026-101104 | 7.7 | High | Authenticated user can manipulate configurations of devices they do not own (CWE-862) |
| CVE-2026-96613 | 7.7 | High | Authenticated user can access complete device shadow of any device by specifying its device ID — exposing credentials, owner details, network data, and telemetry |
Why This Matters More Than the CVSS Suggests
A 7.7 High rating understates the real-world risk when you factor in the absence of any remediation. These aren't theoretical logic bugs awaiting a fix — they are permanent architectural gaps in the OpenAPI authorization model. Any authenticated tenant or API consumer can enumerate device IDs and read or modify other tenants' device states. In a multi-tenant IoT cloud, that is a full tenant isolation failure.
The single most alarming detail in this advisory is not the CVSS score — it is the line: "No fix planned. Meari did not respond to CISA's coordination attempts."
CVE-2026-96613 is particularly dangerous because it exposes the device shadow — the cached state object that IoT platforms use to synchronize device configuration. Device shadows routinely contain Wi-Fi credentials, API tokens, telemetry payloads, and ownership metadata. An attacker who can read any device's shadow by ID can pivot into lateral access across the customer's network infrastructure, potentially bridging into OT environments where Meari-connected sensors or controllers are deployed.
Who Is at Risk
Any organization whose IoT deployments route through the Meari cloud platform is exposed. This includes commercial facility operators using Meari-connected smart building devices, industrial environments where Meari acts as a telemetry bridge, and any IT estate where device credentials stored in the Meari cloud could provide pivot points into corporate networks. Given worldwide deployment, the exposure surface is geographically broad.
The risk is compounded for environments where the OpenAPI service is exposed to the internet without additional access controls — a common configuration for IoT cloud platforms that assume tenant isolation at the application layer.
Shield53 Recommendations — Immediate Actions
- Inventory and identify exposure. Determine whether any devices in your environment communicate through the Meari IoT Cloud Platform. Check outbound connections to Meari API endpoints and device management interfaces.
- Assume credential compromise. Treat all device credentials, API keys, and network configuration data stored in the Meari cloud as potentially exposed. Rotate any credentials that may have been stored in device shadows.
- Network-segment IoT traffic. Place Meari-dependent devices on an isolated VLAN with strict egress filtering. Do not allow IoT device management traffic to traverse into production or OT network segments.
- Restrict OpenAPI access. If you maintain any integration with the Meari OpenAPI, apply IP allow-listing, enforce mTLS, and log all API calls. Monitor for enumeration patterns — sequential or high-volume device ID lookups are a strong indicator of exploitation attempts.
- Detection guidance. Alert on any authenticated OpenAPI request that accesses device resources outside the requesting tenant's expected device scope. Since the platform itself doesn't enforce ownership, your API gateway or reverse proxy must.
- Plan for platform exit. Given the vendor's non-responsiveness, evaluate alternative IoT platforms. A vendor that will not engage with CISA on a High-severity advisory is an unacceptable supply-chain risk for any production deployment.
- Report exploitation. If you observe active exploitation, report to CISA and your national CSIRT. Vendor silence does not eliminate your incident-response obligations.
The broader lesson here is sobering: when an IoT cloud vendor refuses to engage with a national CERT on a fundamental authorization failure, the risk transfer is complete. The vulnerability becomes the customer's problem — permanently. Security teams should treat vendor responsiveness and patch track record as a first-class procurement criterion, not an afterthought.
