Aqara Smart Locks and Cameras Could Be Hijacked: Cloud Flaws Including CVE-2026-50083

A batch of 10 vulnerabilities in the cloud backend of smart-home maker Aqara has been disclosed, and several of them let someone operate other people's smart locks and cameras without ever logging in. The coordinated disclosure was handled by security firm runZero, and the CVE numbers run consecutively from CVE-2026-50083 through CVE-2026-50091.

Aqara sells Apple Home (HomeKit)- and Matter-compatible sensors, cameras, hubs, and smart locks across more than 190 countries and regions, with over 50 million cumulative device activations. It also began direct sales on Amazon Japan in February 2024, making its front-door smart locks and indoor cameras a familiar option in Japan too. The story here is that the cloud you trust with "the keys and eyes of your home" had holes that an unauthenticated outsider could step through.

Let's set the bottom line first. Most of these flaws stem from how the maker built its servers (the cloud), and the fixes were rolled out on the maker's side between April and June 2026. There is no report so far of any of this being used in a real attack against owners' devices — no confirmed exploitation, no abuse of the proof-of-concept code, and no entry in CISA's catalog of exploited vulnerabilities. Even so, finding authentication failures of this scale in devices tied to the physical safety of a home is not a small matter. Here is what happened and what owners should do.

An Overview of the 10 Flaws

Audited by researcher Sammy Azdoufal and coordinated by runZero's Tod Beardsley, the disclosure spans CVE-2026-50082 through 50091 — 10 in total. We focus on the 6 that the U.S. National Vulnerability Database (NVD) scored most severely. One caveat up front: the CVSS score for CVE-2026-50086 differs between NVD (10.0) and the original source runZero (7.5). This article uses runZero's rating (7.5) as the primary source and notes the discrepancy in the table.

