xn0tsa/nobody-puts-baby-in-a-corner: coordinated by Tod Beardsley / runZero.

1.1M cameras on a public broker, five CVEs, and six weeks of negotiating with the vendor

Report Date: May 11, 2026

Researcher: Sammy Azdoufal

Research Type: Independent. The audit was prompted by a colleague at work who'd just bought a baby monitor on Amazon and asked whether it was safe. Full story in Section 1. No bug bounty program existed.

Evidence Sources: Static analysis of com.meari.cloudedge 5.5.0 build 220 and 19+ white-label APKs sharing com.meari.sdk. MQTT broker traffic capture against mqtts-{us-west,eu-frankfurt,cn-hangzhou}.meari.com.cn from a normal CloudEdge account. Public-facing infrastructure probes against apis.meari.com.cn, openapi-euce.mearicloud.com, 118.31.20.61:8080, and the Alibaba OSS buckets meari-{eu,us,oss-eu,oss-hz,sg}.oss-{region}.aliyuncs.com.

CVEs

Coordinated by Tod Beardsley / runZero. CISA tracking: VINCE Case VU#579666 (opened 2026-04-03).

• CVE-2026-33356 — MQTT broker missing per-device subscribe ACL — CVSS 7.7 High
• CVE-2026-33357 — OpenAPI device-status IDOR → WAN IP disclosure — CVSS 7.5 High
• CVE-2026-33359 — Alert images unauthenticated on Alibaba OSS — CVSS 7.5 High
• CVE-2026-33361 — Weak XOR obfuscation on .jpgx3 baby-monitor images — CVSS 7.5 High
• CVE-2026-33362 — Hardcoded static cryptographic keys in client SDK — CVSS 8.6 High

How This Started

In February 2026 I'd just finished an audit of DJI's Romo robot vacuum platform. The kind of work where you spend a week watching a global MQTT broker leak floor plans of strangers' apartments at your terminal. A colleague at work read the writeup. She'd bought a baby monitor on Amazon a few weeks earlier, and asked me the question every civilian eventually asks: is it safe?

I didn't know. The boxes don't tell you which cloud platform they phone home to. The apps are interchangeable. "Made in China by an ODM nobody's heard of" describes about 90% of the consumer baby-monitor market. So I bought the same brand she had, made a fresh account, and started watching what it sent over the wire. The brand was a CloudEdge / Meari white-label. Six weeks later, this is the report.

No client. No engagement letter. One colleague, one Amazon order, one question.

Executive Summary

Meari Technology is a Hangzhou ODM. They build the camera, the firmware, the cloud and the mobile app, then sell the whole stack to brands who put their own logo on the box. CloudEdge is the in-house consumer brand. 300+ partner brands ride the same backend: Arenti, BOIFUN, COCOCAM, PetTec, SV3C, Joystek, Luvion, Vimar, and on.

Five things.

1. The MQTT broker that streams motion alerts to your phone has no per-device subscribe ACL. Any free CloudEdge account can subscribe to meari/# and watch every device on the platform in real time. Measured: 14,204 messages from 2,117 distinct devices in five minutes from a single regional broker.
2. An OpenAPI endpoint, signed with a key hardcoded in every Meari-based app, returns the WAN IP of any device by serial number. No account needed.
3. Motion-alert JPEGs sit on Alibaba OSS without authentication, signed URLs, or expiry. The URL appears in the MQTT message. It works forever.
4. Baby-monitor alert images use the .jpgx3 extension. .jpgx3 is a JPEG with the first 1024 bytes XOR'd against MD5(SN | len(SN) | "[REDACTED]"). The serial is in the same MQTT message that delivered the URL.
5. Every Meari-based app ships the same hardcoded HMAC secret, the same [REDACTED] DES key for password transport, the same OpenAPI key, the same P2P password. None of them can rotate without re-flashing every device in the field.

The platform that ships these defaults sits in front of, conservatively, 1.1 million registered devices across 118+ countries. The number comes from two internal Meari datasets I confirmed during the audit: an 825,194-row device-geolocation table, and a 1,160,795-row P2P license table on the US backend (98,250 on Hangzhou).

That's the technical face of the disclosure. The other face, in Section 11, is what happens when you tell the vendor.

Background: What is Meari?

Hangzhou Meari Technology Co., Ltd. (杭州美象智能科技股份有限公司). Listed on the Shenzhen ChiNext board on March 9, 2025; share price doubled in the two trading sessions after the IPO. Almost nothing sold under their own name in Europe or North America. The revenue model is the white label. CloudEdge (com.meari.cloudedge) is the in-house consumer app. Every other brand in the ecosystem embeds the same com.meari.sdk and connects to the same EMQX brokers, the same apis.meari.com.cn, the same Alibaba OSS buckets.

