Aqara IAM/SSO Gateway EUVD-2026-36477

Exploitation requires the victim to be authenticated to the Aqara IAM/SSO gateway (an active session cookie or token at gw-builder.aqara.com) AND to visit attacker-controlled web content in the same browser while that session is valid (UI:R). The attacker does not need credentials against Aqara (PR:N) and operates entirely through the victim's browser using a credentialed cross-origin XHR/fetch; no special Aqara account configuration is required, and the misconfiguration appears to be present in the default cloud deployment. Limiting factors: the victim must be logged in at the moment of visit, must not have third-party cookie blocking or strict SameSite enforcement preventing credentialed cross-origin requests, and the attacker must successfully deliver the malicious page (phishing or watering-hole), which constrains this from being a fully automated mass-exploit primitive.

The CVSS 8.2 with S:C and C:H is consistent with an SSO-layer CORS bug - confidentiality of cross-service identity data is high, integrity is limited (I:L, since the attacker primarily reads, not forges), and availability is unaffected. AV:N/AC:L/PR:N matches a browser-driven attack with no authentication on the gateway side, while UI:R correctly captures the need for a victim to visit attacker-controlled content. There is no EPSS score, no CISA KEV entry, and no SSVC decision provided, so prioritization rests on the CVSS vector plus the runZero advisory and the linked GitHub PoC. The realistic risk is moderate-to-high for individual Aqara users (credential/token theft enabling device control) but constrained by the requirement that a victim must be coaxed into loading attacker content while authenticated - this is a targeted-phishing class issue rather than a wormable internet-scale exploit, despite the network attack vector. Because this is a cloud-side defect, defenders cannot patch endpoints themselves; the only verifiable signal is the runZero advisory, and whether Aqara has deployed a server-side fix is not stated in the input.

An attacker hosts a malicious page and lures an Aqara user who is currently logged into the Aqara web portal to visit it (phishing email, malvertising, or a compromised forum post). The page issues a credentialed cross-origin fetch to gw-builder.aqara.com; because the gateway's CORS policy trusts the attacker's origin, the browser hands the authenticated SSO response - potentially including tokens, account identifiers, or linked-device data - back to attacker JavaScript, which exfiltrates it and uses it to pivot to smart-home device control. Public exploit code exists in the linked GitHub repository xn0tsa/theres-no-place-like-home.