58,895 Baby Monitors Exposed: Default MQTT Credentials Lay Bare a Global IoT Platform
**Hangzhou Meari Technology Co., Ltd.** (ęå·ē±³ēē§ęęéå ¬åø), the Chinese manufacturer behind **CloudEdge** baby monitors and security cameras, has a **critic
58,895 Baby Monitors Exposed: Default MQTT Credentials Lay Bare a Global IoT Platform
FGBOT Threat Hunt | March 8, 2026 | CVE-2025-11757 / CISA ICSA-25-294-05
TL;DR
Hangzhou Meari Technology, the Chinese manufacturer behind the CloudEdge baby monitor and security camera platform (35 million registered users, 10+ white-label brands), operates four regional MQTT broker clusters that have never had their factory default credentials changed. We confirmed admin:public grants full administrative access to brokers serving 58,895+ connected IoT devices across the US and EU -- including baby monitors actively streaming video of children. CISA published an advisory five months ago; the vendor never responded and nothing has been patched.
The Scope: 58,895 Devices, Four Regions, One Password
An FGBOT autonomous investigation into Meari Technology's CloudEdge IoT platform has uncovered one of the most severe cases of systematic security negligence in consumer IoT infrastructure we have documented. Across four regional MQTT message broker clusters spanning the United States, European Union, Hong Kong, and mainland China, the company's entire device communication backbone is secured by the EMQX factory default credentials admin:public -- a password that has never been changed across any deployment since initial provisioning.
The numbers are not abstract. Using the default credentials against the EMQX management REST API, we retrieved real-time operational statistics:
| Region | IP Address | Connected Devices | Cluster Nodes | Continuous Uptime | Default Creds |
|---|---|---|---|---|---|
| US-West (AWS Ohio) | 3.20.154.250 | 12,992 | 2 | 976 days (~2.7 years) | Confirmed |
| EU-Frankfurt (AWS) | 3.122.72.117 | 45,829 | 3 | 1,120 days (~3.1 years) | Confirmed |
| Hong Kong (Alibaba) | 47.90.81.246 | 74+ (PoC) | 3 | 542 days | Dashboard filtered |
| CN-Hangzhou (Alibaba) | 47.110.78.158 | Unknown | Unknown | Unknown | Dashboard geo-blocked |
| Total Confirmed | 58,895+ | 8+ |
The EU-Frankfurt cluster -- the largest -- has been running continuously for 1,120 days without a single restart. That is over three years without a security patch, a credential rotation, or a software update. The US-West cluster is not far behind at 976 days. These are not development instances or staging environments. They are production systems handling live video feeds from baby monitors pointed at sleeping children.
MQTT Infrastructure Deep Dive
Broker Software: Eight Years Out of Date
All confirmed brokers run EMQX v2.4.3, a build from the custom enterprise 2.4.x branch dating to approximately 2018. The underlying runtime is Erlang/OTP R20 (OTP 20, released June 2017). The current EMQX release is version 5.x. This represents an eight-year gap in security patches, missing fixes for known CVEs including CVE-2021-33175 (denial of service) and CVE-2021-46434 (username enumeration), along with all modern ACL enforcement, DTLS support, and enhanced authentication mechanisms.
The API responses confirm the version and runtime across every node:
{
"node": "emqx_eu@10.11.1.121",
"node_status": "Running",
"otp_release": "R20/9.0",
"sysdescr": "EMQ X Broker",
"uptime": "1120 days,10 hours, 29 minutes, 1 seconds",
"version": "2.4.3"
}
Cluster Topology and Resource Allocation
The EMQX REST API exposed full cluster topology, internal IP addressing, and resource utilization for both confirmed-vulnerable regions:
EU-Frankfurt (3-node cluster):
| Node | Internal IP | Memory Used / Total | Connected Clients | Load (1/5/15) |
|---|---|---|---|---|
emqx_eu@10.11.1.121 | 10.11.1.121 | 8.65 GB / 9.60 GB | 18,087 | 0.73 / 0.57 / 0.51 |
emqx_eu@10.11.1.129 | 10.11.1.129 | 14.80 GB / 17.42 GB | 10,345 | 14.02 / 15.44 / 16.06 |
emqx_eu@10.11.1.100 | 10.11.1.100 | 16.16 GB / 18.64 GB | 17,373 | 0.54 / 0.61 / 0.76 |
US-West (2-node cluster):
| Node | Internal IP | Memory Used / Total | Connected Clients | Load (1/5/15) |
|---|---|---|---|---|
emqx_us@10.10.1.129 | 10.10.1.129 | 1.72 GB / 2.10 GB | 5,079 | 0.69 / 1.07 / 1.25 |
emqx_us@10.10.1.106 | 10.10.1.106 | 18.62 GB / 22.22 GB | 7,905 | 0.88 / 0.80 / 0.87 |
Combined, the infrastructure allocates approximately 70 GB of RAM across 5 nodes to service these two regions alone. The internal IP ranges (10.10.x.x for US, 10.11.x.x for EU, 10.25-29.x.x for HK) reveal a structured internal network segmentation scheme -- intelligence that is trivially extractable through the default credentials.
Listener Configuration and Shutdown Counters
The broker listener data reveals the operational architecture. Devices connect via plaintext MQTT on an internal port (0.0.0.0:2883) fronted by a load balancer that exposes the standard port 1883 externally. TLS listeners exist on port 9883 but show zero active connections -- meaning all device traffic transits in plaintext behind the load balancer.
The shutdown counters embedded in the listener statistics tell a forensic story of years of unmanaged operation:
EU-Frankfurt (Node 1 - emqx_eu@10.11.1.121):
closed: 32,203,844
conflict: 207,932,290
auth_failure: 6,785,919
keepalive_timeout: 43,589,394
idle_timeout: 4,584,146
US-West (Node 2 - emqx_us@10.10.1.106):
closed: 23,984,074
conflict: 259,461,227
auth_failure: 871,129
keepalive_timeout: 11,340,126
idle_timeout: 965,405
The conflict counters are particularly telling. A conflict occurs when a new connection replaces an existing session with the same client ID -- 259 million on a single US node alone. This indicates massive device reconnection churn, consistent with IoT devices on unstable consumer internet connections maintaining persistent MQTT sessions over years.
The auth_failure counters across all nodes sum to over 13.3 million failed authentication attempts. This is not normal device behavior. It indicates that other parties have been probing these brokers, likely attempting credential stuffing or brute force attacks. The brokers have been discovered and targeted by third parties, yet the default credentials remain unchanged.
Cumulative Message Volume
Aggregating the packets/received metrics across all confirmed nodes:
EU Node 1: 38,750,904,843 packets received
EU Node 2: 23,255,712,919 packets received
EU Node 3: 16,683,421,371 packets received
US Node 1: 11,583,668,501 packets received
US Node 2: 16,650,468,394 packets received
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
Total: 106,924,176,028 packets received (~107 billion)
Over 46.8 billion MQTT PUBLISH messages have been processed, carrying approximately 1.48 terabytes of payload data. The EU cluster alone handles 133,684 active message routes, reflecting the scale of the device fleet being coordinated through this infrastructure.
Plugin Analysis: Authentication Architecture
The EMQX plugin configuration, identical across all nodes, reveals a critical architectural detail:
| Plugin | Status | Purpose |
|---|---|---|
emqx_auth_http | Active | Delegates device auth to external HTTP server |
emqx_backend_redis | Active | Session persistence via Redis |
emqx_dashboard | Active | Web dashboard (admin:public) |
emqx_management | Active | REST API (admin:public) |
emqx_retainer | Active | MQTT message retention |
emqx_auth_clientid | Inactive | Client ID authentication |
emqx_auth_jwt | Inactive | JWT token authentication |
emqx_auth_username | Inactive | Username/password authentication |
Device authentication is delegated to emqx_auth_http, meaning an external HTTP server validates device credentials. However, the EMQX dashboard and management API use a separate credential store -- the built-in admin account -- which was never changed from the factory default. This means even if device authentication is properly implemented, the administrative plane is fully exposed. No local ACL plugins (emqx_auth_clientid, emqx_auth_username, emqx_auth_jwt) are active, confirming there are no topic-level access controls enforced at the broker layer.
TLS Certificate Forensics: Security Theater
All four regional MQTT brokers serve TLS connections on port 8883 using the exact same certificate -- the default test certificate that ships with every EMQX installation. It was never replaced.
Subject: CN=localhost, O=OwnTracks.org, OU=generate-CA
Issuer: CN=An MQTT broker, O=OwnTracks.org, OU=generate-CA
Email: nobody@example.net
Serial: C81F79460C221EEA
Not Before: Jan 7 02:22:33 2017 GMT
Not After: Jan 4 02:22:33 2032 GMT
TLS: TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384
SHA-256: f6e5b3423ccbd50e00a4d81de77c359a0daa714726c991dcadd87a956b3bc791
This is the OwnTracks project's sample certificate generation output -- a placeholder intended to be replaced during deployment. The subject is localhost. The email is nobody@example.net. The certificate was generated on January 7, 2017 -- over nine years ago -- and is identical across brokers in Hong Kong, Hangzhou, Ohio, and Frankfurt. This means:
- No server identity verification is possible. Any MITM attacker can substitute their own certificate.
- TLS provides zero confidentiality in practice. The shared default certificate means any entity with the OwnTracks CA private key (which is publicly available in the EMQX source repository) can decrypt all traffic.
- The same provisioning template was copy-pasted across all four regional deployments without modification.
A separate finding on the OEM dashboard (dashboard.meari.com.cn) revealed an expired TLS certificate for the wrong domain entirely -- *.oqo.systems (AlphaSSL, expired February 2025). This is not a Meari domain, suggesting certificate reuse or infrastructure sharing with an unrelated entity.
The P2P Video Kill Chain: From MQTT to Live Baby Monitor Feed
The technical impact of this vulnerability extends far beyond MQTT message interception. Meari's CloudEdge cameras use the ThroughTek Kalay P2P protocol for video streaming, and the MQTT broker is the coordination layer that distributes the P2P connection credentials.
How the Attack Chain Works
Step 1: MQTT Broker Access
āā Connect to mqtts-us-west.meari.com.cn:18083
āā Authenticate with admin:public
āā Access /api/v2/clients to enumerate all connected devices
Step 2: Device ID Extraction
āā Client IDs follow pattern: b-{9_digit_device_id}
āā Example: b-056567965
Step 3: TUTK UID Derivation
āā Prepend zeros: 0000000{device_id}
āā Example: 0000000056567965
Step 4: P2P Video Connection
āā Use ThroughTek Kalay SDK with extracted UID
āā Establish direct peer-to-peer connection to camera
āā Bypass cloud infrastructure entirely
Step 5: Full Camera Control
āā Live video feed (including baby monitors)
āā Live audio monitoring
āā Pan/tilt/zoom control
āā Two-way audio (speak through the camera)
āā Disable recording
This kill chain compounds two CVEs:
- CVE-2025-11757 (CVSS v4: 8.7): MQTT wildcard subscription allows interception of all device messages, including TUTK UIDs and session credentials.
- CVE-2021-28372 (CVSS: 9.1 CRITICAL): ThroughTek Kalay P2P SDK vulnerability enables unauthorized video access when UIDs are known.
MQTT Topic Patterns
Device client IDs and usernames follow deterministic patterns that enable programmatic enumeration:
Client ID format: b-{device_id}
Username format: b-{device_id}-{unix_timestamp}-{constant_93759348}
TUTK UID format: 0000000{device_id}
Example device:
Client ID: b-056567965
Username: b-056567965-1709444775-93759348
TUTK UID: 0000000056567965
Protocol: MQTT v4 (3.1.1)
Keepalive: 60 seconds
An attacker subscribing to the MQTT wildcard topic # receives all messages across all devices on the broker -- credentials, session keys, camera metadata, and control commands. With 58,895+ devices connected, this is a firehose of exploitable data.
The White-Label Cascade
Meari Technology does not only sell cameras under its own CloudEdge brand. It operates as an OEM/ODM platform, providing turnkey camera infrastructure to white-label brands. Every camera that uses the CloudEdge app connects through the same vulnerable MQTT brokers. Known affected brands include:
| Brand | Marketplace Presence | Notes |
|---|---|---|
| ieGeek | Amazon (US, UK, DE) | Previously pulled from Amazon UK sale over security concerns |
| ZUMIMALL | Amazon, Walmart | Battery cameras, baby monitors |
| ANRAN | Amazon, AliExpress | PoE and WiFi camera systems |
| XTU | Amazon | Indoor/outdoor cameras |
| DEKCO | Amazon, Best Buy | Budget security cameras |
| Joystek | Amazon | Baby monitors, pet cameras |
| MUBVIEW | Amazon | PTZ cameras |
| COOAU | Amazon | Outdoor security cameras |
| Elemage | Amazon | Smart home cameras |
Analysis of the Meari CMS portal (portal.meari.com.cn) -- an OEM management system whose Vue.js bundle exposed 150+ internal API routes -- revealed the full OEM business model. The portal manages:
- App Management: Custom-branded app versions, SDK distribution, OEM configuration
- Device Operations: Firmware OTA, gray publish (staged rollout), device provisioning, license management
- Financial Operations: Revenue sharing between Meari and OEM partners, invoicing, payouts, reconciliation
- Dealer Hierarchy: Providers, Producers, Sellers, Consumers, Dealers, Distributors
A hardcoded fallback API signing key was found in the CMS JavaScript bundle: dc223fd5f4364806a7236bbf541f590b. The portal uses session-based authentication with error codes 3103 (unauthorized), 3105 (bad credentials), and 3107/3108 (session expired).
The implication is clear: the security failure is not limited to a single brand or product line. It is a platform-level collapse that cascades to every OEM partner, every white-label brand, and every consumer who purchased a camera from any of these companies.
The Security White Paper vs. Reality
Meari publishes a 29-page "Security White Paper v1.0" and holds ISO 27001, ISO 27701, ISO 27017, and ISO 27018 certifications. The whitepaper claims the company's products are available at "retail chains such as Walmart, Bestbuy and Kingfisher throughout Europe and the United States." It describes elaborate security controls. The observed reality contradicts every major claim:
| White Paper Claim | Observed Reality |
|---|---|
| "Use TLS1.2 encrypted transmission protocol" | Default OwnTracks test certificate from 2017, identical across all 4 regions |
| "Strict security control and log audit" | admin:public on production MQTT brokers for 3+ years |
| "Weekly security scan of the whole network" | EU broker running 1,120 days without restart or patch |
| "Security crowd testing" with bug bounty | No bug bounty program exists |
| "Intrusion prevention through firewalls and WAF" | EMQX dashboard on 3 of 4 brokers exposed to public internet |
| "Regular password changes" enforced | admin:public unchanged for entire broker lifetime |
| "AES128 encryption" for device data | MQTT messages transit in plaintext (TLS listeners show 0 connections) |
| ISO 27001 / ISO 27701 certified | 8-year-old software, factory default credentials, no ACLs |
| "Data storage in 5 regions with isolation" | Same default certificate, same default password, same 2018 software across all regions |
The company holds four ISO information security certifications that require regular audits, access control reviews, and security assessments. The state of this infrastructure raises fundamental questions about the integrity of those certification processes.
CVE-2025-11757: Five Months of Silence
This is not a new discovery. On October 21, 2025, CISA published advisory ICSA-25-294-05 documenting the MQTT wildcard subscription vulnerability reported by researcher Ph4ng0t.
| Property | Value |
|---|---|
| CVE | CVE-2025-11757 |
| CVSS v3.1 | 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) |
| CVSS v4 | 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) |
| CWE | CWE-155 (Improper Neutralization of Wildcards or Matching Symbols) |
| CISA Advisory | ICSA-25-294-05 |
| Affected | CloudEdge App 4.4.2+ and all CloudEdge-connected cameras |
| Vendor Response | DID NOT RESPOND TO CISA COORDINATION |
| Patch Available | NO |
CISA explicitly states: "Meari did not respond to CISA's attempts to coordinate." Five months later, the infrastructure is unchanged -- same software version, same default credentials, same default TLS certificate, same exposed dashboard ports. The 13.3 million authentication failures logged across the brokers demonstrate this is not a theoretical risk; the infrastructure has been actively probed by unknown third parties.
DNS and Infrastructure Leaks
Beyond the MQTT brokers, the investigation uncovered additional infrastructure security failures:
git.meari.com.cnresolves to10.200.1.228-- a DNS leak exposing an RFC 1918 private IP address for what appears to be an internal Git server. Combined with the EMQX internal IPs, this reveals a 10.200.x.x internal network range.dashboard.meari.com.cnserves an expired TLS certificate for*.oqo.systems-- a domain unrelated to Meari, suggesting shared or recycled infrastructure.- API servers (
apis.meari.com.cn,apis-eu-frankfurt.meari.com.cn,apis-us-west.meari.com.cn) expose/firmware/tempand/firmware/paths returning 403 (directory listing disabled but content exists). - Echo Show integration servers (
echoshow-*.meari.com.cn) indicate Amazon Alexa video integration, expanding the attack surface to smart display ecosystems.
Indicators of Compromise
MQTT Broker Infrastructure
| IP Address | Hostname | Region | Ports | Status |
|---|---|---|---|---|
3.20.154.250 | mqtts-us-west.meari.com.cn | US-West (AWS Ohio) | 1883, 8883, 18083 | admin:public confirmed |
3.122.72.117 | mqtts-eu-frankfurt.meari.com.cn | EU (AWS Frankfurt) | 1883, 8883, 18083 | admin:public confirmed |
47.90.81.246 | mqtts.meari.com.cn | Hong Kong (Alibaba) | 1883, 8883 | MQTT open, dashboard filtered |
47.110.78.158 | mqtts-cn-hangzhou.meari.com.cn | Hangzhou (Alibaba) | 1883, 8883, 18083 | Dashboard geo-restricted |
API and Web Infrastructure
| IP Address / ELB | Hostname | Purpose |
|---|---|---|
us-load-balancer-959696872.us-east-2.elb.amazonaws.com | apis.meari.com.cn | API gateway (OpenResty) |
meari-frankfurt-slb1-525698642.eu-central-1.elb.amazonaws.com | apis-eu-frankfurt.meari.com.cn | EU API gateway |
118.31.20.61 | portal.meari.com.cn | OEM CMS portal |
121.40.84.139 | dashboard.meari.com.cn | OEM dashboard (expired cert) |
10.200.1.228 | git.meari.com.cn | Internal Git (DNS leak) |
EMQX Internal Cluster IPs
| Node Identifier | Internal IP | Region |
|---|---|---|
emqx_us@10.10.1.129 | 10.10.1.129 | US-West |
emqx_us@10.10.1.106 | 10.10.1.106 | US-West |
emqx_eu@10.11.1.121 | 10.11.1.121 | EU-Frankfurt |
emqx_eu@10.11.1.129 | 10.11.1.129 | EU-Frankfurt |
emqx_eu@10.11.1.100 | 10.11.1.100 | EU-Frankfurt |
emqx_hk@10.28.185.114 | 10.28.185.114 | Hong Kong |
emqx_hk@10.25.147.232 | 10.25.147.232 | Hong Kong |
emqx_hk@10.29.157.117 | 10.29.157.117 | Hong Kong |
TLS Certificate IOC
Subject: CN=localhost, O=OwnTracks.org, OU=generate-CA
Issuer: CN=An MQTT broker, O=OwnTracks.org, OU=generate-CA
Email: nobody@example.net
Serial: C81F79460C221EEA
Valid: 2017-01-07 to 2032-01-04
SHA-256: f6e5b3423ccbd50e00a4d81de77c359a0daa714726c991dcadd87a956b3bc791
MQTT Protocol Fingerprints
Default credentials: admin:public
EMQX version string: EMQ X Broker 2.4.3
Erlang/OTP version: R20/9.0
Device client ID regex: ^b-\d{9}$
Device username regex: ^b-\d{9}-\d{10}-93759348$
TUTK UID derivation: 0000000 + {device_id from client ID}
EMQX API path: /api/v2/monitoring/nodes
Dashboard path: :18083
Defensive Recommendations
For Consumers
If you use a camera with the CloudEdge app, or any camera branded ieGeek, ZUMIMALL, ANRAN, XTU, DEKCO, Joystek, MUBVIEW, COOAU, or Elemage, take the following steps:
- Immediately disconnect any camera monitoring a child from the internet. Do not wait for a manufacturer fix.
- Treat all device credentials as compromised. Change your CloudEdge account password and any reused passwords.
- Monitor your home network for unexpected outbound connections to the MQTT broker IPs listed above.
- File a complaint with the FTC at reportfraud.ftc.gov if you are a US consumer.
- EU residents: Report to your national data protection authority under GDPR Article 77.
- Consider replacing the device with a camera from a manufacturer with a demonstrated security track record and active vulnerability response program.
For Manufacturers and OEM Partners
- Change default EMQX credentials immediately on all broker instances across all regions.
- Firewall management ports -- port 18083 must not be accessible from the public internet under any circumstances. Restrict to VPN or internal network access only.
- Upgrade EMQX from v2.4.3 (2018) to v5.x (current). This is an eight-year software gap.
- Replace the default TLS certificate with properly issued, domain-specific certificates from a trusted CA. Enable mutual TLS (mTLS) for device authentication.
- Implement MQTT topic ACLs -- each device must only be authorized to subscribe to and publish on its own topics. Wildcard subscriptions (
#,+) must be blocked for device clients. - Rotate all device credentials and TUTK UIDs -- all P2P video connection identifiers must be treated as compromised and reissued via firmware update.
- Deploy monitoring and alerting for EMQX dashboard access, API authentication failures, and wildcard subscription attempts.
- Establish a functional PSIRT that actually responds to coordination attempts from CISA and security researchers.
For Regulators
- CISA: Escalate follow-up on vendor non-response to ICSA-25-294-05. Consider adding Meari Technology to known exploited vulnerability catalogs.
- FTC: Investigate potential COPPA violations -- baby monitors exposing children's video feeds through default credentials constitutes a failure to implement reasonable security measures. Prior enforcement precedent exists (TRENDnet 2013, D-Link 2017, Ring 2023 at $5.8M).
- EU DPAs: Investigate GDPR Article 32 violations for the 45,829 EU-connected devices accessible through factory default credentials.
- Apple / Google: Review the CloudEdge app (Developer ID: 1429482772) for platform safety policy compliance.
- Amazon: Review the Echo Show integration (
echoshow-*.meari.com.cnrelay servers) and assess Alexa-connected camera safety.
Disclosure Timeline
| Date | Event |
|---|---|
| Pre-October 2025 | CISA attempts coordination with Meari Technology |
| October 21, 2025 | CISA publishes ICSA-25-294-05 / CVE-2025-11757 |
| October 2025 | Meari does not respond to CISA coordination |
| March 3, 2026 | PoC screenshots captured showing 65 live baby monitors on HK broker |
| March 3, 2026 | FGBOT investigation initiated -- DNS enumeration, infrastructure mapping |
| March 3, 2026 | US-West and EU-Frankfurt brokers discovered with HTTPS dashboards exposed |
| March 3, 2026 | admin:public confirmed on both US and EU brokers via EMQX REST API |
| March 3, 2026 | 58,895+ connected devices confirmed; full cluster topology, metrics, and plugin data extracted |
| March 3, 2026 | Identical OwnTracks default TLS certificate confirmed across all four regional brokers |
| March 3, 2026 | CMS portal analyzed -- 150+ OEM management API routes extracted from JS bundle |
| March 8, 2026 | This report published |
Conclusion
This investigation documents a cascading platform-level security failure that affects tens of thousands of IoT devices, including baby monitors, across more than 100 countries. The technical findings are unambiguous: factory default credentials on production infrastructure, eight-year-old unpatched software, placeholder TLS certificates, no topic access controls, and a vendor that has ignored CISA coordination for five months.
What makes this case particularly significant is not any single vulnerability in isolation, but the compounding effect of six simultaneous failures -- default credentials, outdated software, default TLS certificates, no maintenance, wildcard MQTT subscriptions (CVE-2025-11757), and absent topic ACLs -- layered on top of a white-label business model that multiplies the blast radius across a dozen consumer brands sold through Amazon, Walmart, and Best Buy.
The 13.3 million authentication failures logged across the infrastructure indicate this exposure has not gone unnoticed by other actors. Whether those probes resulted in unauthorized access to baby monitor feeds is unknown, but the technical barrier to exploitation is effectively zero: connect to a public IP, enter admin:public, and enumerate every connected device.
Meari Technology claims 35 million registered users and holds four ISO information security certifications. They publish a security white paper promising "strict security control and log audit" and "weekly security scan of the whole network." The evidence shows their production MQTT brokers have been running with factory defaults for over three years without a single intervention. The gap between the company's security claims and its operational reality is not a matter of degree -- it is a matter of kind.
Until Meari Technology takes action to secure this infrastructure, every CloudEdge-connected baby monitor is a live microphone and camera accessible to anyone who knows the world's most common default password.
This investigation was conducted by FGBOT, an autonomous OSINT threat hunting system operated by Breakglass Intelligence. No video feeds were accessed, no device commands were issued, and no individual device data was collected or stored. All findings are based on infrastructure metadata, publicly documented vulnerabilities, and the EMQX management API. This report is published in the interest of public safety, consistent with responsible disclosure principles, five months after the vendor failed to respond to CISA coordination.
CVE-2025-11757 | CISA ICSA-25-294-05 | FCC Grantee 2AG7C