Aqara Cloud OAuth Flaw (CVE-2026-50090): What It Is and Whether You Are Affected
A critical vulnerability in Aqara’s cloud authentication infrastructure was publicly disclosed on 12 June 2026. If you saw a headline and want to know whether your home setup is at risk, the answer depends almost entirely on one thing: whether your Aqara devices talk to Aqara’s cloud at all.
If you run Zigbee2MQTT, ZHA, or the local HomeKit or Matter path, you are not in scope for this vulnerability. The flaw lives in a layer your setup never touches.
Here is what CVE-2026-50090 actually is, who it affects, and what the companion disclosures tell us about cloud-dependent smart home infrastructure.
What CVE-2026-50090 Is
The vulnerability sits in Aqara’s cloud OAuth authorization endpoint — specifically, the one that handles sign-in flows and third-party application permissions at open-cn.aqara.com/oauth/authorize.
OAuth is the protocol that lets a service confirm your identity to a third party without handing over your credentials. When you authorize a third-party app to access your Aqara account, the OAuth server sends an authorization code to a redirect URI — a URL that the app registered as its callback address. The vulnerability is in how Aqara’s server validates that redirect URI.
When a user initiates an OAuth flow, the client supplies a redirect_uri parameter. The server is supposed to verify that this URI matches one of the URIs the application registered. CVE-2026-50090, classified under CWE-1289, describes a flaw in how that comparison is performed. The server does not properly check that the supplied redirect target falls within an allowlisted domain, which means an attacker can craft a link that substitutes a malicious redirect destination.
In practice: a victim clicks what looks like a legitimate Aqara authentication link. The OAuth flow completes on Aqara’s server, but the authorization code gets sent to an attacker-controlled site instead of the legitimate app. The attacker can then use that code to access the victim’s Aqara account or any linked third-party integrations.
This is not a zero-interaction exploit. The victim has to click the crafted link. But it requires no authentication from the attacker, and it is network-accessible, which is why NIST’s CVSS scoring landed at 9.3 — critical severity. The “Changed Scope” modifier in that score reflects the downstream risk: a captured authorization code can affect resources beyond the immediate OAuth session, including any third-party integrations connected to the account.
Who Is Actually Affected
The flaw is in the cloud OAuth server. That is the relevant boundary.
Cloud-dependent setups are in scope. If your Aqara integration relies on Aqara’s cloud — for example, a Home Assistant cloud integration that authenticates via OAuth, or third-party apps that use Aqara’s developer API with OAuth flows — then the attack surface exists for you. You are trusting Aqara’s server to correctly validate redirect URIs, and that trust is currently misplaced given the unpatched state of the vulnerability.
Local setups are out of scope. Zigbee2MQTT, ZHA, Aqara’s local HomeKit bridge, and Matter direct commissioning do not route device commands or authentication through Aqara’s cloud OAuth server. The authorization endpoint at open-cn.aqara.com/oauth/authorize is simply not part of those protocol paths. The attack surface does not exist.
Our Aqara Hub E1 local integration guide walks through the E1 local integration setup, which is representative of why local paths avoid this class of vulnerability entirely.
As of the time of writing (2026-06-18), Aqara has not published patch notes or remediation confirmation in publicly indexed sources. I’ll update this post when a patch announcement appears. Do not assume the issue is resolved.
If you are reconsidering your setup architecture in light of this, our explainer on whether Aqara devices work without internet covers what actually stays local without any cloud access.
The Companion Vulnerabilities
CVE-2026-50090 was not disclosed in isolation. Two companion vulnerabilities came out of the same research batch.
CVE-2026-50084 (CVSS 9.6) describes a missing authorization check in Aqara’s cloud production API. The flaw allowed any valid developer token to access any user account — an authorization model failure, not just an OAuth redirect failure. Also cloud-infrastructure scoped.
CVE-2026-50091 involves hardcoded cryptographic keys in the Aqara Home Android SDK. Those keys could be used to impersonate camera authentication signatures and device pairing flows.
All three are cloud-infrastructure or SDK-layer vulnerabilities. None involve Zigbee firmware, Zigbee protocol, or hub-side firmware that affects local operation. Local users are outside the attack surface for all three.
The pattern across the three CVEs is consistent: they describe what happens when a cloud integration layer has inadequate input validation and authorization controls. That is not a Zigbee problem.
Why This Matters Even If You Are Unaffected
The word “unaffected” can breed complacency. What is more useful here is understanding why local-first architecture has concrete security implications, not just abstract privacy ones.
When your smart home does not route through a vendor’s OAuth server for normal operation, an entire class of credential-interception and token-hijacking attacks simply has no entry point. CVE-2026-50090 is a named, independently researched, CVSS-scored example of that class. Before this disclosure, the argument for local-first was partly philosophical — vendors could theoretically do bad things with cloud access, or their servers could theoretically have vulnerabilities. Now there is a specific CVE to point at.
This is not a reason to panic about Aqara. It is a reason to treat the local-versus-cloud choice as a security architecture decision, not just a privacy preference.
Our guide to putting Aqara and Xiaomi on an IoT VLAN covers network segmentation as a complementary layer — even for local setups, VLAN isolation limits what a compromised device can reach.
What to Do If You Use Aqara’s Cloud Integration
Keep this short: monitor Aqara’s official security channels for patch confirmation. Be cautious of any unsolicited link that prompts you to authenticate to an Aqara or Mi Home login page. If security and privacy are priorities, this is a reasonable moment to evaluate whether a local-only setup — via Zigbee2MQTT or ZHA — fits your situation. Our ZHA vs Zigbee2MQTT comparison may be a useful starting point.
For remediation steps specific to the cloud OAuth issue, check Aqara’s official security advisory when one appears. I won’t speculate on timelines.
The Bigger Picture
Security research finds vulnerabilities in cloud infrastructure regularly. That is not a failing unique to Aqara. The question for any smart home user is which parts of a vendor’s infrastructure they depend on, and what happens when those parts have problems.
The Aqara local APIs, Zigbee firmware, and Zigbee protocol itself were not implicated in any of these disclosures. The risk surface in CVE-2026-50090 and its companions is the cloud authentication and authorization layer — specifically, the code that handles credential flows, token issuance, and API access control.
If your setup bypasses that layer, you bypassed the risk. That is the architecture working as intended.
