Aqara Cloud CVE Chain (June 2026): What It Means for Local-First Users

On June 12, 2026, a set of CVEs against Aqara’s cloud infrastructure went public. Four of them chain together into something worth taking seriously: an unauthenticated attacker could register a developer account, mint an overprivileged token, reach into any Aqara user’s cloud account, and send commands to their devices. No password required, no phishing needed.

I’ve spent the last few days going through the runZero advisories and the NVD entries to figure out what actually happened and, more usefully, who’s exposed. Short version: if your Aqara devices talk to Aqara’s cloud, this affects you. If you’re running Zigbee2MQTT, ZHA, or a hub locked down to local-only operation, the attack chain has no path to reach you, architecturally rather than by luck. That distinction is the whole point of this article.

Eight CVEs, one attack chain

The researcher credited with discovery is Sammy Azdoufal, with coordination handled by Tod Beardsley at runZero. The disclosure timeline ran 90 days: initial vendor contact March 13, 2026, public release June 12, 2026. That’s standard responsible disclosure practice, not a drive-by drop.

The runZero research turned up a broader spread of findings across Aqara’s cloud and app surface. The eight CVE IDs below are the ones that matter for home users, and they don’t carry equal weight. Four of them (CVE-2026-50082 through 50085) chain into a full unauthenticated remote takeover path. The other four (50088, 50089, 50090, 50091) are real vulnerabilities but sit outside that core chain. I’ll get to what they actually do further down, because conflating them with the takeover path overstates some risks and understates others.

Here’s the set relevant to this article:

Worth knowing: CVE-2026-50082 looks unremarkable on its own at 6.5 Medium, because CVSS scores an individual flaw’s standalone impact. Its real severity only shows up once you see it as step one of a chain. That’s a recurring pattern in cloud IoT disclosures and one reason single-CVE severity scores can undersell chained risk.

How the attack chain actually works

I’ll walk through the four-step path in order, because the sequence matters for understanding why local-only setups sit outside it.

Step 1 — CVE-2026-50082. An attacker registers a developer account at developer.aqara.com using any email address. The portal issues a developer AppID without verifying the registrant is who they claim to be. This is the foothold, nothing more.

Step 2 — CVE-2026-50083. The IAM/SSO gateway at gw-builder.aqara.com contains a hardcoded OAuth client credential. Using the AppID from step 1, the attacker exchanges it for a scope=all OAuth token. No real user credentials are involved at any point; the hardcoded credential does the work.

Step 3 — CVE-2026-50084. This is the core flaw. The Production API at open-cn.aqara.com does check request signatures (MD5), but it never verifies that the token presented actually belongs to the account being accessed. A scope=all token from step 2 can read and write any Aqara user’s account: device state, automations, stored commands. The “cn” in the hostname doesn’t mean this is China-only infrastructure; it’s Aqara’s global cloud API endpoint, used by the Aqara Home app worldwide.

Step 4 — CVE-2026-50085. The Aqara Board service accepts arbitrary MQTT payloads and forwards them to the HiveMQ broker without authenticating the sender. Paired with account access from step 3, this gives the attacker a live command channel to cloud-connected devices.

Net effect: an unauthenticated remote attacker walks from “I have an email address” to “I can send commands to your Aqara devices” in four steps, none of which require compromising your password, your Wi-Fi, or your physical hub.

The other four CVEs matter but play different roles. CVE-2026-50088 (permissive CORS) opens the developer portal to cross-site exploitation. CVE-2026-50089 (open redirect on the SSO gateway) is a phishing vector: it makes malicious login links look legitimate. CVE-2026-50090 (lax OAuth redirect validation) enables session hijacking during the OAuth flow itself. All three are legitimate findings, but none of them is a required link in the unauthenticated takeover chain above. They’re separate attack surfaces on the same infrastructure.

CVE-2026-50091 is its own category entirely: two hardcoded cryptographic keys baked into liblumidevsdk.so, the native library shipped inside the Aqara Home Android app (version 6.0.0, package com.lumiunited.aqarahome). Those keys can compromise camera authentication signatures, impersonate device pairing flows, and decrypt content that’s supposed to be encrypted. Extraction doesn’t require root; basic reverse-engineering tooling gets you there. This is an app-binary problem, not a cloud-API problem, and it affects anyone with the app installed regardless of how their devices are networked.

Which Aqara setups are actually at risk

This is the part that matters for readers of this site, and it’s worth being precise instead of alarmist.

Exposed to the CVE-50082–50085 takeover chain:
– Any Aqara device paired through the Aqara Home app with cloud connectivity active
– Any setup where the Aqara hub still talks to open-cn.aqara.com, which is the default state for most Aqara hubs out of the box
– Aqara developer API users directly, via the CORS (50088) and open-redirect (50089) issues at the portal level