Meari already had a public regulatory record before this audit. In March 2024 the Zhejiang Provincial Communications Administration cited CloudEdge for forced and excessive permission requests, frequent self-launching, and unauthorised cross-device data collection. A CVERC review concluded the rectification was "merely superficial compliance" and that the company "continues to collect user data beyond necessary scope", including approximate location via IP and Wi-Fi when the user had refused the location permission. Two years later the same backend that received that data was reachable from a free account.

CVE-2026-33356 — Subscribe to Everyone Else's Camera

CVSS 7.7 High — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N — CWE-639 Authorization Bypass Through User-Controlled Key.

The EMQX 4.x broker enforces publish ACLs (PUBACK is sent, message silently dropped). It does not enforce subscribe ACLs at per-device scope. Any authenticated app user subscribes to the platform-wide wildcard and reads everything.

Repro

1. Install CloudEdge from Google Play. Register with any email.

2. Login. The response hands you MQTT credentials in cleartext: host, clientId, username ({deviceId}-{timestamp}-{random}), password (base64-HMAC).

POST https://apis.meari.com.cn/ppstrongs/app/user/login2
  userAccount=<your_email>
  password=<DES_ENCRYPTED>     # see CVE-2026-33362 for the key
  signatureMethod=HMAC-SHA1 signatureVersion=1.0
  signature=<HMAC>

3. Connect to the broker and subscribe to the wildcard:

mosquitto_sub \
  -h mqtts-us-west.meari.com.cn -p 8883 --cafile <ca.pem> \
  -i "<mqtt.clientId>" -u "<mqtt.username>" -P "<mqtt.password>" \
  -t "meari/#" -v

4. Messages from every other device on the platform start arriving immediately.

What you get

• msgid=111 motion alerts with picUrl to Alibaba OSS (see CVE-2026-33359).
• msgid=170 device-binding events with deviceUUID, snNum, userAccount (PII).
• msgid=172 device-sharing events with hostKey. The hostKey is often the literal string "admin". That's also the P2P auth password.
• Cloud-video segment URLs broadcast as part of motion events.
• Live floor plans for the robot vacuums on the same backend.

Scope

Confirmed across three regions (US-West, EU-Frankfurt, CN-Hangzhou). One five-minute capture from a single broker: 14,204 messages, 2,117 distinct devices, 85+ country codes in the binding events.

CVE-2026-33357 — Device Status IDOR (WAN IP Disclosure)

CVSS 7.5 High — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — CWE-862 Missing Authorization.

GET /openapi/device/status on openapi-euce.mearicloud.com returns the WAN IP and TUTK relay parameters of any device, by serial number, with no user authentication. The request needs an HMAC-SHA1 signature using the static OpenAPI key. That key is hardcoded in every CloudEdge / Arenti / BOIFUN / etc. APK (CVE-2026-33362).

Repro

FSN="<8-digit serial without 4-char prefix>"
TS=$(date +%s)
KEY="[REDACTED]"     # CVE-2026-33362
SIG=$(echo -n "fsn=${FSN}&timestamp=${TS}" | \
      openssl dgst -sha1 -hmac "${KEY}" -binary | base64)
curl "https://openapi-euce.mearicloud.com/openapi/device/status?\
fsn=${FSN}&timestamp=${TS}&signature=${SIG}&accesskey=${KEY}"

Returns wan_ip, relay_server, tutk_uid for the device. MaxMind / IPinfo resolves wan_ip to a residential precision good enough for stalking.

Scope

Sweep against serials harvested from the MQTT firehose (CVE-2026-33356) resolved 13,734 devices to city-level precision.

CVE-2026-33359 — Alert Images, No Auth, No Expiry

CVSS 7.5 High — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — CWE-862 Missing Authorization.

Motion-alert JPEGs are uploaded to public Alibaba OSS buckets (meari-{eu,us,oss-eu,oss-hz,sg}.oss-*.aliyuncs.com). The URLs:

• Are not signed.
• Carry no token parameter.
• Have no expiry.
• Are broadcast in plaintext over the MQTT channel that any account can subscribe to (CVE-2026-33356).

Repro

From the MQTT firehose, take a msgid=111 message:

{
  "msgid": 111,
  "deviceSn": "<SN>",
  "picUrl": "https://meari-us.oss-us-west-1.aliyuncs.com/alert/<path>.jpg",
  "time": <unix>
}

