CVE-2026-96613

Executive Summary

CVE-2026-96613 is an authorization flaw in the Meari IoT Cloud Platform OpenAPI Service that permits any authenticated user to retrieve the complete device shadow of an arbitrary device by supplying its device ID. Because the service fails to verify any ownership or relationship between the requesting account and the target device, an attacker with basic authenticated access can exfiltrate sensitive information including device credentials, owner details, network data, and telemetry. The vulnerability carries a CVSS base score of 6.5 and remains unpatched according to all tracked sources.

Technical Analysis

The affected component is the Meari IoT Cloud Platform OpenAPI Service, a cloud-facing API interface that manages IoT device state and interaction. The vulnerability class is CWE-862 (Missing Authorization). In a correctly implemented device-shadow API, the service is expected to enforce an object-level authorization check: after authenticating the caller, the backend must confirm that the caller is associated with (owns, manages, or is otherwise entitled to) the device identified by the supplied device ID before returning that device's shadow.

In this case, that check is absent or ineffective. The NVD description states that the service "allows authenticated users to access the complete device shadow of any device by specifying its device ID," and that it does so "without verifying any relationship between the requester and the target device." This is a classic Broken Object Level Authorization (BOLA / IDOR) condition: authentication is enforced (the attacker must be a valid, authenticated user — hence the PR:L privilege requirement), but authorization scoped to the specific object is not.

The attack surface is the OpenAPI Service endpoint that returns device shadow data. Because the CVSS vector is AV:N (network reachable) and AC:L (low attack complexity), no special conditions, race windows, or user interaction (UI:N) are required — a single crafted request bearing a valid session/credential and a target device ID is sufficient. The confidentiality impact is rated High (C:H) because the device shadow aggregates highly sensitive material: device credentials, owner details, network data, and telemetry. Integrity and availability are unaffected (I:N/A:N), and the scope is unchanged (S:U).

Critically, the available intelligence does not disclose the specific endpoint path, HTTP method, query/body parameter names, authentication header format, or device ID format. Those implementation-level specifics are not present in the NVD description and are therefore not asserted here. The defining technical fact is the missing object-level authorization check on a device-shadow read operation parameterized by device ID.

Exploitation Scenarios

No public proof-of-concept is available; the attack chain below is inferred strictly from the vulnerability class (CWE-862 missing authorization / BOLA) and the NVD description. It does not rely on any invented endpoint, parameter, or function name.

1. Reconnaissance / target identification. The attacker obtains a valid account on the Meari IoT Cloud Platform (the flaw is reachable by any authenticated user, consistent with PR:L). The attacker then identifies one or more target device IDs. Device IDs for IoT fleets are frequently sequential, predictable, or discoverable through other APIs, telemetry, or registration flows. No relationship to those devices is required.

2. Triggering the flaw. The attacker issues a request to the OpenAPI Service device-shadow endpoint, substituting an arbitrary target device ID in place of their own. Per the description, "specifying its device ID" is the sole requirement, and "no relationship between the requester and the target device" is verified. The missing authorization check is the root cause — there is no ownership validation gate to defeat, because the gate is absent.

3. Payload/execution method. At the vulnerability-class level, this is a direct object-reference substitution in an authenticated API call. The attacker reuses their legitimate session/credentials and changes the object identifier. No injection, memory corruption, or complex payload is involved; success depends only on the server returning shadow data for the non-owned device ID. Specific request syntax is not documented in the source data and is not fabricated here.

