Sammy Azdoufal

The AI skill upload endpoint, served by the FastAPI AI inference and profiling services, lacks authentication and does not restrict uploaded file paths. This allows an unauthenticated remote attacker to perform path traversal—a method of accessing files and directories that are stored outside the web root folder—to write arbitrary files and tamper with AI skill files used by the robots.

The EnergizeLab AI Station (RK3562) firmware image ships with default root credentials and SSH enabled. An attacker with network access to the device can log in as root and take full control of it.

The EnergizeLab Eilik NestJS auth service issues device tokens for arbitrary robot serial numbers without authentication. An unauthenticated remote attacker can obtain a valid device token for any serial number and act as that device against the cloud services.

The EnergizeLab FirmwareUpdater (AArch64 ELF, distributed in the CDN bin.zip) uses a single hard-coded AES key shared by all installations. An attacker who recovers the key from the updater can decrypt and forge firmware packages for any device that trusts it.

EnergizeLab AI Station firmware, EilikO Linux robot firmware v2.1 20260617182218 release, and the EnergizeLab Windows desktop app 3.1.2 download firmware updates over plain HTTP and do not verify their integrity or authenticity. An attacker able to intercept or modify the traffic can substitute a malicious update.

Low-privilege registered accounts can read arbitrary files from the server by providing a controlled file path. This issue allows unauthorized access to middleware files and server secrets.

The FastAPI AI inference and profiling services lack authentication for AI model administration functions. This allows an unauthenticated remote attacker to modify the AI model configuration and change the active model during runtime.

Insufficient authorization checks on administrative APIs allow authenticated users with low privileges to perform unauthorized actions. This includes the ability to retrieve AI provider keys and modify system configurations and object-store contents.

The EnergizeLab Eilik NestJS auth service accepts a user-controlled user ID in account update requests (mass assignment). A registered user can set another account's identifier and take over that account.

Aqara Home Android (com.lumiunited.aqarahome) and white-label clients embedding the `liblumidevsdk.so` library use hard-coded cryptographic keys. This occurs when a developer embeds a secret key directly into the source code, which can be extracted by an attacker to decrypt sensitive data or authenticate as a legitimate entity.

The IAM/SSO gateway at 'gw-builder.aqara.com' exposes an unauthenticated AES oracle, allowing bidirectional AES round-trips against the platform's signing key. This occurs due to missing authentication for a critical function and the use of a broken or risky cryptographic algorithm.

The Aqara IAM/SSO gateway at 'gw-builder.aqara.com' contains a cross-origin resource sharing issue. This is a permissive cross-domain policy with untrusted domains, which allows a website to make requests to a different domain than the one that served the original page.

The Aqara Developer Portal (developer.aqara.com) and shared test environments (developer-test.aqara.com, aiot-test.aqara.com) exhibit permissive cross-origin request sharing. This is an instance of a permissive cross-domain policy with untrusted domains, which allows requests from unauthorized origins to access resources.

The Aqara IAM/SSO Gateway at 'gw-builder.aqara.com' contains an open redirect. This issue allows the system to redirect users to untrusted external sites, which can be leveraged to facilitate phishing attacks.

The OAuth Authorization Endpoint "open-cn.aqara.com/oauth/authorize" is subject to a redirect bypass caused by improper validation of unsafe equivalence in input. This flaw allows for domain matching bypass, which can be leveraged to facilitate phishing attacks and session theft.

🚨 CVE-2026-50082 The Aqara Cloud Developer Portal (developer.aqara.com) issued a developer token to any email address supplied by the attacker. This is an instance of "CWE-306: Missing Authentication for Critical Function" with an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (6.5 Medium). When combined with CVE-2026-50083, CVE-2026-50084, and CVE-2026-50085, any otherwise-unauthenticated attacker could execute a full takeover of affected devices. 🎖@cveNotify

The Aqara IAM/SSO Gateway at the endpoint 'gw-builder.aqara.com' uses a hardcoded OAuth client credential. This flaw can be combined with other issues to allow a fully unauthenticated remote takeover of affected devices.

The Aqara Cloud Production API at the endpoint 'open-cn.aqara.com/v3.0/open/api' fails to properly authorize requests, allowing any valid developer token to access any account. This missing authorization can be combined with other issues to enable a fully unauthenticated remote takeover of affected devices.

The Aqara Board service at the endpoint "op-test.aqara.com" accepts arbitrary MQTT command payloads and forwards them to the platform's HiveMQ broker without authentication. This missing authentication for a critical function allows for unauthenticated MQTT command injection. When combined with other flaws, this can lead to a complete remote takeover of affected devices.

Meari client applications embedding "com.meari.sdk" contain a server-side authorization failure. An attacker can abuse the integrated call path to 'openapi-euce.mearicloud.com' to retrieve the WAN IP address of arbitrary devices using their serial number. This is possible because the 'GET /openapi/device/status' endpoint does not require user authentication and utilizes a hardcoded signing key present in all public Meari-based applications. This issue is an Insecure Direct Object Reference (IDOR), which occurs when an application provides direct access to objects based on user-supplied input.