Then:

curl -o snapshot.jpg "<picUrl>"

The image is whatever the camera was pointing at when motion fired.

Scope

A 72-second capture from one broker yielded 51 distinct image URLs across 29 unique cameras, all dereferenceable. A 3-minute capture across three brokers: 222 alert image URLs from 191 doorbells and baby monitors. An internal alert-history table accessible from the same compromised infrastructure listed 39,514 unencrypted alert JPEGs from 9,809 devices. None of those URLs are reproduced here. The vulnerability is the URL itself.

CVE-2026-33361 — .jpgx3 Is XOR

CVSS 7.5 High — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — CWE-326 Inadequate Encryption Strength.

Baby monitors (firmID=8, model Baby6 and variants) deliver alert images with the .jpgx3 extension instead of .jpg. .jpgx3 is a JPEG with the first 1024 bytes XOR'd against a 16-byte repeating key. Reverse engineered from libmrplayer.so (function mrxor_picdata).

The key:

key = MD5( "{SN}|{len(SN)}|[REDACTED]" )

The SN is broadcast in plaintext in the MQTT alert message that delivered the URL. It also leaks over OpenAPI (CVE-2026-33357).

Repro

import hashlib
sn  = "<SN_FROM_MQTT>"
key = hashlib.md5(f"{sn}|{len(sn)}|[REDACTED]".encode()).digest()
data = open("alert.jpgx3","rb").read()
out  = bytes(data[i] ^ key[i % 16] for i in range(min(1024, len(data)))) + data[1024:]
open("alert.jpg","wb").write(out)

The same key family (redacted) is used for the AES-IV in video and for BLE auth.

Scope

Every .jpgx3 artifact ever uploaded by a Meari-platform baby monitor is decryptable from public information. Cloud videos use the same XOR scheme on .tsx3 / .mp4x3 segments.

CVE-2026-33362 — Static Keys Across the Whole Ecosystem

CVSS 8.6 High — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N — CWE-321 Use of Hard-coded Cryptographic Key.

Every Meari-based app — CloudEdge, Arenti, BOIFUN, PetTec, SV3C, Joystek, Luvion, Vimar, and 300+ others sharing com.meari.sdk — ships with the same hardcoded keys.

Repro

apktool d com.meari.cloudedge.apk -o out/
grep -r "<HMAC-SECRET>\|<OPENAPI-KEY>\|<P2P-PASSWORD>" out/

The strings live in BuildConfig.smali, SdkConstants.smali, MeariIotManager.smali, and PPStrongManager.smali. Identical across versions, brands, devices.

Why this matters

These keys can't rotate without re-flashing every device in the field. Any single compromise is permanent, across the whole ecosystem.

Other findings (no CVE)

I dropped two findings from the CVE set on 2026-04-28 after re-test:

• Cloud video IDOR on POST /pps/v2/cloudstorage/video/detail. The endpoint returned resultCode: 1001 for ten foreign devices on March 8. On re-test, the code turned out to be a user-account subscription gate, not a per-device ownership check. Without a paid subscription on the test account I couldn't reconfirm against my own evidence. Withdrawn.
• CN production signature bypass on apis.meari.com.cn. Between March 2 and March 10 the CN endpoint accepted signature=AAAA and returned a valid userToken, while the EU endpoint returned 1018. The CN server was patched silently during the disclosure window. Re-test on March 23 confirmed both regions now reject invalid signatures. Withdrawn (patched).

A second set of findings, on Meari's own infrastructure, didn't get CVE numbers because they're operator misconfigurations, not product flaws. They shape the next section, so I'm listing them here for the record:

• Apollo Configuration Server at 118.31.20.61:8080, unauthenticated. 614 keys across 11 microservices: every production MySQL/MongoDB/Redis credential, an RSA-2048 private key used to unbind devices from customer accounts, two valid Facebook OAuth secrets, an Aliyun SMS access key capable of sending SMS as Meari to any number, and a corporate DingTalk access token covering 678 employees including the CEO.
• EMQX management dashboards (port 18083) running default admin:public across the US-West and EU-Frankfurt regions until disclosure.
• XXL-Job scheduler at xxl-hz.meari.com.cn running weak credentials ([REDACTED]:[REDACTED], the password being the framework default) with GLUE_SHELL mode enabled. I wrote a single non-destructive marker (echo XXL-JOB-PENTEST-MARKER) into one production job, triggered it, watched the marker appear in the log, and restored the original source. Proof of code execution on the production cron host (10.200.15.95) running 64 active jobs.
• PIS (Product Information System) backend at pis.meari.com.cn. Unauthenticated GET /back/v1/p2p/p2p_list paginates 1,160,795 P2P license records on the US backend and 98,250 on Hangzhou. Each row holds the per-device licence ID, relay password ([REDACTED]), and authentication keys for a direct P2P video session.
• CMS portal route table (portal.meari.com.cn/cms/portal/) carrying endpoints named camera/live, camera/playback, preview/start, stream/start, video/play, video/download, cloud/video/download, alarm/image, alarm/download, snapshot/list, snapshot/download. Not exploits. Features of the operator's own console.