Not exposed to the takeover chain:
– Zigbee2MQTT users. Devices paired to a local Zigbee coordinator (a ZBDongle-E or similar) running Z2M never touch Aqara’s cloud. The four-step chain requires reaching devices through open-cn.aqara.com, and a Z2M setup has no such path to attack: the coordinator only speaks Zigbee to your devices and MQTT to your local broker.
– ZHA users. Same reasoning: local Zigbee radio, no cloud hop.
– HomeKit-local Aqara hubs, provided outbound internet is actually blocked at the firewall. If the hub can’t reach open-cn.aqara.com, the chain has nothing to command.
– Matter/Thread setups running on a local fabric with no Aqara cloud bridge in the path.

That “not exposed” list comes with a condition I want to underline, because it’s easy to gloss over: this protection is architectural, not permanent. If you factory-reset an Aqara hub and it re-registers with the cloud, or you remove an outbound firewall rule “just to test something,” the exposure comes right back. Local-only is a network posture you maintain, not a setting you flip once and forget.

CVE-2026-50091 cuts across all of this. It affects anyone running the Aqara Home Android app, independent of whether their devices are cloud-connected or local-only. If you’ve finished local setup and no longer need the app, uninstalling it removes this exposure entirely. If you’re still running it, say to occasionally check firmware versions, you’re carrying that risk on any network the phone connects to, not just your home Wi-Fi.

For the broader case on keeping this class of device off your main network, see our walkthrough on running Aqara and Xiaomi on an IoT VLAN with Home Assistant.

Has Aqara actually fixed this?

Here’s where I’d stop short of saying “patched, move on.” According to runZero’s coordination notes, Aqara told researchers fixes were implemented as of April 20, 2026 for most of the chain, with partial remediation for CVE-2026-50091 as of April 8, 2026. That’s the vendor’s claim, relayed through the researcher who coordinated disclosure, not something independently verified by a third party.

What I couldn’t find, as of this writing: any public Aqara security advisory, patch bulletin, or changelog entry referencing these CVEs. The NVD entries for the set don’t list patched version numbers, and searches of Aqara’s own site and developer portal turned up nothing acknowledging the disclosure.

That gap is not necessarily damning. Vendors sometimes fix quietly server-side without a public writeup, especially for cloud API issues that don’t require a client update. But “fixed server-side, unconfirmed publicly” is not the same as “confirmed safe,” and I’d rather tell you that plainly than round it up to “resolved.” If your devices are cloud-connected, I’d treat this as unresolved until Aqara says otherwise in writing.

If you’re already local-first, what do you actually need to do

Not much, which is the reassuring part.

• Z2M and ZHA users: nothing changes at the protocol level. Your devices were never reachable through this chain.
• Confirm your hub has no outbound cloud path, if you’re running an Aqara hub locally rather than a third-party coordinator. A quick check at the firewall, whether the hub’s IP shows any outbound connections to Aqara’s cloud ranges, settles it.
• Uninstall the Aqara Home Android app if your setup is done and you don’t need it day to day. That closes CVE-2026-50091 exposure entirely rather than leaving it conditional.
• Segment IoT traffic on its own VLAN if you haven’t already. Our IoT VLAN walkthrough covers the setup. This CVE chain is a good concrete example of why that segmentation earns its keep, not as theory but as a specific incident where it would have mattered.

One thing I’d flag from experience: when I audited my own setup after reading through these advisories, the friction wasn’t in the Zigbee layer at all. It was confirming that an old Aqara hub I’d kept around for a single unsupported sensor hadn’t quietly re-enabled cloud sync after a firmware update. It hadn’t, but the check took longer than I expected, because Aqara’s hub doesn’t surface its cloud-connection state anywhere obvious in the local admin interface. You have to infer it from firewall logs.

Why this matters beyond this specific chain

I think the more useful takeaway here isn’t “Aqara had a bad month.” Every cloud IoT vendor eventually turns up in a disclosure like this, and singling Aqara out for it would be unfair given how much of the industry runs comparable cloud architectures. The useful takeaway is narrower and more durable: cloud dependency is itself an attack surface, and every device you keep purely local is one less thing riding on the security posture of infrastructure you don’t control and can’t audit.

That’s not an argument for paranoia about any single vendor. It’s an argument for architecture. If you want to cut the Aqara cloud out of the loop entirely, our guide on running Aqara Zigbee devices in Home Assistant without the Aqara hub is the place to start.

Whether Aqara publishes a formal advisory acknowledging this chain is still an open question as of late June 2026, worth checking back on before you decide how much weight to put on the “already fixed” claim.