The remaining four (CVE-2026-50082's unverified account registration, the loose cross-origin settings in 50087 and 50088, and the redirect abuse in 50089) are medium severity on their own, but they become important parts in the takeover chain described below.

The crux is that chaining CVE-2026-50083, 50084, and 50085 in sequence lets someone who is not a legitimate owner operate another person's smart lock or camera.

The CVSS numbers rate each flaw individually, but the real danger is that a chain you can start with no login at all was actually possible.

Who Wants This Bug, and What Do They Walk Off With

The most dangerous thing about these flaws is that the entry point requires nothing of the attacker — not even being a legitimate user. The threat isn't only some hacker in a distant country. An ex-partner, a persistent stalker, a burglar casing a home, a third party who wants to watch a child, a former housemate out for revenge — people already inside the victim's life are exactly the ones with a motive to seize this kind of "lock and surveillance." What they obtain is not some abstract "personal data." It is the unlock action on your front door itself, the video and audio from an indoor camera pointed at a bedroom or a child's room, the daily rhythm that reveals whether anyone is home, and the lock/unlock history. The moment the chain from CVE-2026-50083 to 50085 is walked, an unknown device unlocks your front door and a camera inside your home appears on a stranger's screen.

The damage downstream does not end at a data leak. Indoor camera footage becomes a burglar's preview of the floor plan and where the valuables are; in the wrong hands it becomes material for blackmail or stalking. Overlay the lock/unlock history with the at-home pattern, and a break-in timed precisely to when the house is empty can be assembled. Stolen account details and tokens get traded on the dark web and spread sideways into takeovers of other services where the same password was reused. A physical break-in and an online impersonation start moving from a single hole at the same time — that is what makes a breach of a home-device cloud distinct.

And almost none of this responsibility falls back on the owner. The cause is not a weak password chosen by the user but the very design of the cloud run by Aqara (operated by Lumi United Technology). Because these are devices close to household fixtures, a leak means the maker itself has to face breach notifications, reports to data-protection authorities, victim support, and the work of rebuilding trust. This kind of cost never appears in a CVSS number — it puts a price on a front-door key and the video inside a home, things money cannot buy back. That is precisely why whether you can take action in your own settings now is what decides a household's safety.

How Do Smart Locks and Cameras Actually Work?

When you hear "unlock my front door from my phone," it sounds like the phone and the lock talk directly. In reality they don't. Most smart-home devices operate through the maker's cloud (servers on the internet). When you tap "unlock" from outside, that command first reaches Aqara's cloud, the cloud confirms "this person is the rightful owner," and only then does it tell the lock at your home to open. Camera video works the same way, flowing through the cloud to your phone.

The flip side of this convenience is a clear weakness: if the cloud's "this is the rightful owner" check is loose, commands from someone who is not the owner get through too. You can put a sturdy lock on your front door, but if the receptionist (the cloud) that operates it remotely will obey anyone's order, the sturdiness of the lock means nothing. The flaws found here are exactly that kind of loose authentication in the "receptionist" cloud.

This is not the first accident of this shape. The researcher here, Sammy Azdoufal, is known for finding in February 2026 that roughly 7,000 DJI "Romo" robot vacuums across 24 countries could be controlled remotely. While trying to drive his own vacuum with a PS5 controller, he used the AI coding assistant "Claude Code" to analyze the cloud communication and found that the issued "auth token" treated him as a legitimate user of other people's vacuums too — reaching even their cameras and microphones. Aqara has the same root cause: a design in which a cloud token grants authority to people other than the rightful owner.

From No Login to Device Takeover in 4 Steps

The takeover flow the researcher demonstrated works in four steps starting from a state with no login at all. Here are just the technical highlights.

The token issued in Step 2 was the most symbolic part. According to the researcher, the cloud had a fixed credential "test1:123456" baked in; using it produced a token with "all permissions (scope=all)" and an expiry in 2083 — about 57 years, effectively unlimited. Worse, that token did not expire even when the user changed their password. In Step 3, because the production API's signature check accepts any developer ID, building a correct signature returns "code:2002 (accepted)." In the final Step 4, sending that signed command to the production API (CVE-2026-50084), or pushing a command straight into the messaging system from a debug endpoint that requires no authentication at all (CVE-2026-50085), lets the attacker operate smart locks, cameras, hubs, and various sensors on the platform.

The Individual Flaws

Here is each of the 6 higher-severity flaws and what went wrong.

CVE-2026-50083: A Fixed Password That Mints 57-Year Tokens (CVSS 9.1)

A fixed credential "test1:123456" was embedded in the auth backend (CWE-798: Use of Hard-coded Credentials). Anyone could use it to issue an all-permission token valid until 2083 that survived password changes. runZero's advisory positions this as the "get key" step of the takeover chain.

CVE-2026-50084: A Signature Flaw That Lets You Impersonate Others (CVSS 9.6)

The production API's signature check accepts a correctly formatted signature built with any developer ID, so an attacker could operate devices in another person's account (CWE-862: Missing Authorization). The researcher's proof script confirms "code:2002 (accepted)" for a correct signature and "code:302 (rejected)" for a wrong one. This one was reported as "still active" even at disclosure time in June, with no confirmed fix — making it the one to watch most among the six.

CVE-2026-50085: An Unauthenticated Debug Endpoint (CVSS 8.6)

A debug API that should have been for development and testing was exposed with no authentication, and through it an attacker could push commands directly into the device-bound messaging system (an MQTT broker) (CWE-306: Missing Authentication for Critical Function). At the time of the research, this debug endpoint reportedly held a log of 18,537 production requests, suggesting a test door was being used in live operation.

CVE-2026-50086: An Unauthenticated Encrypt/Decrypt Endpoint (CVSS 7.5; NVD 10.0)

The auth backend exposed AES encryption and decryption using the platform's signing key, callable by anyone with no authentication (runZero's advisory). It also used the old ECB mode, where identical plaintext always becomes identical ciphertext — a foothold for decrypting or forging captured tokens. As noted up front, the severity differs: runZero rates it 7.5 and NVD 10.0. The vector runZero gives affects only confidentiality (C:H/I:N/A:N), and this article uses the primary-source figure of 7.5.

CVE-2026-50090: A Weak Redirect Check That Hijacks Auth Codes (CVSS 9.3)

When linking login with an external service, the check on the "return destination after login (redirect_uri)" was a loose suffix match, so an attacker domain like aqara.com.evil.example.com was mistaken for a legitimate one (NVD, CWE-1289). If a user carelessly approves the link, the authorization code meant only for them is handed to the attacker, leading to takeover of the linked account.

CVE-2026-50091: An Encryption Key Baked Into the Mobile App (CVSS 9.1)

A library used internally by the Android app (com.lumiunited.aqarahome) had a hard-coded AES key (CWE-321: Use of Hard-coded Cryptographic Key). Anyone who analyzes the app can extract the same key, undermining the premise that the traffic cannot be read or forged. It is the only one of the six that touches what owners hold in their hands (the mobile app), and the countermeasure centers on the app update discussed below.

The "Numbers" Show How Wide the Exposure Was

The researcher's public materials record, in concrete numbers, how much information and how many accounts were visible from the outside. These are not figures about a real attack — they show the "unprotected surface" — but the scale cannot be ignored.