The pattern, not the bugs

Five CVEs don't make a thesis. The pattern across the audit does. The MQTT broker that broadcasts every device's events to anyone with a free account. The static OpenAPI key in every APK that returns any device's WAN IP. The OSS bucket that holds every alert image with no expiry. The static keys that can't rotate without re-flashing a whole fleet. The operator console with camera/live and video/download as routes. None of this looks like a platform that took a wrong turn. It looks like a platform built to harvest customer data at scale, secured by defaults that nobody on the inside ever planned to rotate.

A patent filing called "A Method and System for Detecting and Translating Infant Crying Sounds" describes a model that fuses millimetre-wave radar from infants' bedrooms with matched audio from the same rooms. Training that model needs paired radar + audio traces from a deployed customer base of hundreds of thousands of cameras. The 2024 Zhejiang notice that found the company "continues to collect user data beyond necessary scope" and the 2026 audit that found the same data sitting on a public broker with no per-device subscribe ACL look like two views of the same architecture.

When I told Meari, the first response was that the affected products were "obsolete." The MQTT broker is still streaming.

A long-form take on all of this is being prepared for separate publication. Not here.

Disclosure Timeline

Initial discovery: 2026-03-02. From day one I emailed [email protected] (the mailbox was a guess — nothing about it was documented on Meari's sites) and DMed Meari engineering and security staff on LinkedIn. Nine days, zero replies on either channel. The mailbox finally answered on 2026-03-11. The negotiation that followed lasted 47 days and ended with a signed Vulnerability Disclosure Reward Agreement on 2026-04-28.

Full chronology with verbatim email quotes from [email protected] and the relevant articles of the signed agreement: DISCLOSURE_TIMELINE.md.

What didn't happen during the 70-day window between first contact attempt and publication:

• No GDPR Article 33 breach notification confirmed by any EU DPA.
• No GDPR Article 34 direct user notification. CloudEdge users have not been told.
• The Apollo configuration server at 118.31.20.61:8080 was still answering, intermittently, as recently as the last 14 days. The credentials changed. The decision to expose the service to the public internet didn't.
• The static keys (CVE-2026-33362) can't be rotated without re-flashing every device in the field.

If you own one of these cameras

If you own a CloudEdge camera, or one of the 300+ white-label brands sharing com.meari.sdk (Arenti, BOIFUN, COCOCAM, PetTec, SV3C, Joystek, Luvion, Vimar, etc.), this is you. Easier test: open your camera's app, check what hostname it talks to. If it's apis.meari.com.cn or mqtts*.meari.com.cn, this is you.

• The MQTT and OSS findings are platform-side. A firmware update on your device won't fix them. The fix has to come from Meari, on the broker. You can't do it from the camera.
• What you can do: physically unplug the camera when you're not using it. Pointed at a wall, it can't leak what it can't see.
• What you should not do: assume "it's password-protected" means it's not on a wildcard subscribe. The password protects you from logging in. It doesn't stop the broker from broadcasting your device's events to anyone with their own account.
• Baby monitors specifically (firmID=8, Baby6 family): every alert snapshot the camera ever uploaded is recoverable and decryptable from public information (CVE-2026-33359 + CVE-2026-33361). You can't delete those from the cloud as a customer. Retention policy is the vendor's.
• Doorbells: same as above for snapshots. Cloud video segments also broadcast on the same MQTT channel.
• EU residents wanting to file a GDPR complaint: relevant authorities are CNIL (France), AEPD (Spain), BfDI (Germany), Garante (Italy). The brand on your box doesn't change which authority is competent. Your country of residence does.

All testing was done from a single test account I registered myself, against publicly reachable infrastructure. The data quoted as scope (device counts, message counts, country counts, image counts) is reported in aggregate. Findings were communicated to the vendor on March 12, 2026 and coordinated through CISA VINCE Case VU#579666 and runZero from April 3, 2026 onward.