1.1 Million Cameras, One Wildcard: The MQTT Failure That Turns Every Smart Home Into a Broadcast Studio
The message arrived from a colleague who had just become a parent. He had bought a baby monitor on Amazon — the kind of purchase that feels routine, bracketed by a few reviews and a glance at the star rating — and, like any sensible person, he asked whether it was actually safe. It's a question we all ask before plugging in a new device, and then we shrug and hope the brand name on the box knows what it's doing. That hope is now a multi-billion-dollar liability.
At DEF CON 34, a researcher presented the audit that answers the question with an unambiguous no. The presentation, titled "1.1 Million Cameras, One Wildcard: Architectural Surveillance in an IoT Cloud," pulled back the curtain on Meari Technology, a Hangzhou-based ODM that does not sell to consumers but powers the infrastructure beneath more than 300 white-label camera brands. The finding, cataloged as CVE-2026-33356, is stark: the MQTT broker at the center of Meari's cloud lacks per-device subscribe access control lists. Any authenticated CloudEdge account can subscribe to a 'meari/#' wildcard and watch every device on the platform in real time.
The researchers captured 14,204 messages from 2,117 distinct devices in five minutes. No privilege escalation. No sophisticated exploit chain. A registration page and a wildcard.
Logic is binary; intent is often ambiguous. The code here is unambiguous.
Meari is what the industry calls an ODM — an original design manufacturer. It builds the entire product stack: camera firmware, cloud backend, mobile applications. It then sells that stack to brands that put their logos on the hardware. If you have bought a camera from Arenti, BOIFUN, COCOCAM, PetTec, SV3C, Joystek, Luvion, or Vimar, you are not using those companies' technology. You are using Meari's infrastructure, wearing a brand's sticker. When a product carries a logo you recognize, you assume the company behind it built the device, secured the cloud, and reviewed the code. In the ODM model, that assumption is fiction. The brand is a purchase-order generator; the ODM owns the attack surface.
The scale of this operation changes how we should think about the risk. Meari reported 1.1 million registered devices across 118 countries. One point one million endpoints, all publishing to a shared MQTT topic namespace. All sharing a single broker architecture that, as disclosed, lacks the capacity to isolate any single device from any single subscriber. From a threat-modeling perspective, this is not 300 separate products with 300 separate security postures. It is one product with 300 masks, and the shared fabric is the weakest link.
The financial context is essential to understanding why this architecture exists. The global baby monitor market is valued at $1.87 billion, with the United States representing roughly $540 million of that demand. Meari itself went public on the Shenzhen ChiNext board in March 2025, and its share price doubled within two days. The company is not a marginal player; it is a public-market success story built on the back of a trust model that this disclosure proves invalid.
The business model is the vulnerability. An ODM wins contracts by maximizing features per dollar and minimizing time-to-market. Brands choose suppliers on price. Retailers list products on checkboxes. Security architecture is a cost center, and in a race to the bottom, it gets optimized away. That is not an excuse; it is a structural explanation for why 1.1 million cameras ended up on a broker with no per-device authorization.
I have spent years auditing smart contracts for a living, and I have learned to look for one thing before anything else: access control. The inheritance chain. The modifiers. The function visibility. The question of who can call what, and what happens when someone who is not the owner calls it anyway. That habit has made me unforgiving when reading disclosures like this one, because the pattern is always the same. Somewhere in the architecture, someone decided that authentication was sufficient and authorization was optional.
Let me break down how the Meari architecture actually works, because the disconnect between what the brands promise and what the protocol permits is the core story.
MQTT — Message Queuing Telemetry Transport — is a publish-subscribe protocol built for constrained devices. It is simple by design: devices publish messages to topics, applications subscribe to topics, and a broker routes messages between publisher and subscriber. The broker is the center of the universe. It is the middleman that knows which topics exist, which clients are connected, and who is allowed to receive what.
In Meari's implementation, cameras publish to topics beneath the 'meari/' namespace. An individual camera's topic might follow a hierarchical pattern with a device identifier appended. The owner's mobile application subscribes to that specific path. The broker is supposed to enforce that only the device owner's account can subscribe to that device's topics. This enforcement is the entire security model. It is the boundary between your nursery and the internet.
CVE-2026-33356 documents that this boundary does not exist. The broker lacks per-device subscribe ACLs. The 'meari/#' wildcard — the multi-level MQTT wildcard that matches every topic beneath the platform root — is accepted from any authenticated account.
I want to be precise about what a wildcard subscribe means, because many people who have never touched MQTT will underrate it. In the protocol, the '#' is not a metaphor. It is a literal subscription pattern that tells the broker, "deliver to me everything from this point downward." There is no filtering. There is no ownership check. There is no equivalent of "this user does not own this device." The broker processes the subscription and starts streaming.
This is architecturally equivalent to a Solidity contract where a critical function's visibility is public and the access-control modifier is missing entirely. I have seen this failure mode in production smart contracts. In late 2017, I spent 40 hours auditing an early fintech startup's ICO contract and found a reentrancy vulnerability in its withdrawal logic — a bug that could have drained $2 million in user funds. That vulnerability was a logic flaw in ordering: checks, effects, interactions, in the wrong sequence. The Meari flaw is more basic. The check does not exist at all.
In a correctly designed system, the broker resolves the subscriber's account identity, looks up the set of devices associated with that account, and rejects any subscription that falls outside that set. The Meari broker was apparently designed to route, not to enforce. The absence is structural. When you centralize 1.1 million devices under a single namespace, per-device ACLs are the only thing separating each customer's private feed from a public broadcast. And that separation was never implemented.
The attack chain is a case study in simplicity. Step one: obtain authenticated access to the CloudEdge platform. The disclosure does not suggest this is a sophisticated operation; an attacker can create an account, purchase a cheap device to obtain legitimate credentials, or use phishing and credential-stuffing to harvest existing ones. Step two: connect an MQTT client to the broker endpoint, discoverable from the mobile application or firmware configuration. Step three: subscribe to 'meari/#'. Step four: receive.
14,204 messages from 2,117 devices in five minutes. The rate matters. This is not a forensic snapshot delivered after the fact; it is a real-time stream. The attacker sees motion events as they fire, audio segments as they are captured, and video chunks as they are published. For all practical purposes, the attacker is an additional subscriber on the platform with access to every device.
Let me translate that into what it means for a family using one of these cameras. The camera on the bookshelf publishes throughout its operational lifetime. It publishes motion events when the child moves. It publishes telemetry when the device wakes, sleeps, or reconnects. It publishes audio and video content across the day. Every one of these messages is a data point in a behavioral graph. A sequence of motion events is a schedule. A silence followed by a wakeup is a sleep pattern. A recurring absence of motion is a signal that the house is empty. The attacker does not need to exploit the home network; the data is being delivered to them by the platform.
This is the detail that most coverage will miss: the value is not the individual frame, it is the pattern. When I analyzed Uniswap V2 liquidity provision in 2020, I ran 10,000 simulated price paths to quantify how passive positions failed to generate sufficient fee revenue in high-volatility regimes. The insight was that the distribution of outcomes matters more than the headline number. The same logic applies here. A few stolen minutes of video is a headline. A continuous behavioral stream of motion events, audio snippets, and device telemetry is a surveillance-grade dataset. The wildcard subscription provides the stream, and the patterns accumulate without any further attacker effort.
Now consider the AI-agent layer, because it is the compounding factor that turns a camera vulnerability into a home-automation takeover. These devices are being integrated into Alexa, Google Home, Home Assistant, and a new generation of AI agents. The camera is no longer a passive display; it is a sensory input to an autonomous system that makes decisions on the user's behalf. When the camera feed is compromised, the agent inherits the surveillance exposure. The attacker gains not just vision into the home but potential influence over the agent's decision-making, if the feed can be manipulated or replayed.
Trust breaks at the vision layer. This is the clearest way to describe the domino effect. An AI agent that trusts a compromised camera is an agent acting on attacker-controlled perception. It will turn on lights based on false motion. It will notify, or fail to notify, based on false presence. It will build its model of the world from inputs that an attacker can steer. The privacy violation is immediate; the autonomy violation is the next stage. We are handing our homes to agents, and we are handing our agents to architectures that cannot tell one subscriber from another.
The disclosure timeline adds a regulatory dimension that makes the story worse. The researcher coordinated a 70-day disclosure window with Tod Beardsley of runZero. That is a generous timeline, designed to give a vendor time to remediate before public exposure. Meari's response was to label the affected products as "obsolete."
Let's define what that means precisely. It means Meari refused to implement the fix. It means no firmware update will be issued. It means no broker-side access-control list will be deployed. The devices currently in consumers' homes will continue to operate exactly as they do today, streaming to a public namespace, with a wildcard subscription available to any authenticated account. Labeling a product obsolete is not a remediation. It is a legal dodge that transfers the cost of an architectural failure to the end user, who will now have to buy a replacement device to escape the vulnerability.
Meanwhile, the MQTT broker kept streaming.
And there is a detail in the researcher's GitHub disclosure timeline that deserves emphasis: there has been no confirmed GDPR Article 34 direct user notification. Article 34 is the provision of the General Data Protection Regulation that requires a data controller to notify affected individuals without undue delay when a breach is likely to result in a high risk to their rights and freedoms. A broker that allows any account to subscribe to every device topic is, by definition, a high-risk scenario. The absence of notification means the families relying on these devices have not been told that their feeds are accessible. They will discover the exposure if someone tells them, or they will never discover it at all.
I want to compare this with the Zbtlink ENDLESSDOORS disclosure, because the contrast sharpens the technical picture. ENDLESSDOORS targeted the infrastructure layer — the silicon and board support package — and raised serious concerns about hardware trust and supply-chain integrity. Meari's issue is categorically different. It requires no physical access, no compromised chip, no advanced boot-level exploitation. It is purely an authorization failure in the cloud control plane. This makes it easier to exploit and harder for the individual user to defend against, because the user has no control over the broker. The only defense is not to use the product.
Logic is binary; intent is often ambiguous. The Meari architecture is the physical manifestation of a trust assumption — the broker will enforce boundaries — and the code reveals the assumption was never implemented.
Let me also connect this to the financial architecture of decentralized systems, because there is a structural lesson for anyone who works with tokenized assets and real-world asset collateral. The ODM model is a centralized service layer underneath a fragmented brand surface. Each brand has its own app store listing, its own privacy policy, its own customer support channel. But the infrastructure is shared. If you assess the security of any single brand, you are examining a facade. The real attack surface lives in the shared fabric — the same lesson as examining a collection of DeFi protocols that all depend on one oracle provider or one liquidity aggregator. The economic incentives to secure the shared fabric are not distributed to the party who bears the cost. The result is systemic neglect that no individual brand is incentivized to fix. We are buying convenience at the cost of total exposure, and we are doing it because the market does not price the exposure at the point of sale.
Here is the counter-intuitive point: local-first is necessary but insufficient, and the security industry should say so loudly.
Every article following this disclosure will advise consumers to switch to Home Assistant or Matter-compatible, fully local devices. That advice is correct at the individual level and incomplete at the systemic level. The ODM model produces the same physical hardware for local-only and cloud-dependent versions. The chips come from the same fabs. The firmware is often the same codebase, with a feature flag that disables remote connectivity. The access-control failure in the cloud backend has a local equivalent: device firmware that trusts a shared secret, hardware that lacks a per-device root of trust, ecosystems where the local network is the new attack surface. A "local" camera with a default password is still a public broadcast in a different layer.
The deeper problem is liability. "Obsolete" is the supply chain's equivalent of a rug pull. The vendor declares an asset unsupported to avoid the obligation to patch. We do not accept car manufacturers releasing vehicles and then declaring them obsolete when a brake defect is found, without a recall. The consumer electronics industry operates outside that accountability, and it will continue to do so until regulators impose structural liability or purchase decisions incorporate security attestation as a first-class requirement.
The encryption question is also misdirected. Even if the camera payloads are encrypted end-to-end, the broker relays them to the authenticated subscriber. A wildcard subscription receives the keys and the ciphertext. The broker is the trust root, and this broker failed. No amount of transport-layer security repairs a broken authorization model. In blockchain terms: a protocol with a centralized sequencer is centralized, regardless of where the settlement happens.
The direction is clear. The future belongs to devices that can attest their own behavior — firmware that proves its hash, brokers that enforce per-device ACLs, and brands that face liability for the architecture beneath the sticker. Consumers should treat every smart home device as an unauthenticated subscriber until proven otherwise. And the blockchain industry, which has spent years arguing that code is trust, should recognize the Meari case as the physical-world version of a contract without access control.
Logic is binary; intent is often ambiguous. The wildcard is not. The question is whether the market will learn to read the authorization table before the subscriber does.