The fact that 2,969 active login sessions could be pulled at once — including two belonging to Aqara employees — speaks to a hole in the authentication design itself. And about 1.72 million CRM attachments reachable by sequential ID, with 9 in 10 actually existing, shows that personal information such as addresses and inquiry contents was in a nearly unprotected state.

The Maker's Response vs. the Researcher's Re-test

The path to disclosure includes a part where the maker's and the researcher's assessments do not match. Here is the sequence of events.

← swipe to move

The disagreement is over how far the fixes had progressed. On April 20, Aqara stated that "26 of the 27 findings are fixed" and invited the researcher to an independent re-test. The researcher's re-test, however, found that only some could be confirmed as definitely fixed, while several remained exploitable. In particular, CVE-2026-50084 (the signature-check flaw) was reported as "still active" via the proof script even at the time of disclosure. The reasonable stance is to hold both as the current state: the maker's account that it "fixed it," and the researcher's confirmation that it "still goes through."

For the record, there is no report at this time of this set of flaws being used in a real attack, and none are listed in CISA's "Known Exploited Vulnerabilities" catalog. Because most fixes are being made on the cloud side (servers invisible to users), there is basically no patching work for owners to perform.

What Should Aqara Owners Do?

Most of these holes are on the cloud side and are not something owners can close by hand. Still, there are a few precautions you can take. There is no need to panic, but because this involves your front-door key and the video inside your home, it is worth reviewing your settings once.

Above all, Android users should update the Aqara Home app to the latest version first, since it is the only one of the six that touches what owners hold. Changing your password and enabling two-factor authentication are basic measures that help for smart-home devices in general, not just this case. If you use a smart lock, it is reassuring to keep a physical-key fallback just in case.

A Technical View — The "Cloud Concentration" Risk Behind the Convenience

Seen individually, these 10 flaws — a fixed password, a loose signature check, an old cipher mode, insufficient validation of redirect destinations — are all textbook basics. The real problem is that they were concentrated in a single cloud and connected in a form that chains together with no identity check. Home IoT devices carry a structural tendency to defer the hard work of authentication in favor of low prices and fast feature additions.

The shape this researcher demonstrated with DJI's robot vacuums in February and Aqara here are strikingly alike. Both are authorization (who may do what) design mistakes in which a cloud-issued token grants authority beyond the rightful owner's scope. As long as smart appliances run through the cloud rather than on the phone alone, no matter how solid the device's own encryption is, a loose cloud reception loosens the whole. There is little owners can do, but from an engineer's perspective it is worth taking this chance to audit your own service's "scope of issued tokens," "test endpoints leaking into production," and "session expiry on password change."

Note that because this is not a flaw in a specific open-source component but the maker's own cloud implementation, a software bill of materials (SBOM) match cannot detect it. The realistic way to apply this is to inspect your own cloud's authentication and authorization flows in the same spirit.

Summary

Ten vulnerabilities were disclosed in the cloud backend of smart-home maker Aqara, several of which let someone operate smart locks and cameras without logging in. The crux is a chain: a fixed password could mint a 57-year token, a signature flaw allowed impersonation, and an unauthenticated debug endpoint could push commands straight to devices. Most fixes were made on the maker's side, and there is no report of real-world attacks at this time. Still, CVE-2026-50084 was reported as still active at disclosure, and a gap remains between the maker's "fixed" account and the researcher's re-test.

What owners can do are the basics: update the app, change passwords, enable two-factor authentication, check activity logs, and reconsider camera placement. Precisely because these devices hold your front-door key and the video inside your home, it is a case worth pausing on to confirm where, behind the convenience, you are placing your trust.

Sources

• ▸Sammy Azdoufal - theres-no-place-like-home (researcher materials, PoCs, exposure data)
• ▸runZero Advisory - Aqara Hardcoded OAuth Credentials (CVE-2026-50083)
• ▸runZero Advisory - Aqara Production API Access (CVE-2026-50084)
• ▸runZero Advisory - Aqara Board IoT Debug API (CVE-2026-50085)
• ▸runZero Advisory - Aqara Unauthenticated AES Oracle (CVE-2026-50086)
• ▸NVD - CVE-2026-50083 / 50084 / 50085 / 50086 / 50090 / 50091
• ▸PR TIMES - Aqara launches in Japan, sales begin on Amazon Japan (Lumi United Technology)
• ▸RNZ - The same researcher's DJI robot-vacuum remote-control case (Feb 2026)