Unauthenticated AES Oracle in Aqara IAM/SSO Gateway

A remote unauthenticated attacker can use the exposed AES oracle to perform arbitrary encryption and decryption operations under the platform's signing key. This can enable recovery of sensitive information derived from that key, misuse of the signing-key context for unauthorized cryptographic operations, and compromise of confidentiality for data protected by the affected mechanism. Given that the oracle is bidirectional and internet-accessible, the issue may also facilitate forgery or abuse of downstream trust decisions that rely on the same key material or encrypted artifacts, depending on how the signing key is used elsewhere in the Aqara platform.

Until a full fix is deployed, disable or firewall public access to the vulnerable gw-builder.aqara.com endpoints, restrict them to trusted administrative networks if operationally necessary, and monitor for requests indicative of oracle abuse. Apply WAF or API gateway rules to block unauthenticated access to the affected paths. As a precaution, rotate signing keys and invalidate tokens, signatures, or artifacts that may depend on the exposed key if there is any possibility the oracle was abused. Conduct log review for repeated chosen-input requests to the relevant endpoints.

Restrict access to the affected AES encrypt/decrypt endpoints by requiring strong authentication and authorization for any cryptographic operation involving platform key material. Remove any externally exposed oracle behavior that permits arbitrary client-supplied plaintext or ciphertext to be processed under sensitive keys. Rotate the affected platform signing key and any derived or related credentials after remediation, because prior unauthenticated access may have exposed key-dependent operations. Review all uses of the same key across the IAM/SSO and related services, and replace ECB-based constructions with a modern, purpose-appropriate cryptographic design that does not expose raw encryption/decryption primitives to untrusted callers.