4. Post-exploitation impact. The response — the "complete device shadow" — exposes device credentials, owner details, network data, and telemetry. Captured device credentials can enable further abuse (for example, impersonating the device or pivoting into the owner's ecosystem), while owner details and network data enable targeting, and telemetry reveals device state, behavior, and potentially physical-world context. Because the method is repeatable, an attacker can enumerate device IDs to harvest shadow data at scale across the fleet.

Impact Assessment

Business impact centers on large-scale disclosure of sensitive IoT data and credentials. The CVSS base score of 6.5 reflects a medium-severity rating driven by high confidentiality loss offset by a low-privilege requirement (PR:L) and no integrity/availability impact. The blast radius is potentially the entire device population reachable through the OpenAPI Service, since authorization is not scoped per-object and device IDs can be enumerated. Leaked device credentials and owner details create downstream risk: account/device takeover, unauthorized device control, privacy violations affecting end users, and regulatory exposure (for example, personal data protection obligations tied to owner details and telemetry). The unchanged scope (S:U) means impact is confined to the vulnerable service's authorization domain, but the sensitivity of the exposed data raises the effective severity. Affected systems are all deployments of the Meari IoT Cloud Platform OpenAPI Service for which this authorization check is missing; the exact version range is not specified in the available sources.

Detection Guidance

Because no public PoC or exploit code exists and no vendor signature is available, detection must target the behavioral pattern: authenticated requests to the device-shadow read endpoint that reference device IDs not associated with the requesting account, and anomalous enumeration of device IDs. Detection logic below is written generically where endpoint/parameter names are not documented; teams should adapt field names to their observed API telemetry.

Sigma Rule

title: Potential Meari IoT Cloud OpenAPI Device Shadow BOLA Access
id: 96613000-0000-4000-8000-000000009661
status: experimental
description: Detects authenticated access to the Meari IoT Cloud OpenAPI device shadow endpoint where the requested device ID is not associated with the requesting account (CWE-862 / BOLA), consistent with CVE-2026-96613.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-96613
author: valtersit.com
date: 2026-01-01
logsource:
  category: web
  product: generic
detection:
  selection_endpoint:
    cs-uri-stem|contains:
      - '/shadow'
      - '/device'
      - '/openapi'
  selection_method:
    cs-method:
      - 'GET'
      - 'POST'
  selection_auth:
    sc-status: 200
  filter_self:
    account_device_match: true
  condition: selection_endpoint and selection_method and selection_auth and not filter_self
fields:
  - src_ip
  - cs-username
  - cs-uri-query
  - sc-status
falsepositives:
  - Administrative or service accounts legitimately accessing multiple devices
  - Field names must be mapped to the specific API telemetry in use
level: medium

YARA Rule

rule CVE_2026_96613_Meari_Device_Shadow_BOLA
{
    meta:
        author = "valtersit.com"
        description = "Detects artifacts referencing Meari IoT Cloud device shadow access / enumeration consistent with CVE-2026-96613"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-96613"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $a = "device shadow" ascii nocase
        $b = "deviceId" ascii nocase
        $c = "device_id" ascii nocase
        $d = "Meari" ascii nocase
        $e = "/openapi" ascii nocase
        $f = "shadow" ascii nocase

    condition:
        uint16(0) == 0x5A4D or (2 of ($a, $b, $c, $d, $e, $f))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-96613 Meari IoT Cloud OpenAPI Device Shadow Access Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"shadow"; nocase; http.uri; content:"device"; nocase; http.header; content:"Authorization"; nocase; reference:cve,2026-96613; classtype:attempted-recon; sid:9661301; rev:1;)

alert http any any -> any any (msg:"CVE-2026-96613 Possible Device ID Enumeration Against Meari OpenAPI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"openapi"; nocase; threshold:type both, track by_src, count 20, seconds 60; reference:cve,2026-96613; classtype:attempted-recon; sid:9661302; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=60s
  [http where http.request.method == "GET" and http.request.uri : "*shadow*" and http.response.status_code == 200]
  [http where http.request.method == "GET" and http.request.uri : "*shadow*" and http.response.status_code == 200]
  [http where http.request.method == "GET" and http.request.uri : "*shadow*" and http.response.status_code == 200]

Note: A high count of successful device-shadow reads by a single account, especially for device IDs (from http.request.uri) not correlated to that account, is the primary signal. Field names should be mapped to the actual API access log schema.

Splunk SPL Query

index=web sourcetype=meari:openapi OR sourcetype=access_combined
| search (uri_path="*shadow*" OR uri_path="*device*") status=200 method=GET
| rex field=uri_path "(?<device_id>[A-Za-z0-9_\-]{6,})"
| stats dc(device_id) as distinct_devices count as requests values(device_id) as devices by user src_ip
| where distinct_devices > 5
| sort - distinct_devices

This surfaces accounts reading an unusually high number of distinct device IDs — a strong indicator of the missing-authorization exposure described in CVE-2026-96613.

Wazuh OSSEC Rule

<group name="meari,openapi,cve-2026-96613,">
  <rule id="966130" level="8">
    <decoded_as>json</decoded_as>
    <field name="uri_path">\.*shadow\.*</field>
    <field name="status">200</field>
    <description>CVE-2026-96613: Successful device shadow access on Meari OpenAPI (potential unauthorized object access)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web,accesslog,</group>
  </rule>

  <rule id="966131" level="10" frequency="15" timeframe="60">
    <if_matched_sid>966130</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-96613: Possible device ID enumeration against Meari OpenAPI from same source</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web,accesslog,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected version range is currently published in the tracked sources.

1. Immediate mitigations:

   • Enforce object-level authorization (ownership/relationship checks) in the OpenAPI Service so that a device shadow is returned only when the authenticated caller is verified to be associated with the requested device ID. This is the root-cause fix for CWE-862.
   • Where feasible, restrict or disable access to the device-shadow OpenAPI functionality until authorization controls are in place, or gate it behind strong, enterprise-only access paths.
   • Apply API rate limiting and device-ID enumeration throttling to reduce bulk-harvesting potential.
   • Add monitoring/alerting for authenticated shadow-access patterns that span device IDs not tied to the requesting account (see Detection Guidance).

2. Patch/upgrade steps:

   • Monitor the vendor (Meari) for an official advisory and patched firmware/cloud-service release; no patch currently exists per tracked sources.
   • When a fix is released, validate that the authorization check binds the caller to the target device before returning shadow data, and re-test for BOLA by attempting cross-account device ID access.
   • Rotate device credentials and any secrets potentially exposed via device shadows once the fix is applied, since exposure may have already occurred.

3. Long-term hardening:

   • Adopt object-level authorization as a mandatory control in API design reviews and tests (IDOR/BOLA test cases in CI).
   • Implement centralized authorization middleware that evaluates account-to-device relationships for every device-scoped request.
   • Treat device credentials and owner/network/telemetry data as high-sensitivity fields; minimize what is returned in shadow responses and apply field-level access control.
   • Maintain continuous log monitoring for anomalous cross-device access and integrate detections into the SOC.

References

• NVD — CVE-2026-96613: https://nvd.nist.gov/vuln/detail/CVE-2026-96613
• MITRE CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• OWASP API Security Top 10 — API1: Broken Object Level Authorization (BOLA): https://owasp.org/API-Security/
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-96613 not listed as of this report)

Note on exploitation in the wild: No public PoC, exploit code, Nuclei template, or CISA KEV entry is associated with CVE-2026-96613 in the available data. No known threat actor campaign tied to this CVE has been identified. Exploitation potential is assessed as credible given the low complexity (AC:L), low privilege requirement (PR:L), and high confidentiality impact (C:H), but no in-the-wild evidence is currently available.