CVE-2025-65290: Aqara Hub M2 Information Disclosure Flaw

CVE-2025-65290 Overview

CVE-2025-65290 is a certificate validation vulnerability affecting multiple Aqara Hub smart home devices. The affected hubs do not validate server certificates during HTTPS firmware downloads, allowing attackers positioned on the network path to intercept Over-The-Air (OTA) update traffic. An attacker performing a man-in-the-middle (MITM) attack can serve modified firmware images to the device. This weakness is categorized under CWE-295: Improper Certificate Validation. The flaw impacts Aqara Camera Hub G3 firmware 4.1.9_0027, Hub M2 firmware 4.3.6_0027, and Hub M3 firmware 4.3.6_0025. Successful exploitation can compromise both the confidentiality and integrity of firmware delivery to consumer IoT devices.

Critical Impact

Attackers on the network path can intercept OTA firmware downloads and deliver tampered firmware to Aqara Hub devices, enabling persistent device compromise.

Affected Products

• Aqara Camera Hub G3 firmware 4.1.9_0027
• Aqara Hub M2 firmware 4.3.6_0027
• Aqara Hub M3 firmware 4.3.6_0025

Discovery Timeline

• 2025-12-10 - CVE-2025-65290 published to NVD
• 2025-12-17 - Last updated in NVD database

Technical Details for CVE-2025-65290

Vulnerability Analysis

The vulnerability resides in the firmware update routine of the affected Aqara Hub devices. When the hub requests an OTA firmware image over HTTPS, the client implementation does not properly validate the TLS server certificate presented by the update endpoint. The Transport Layer Security (TLS) handshake completes without verifying certificate chain, hostname, or trust anchors. As a result, any certificate, including a self-signed or attacker-controlled certificate, is accepted as valid. This breaks the integrity and authentication guarantees that HTTPS is intended to provide for firmware distribution.

Root Cause

The root cause is improper certificate validation [CWE-295] in the HTTPS client used by the firmware updater. Either the device skips verification entirely or the verification callback returns success regardless of the certificate state. Firmware update channels require strict certificate pinning or full chain validation, and neither is enforced on the affected builds.

Attack Vector

Exploitation requires the attacker to occupy a network position between the device and the Aqara update servers. Suitable positions include compromised home routers, rogue Wi-Fi access points, ARP spoofing on the local network segment, or upstream network compromise. Once positioned, the attacker intercepts the HTTPS update request, presents an arbitrary TLS certificate, and serves a modified firmware payload. Because certificate validation is bypassed, the device proceeds with the download and may install attacker-supplied firmware if additional firmware signing checks are absent or also bypassed.

No verified public exploit code is available. See the GitHub PoC Repository for technical details documented by the reporter.

Detection Methods for CVE-2025-65290

Indicators of Compromise

• Unexpected outbound TLS connections from Aqara Hub devices to hosts that are not official Aqara update endpoints.
• TLS sessions from hub devices negotiated with certificates that are self-signed or issued by untrusted certificate authorities.
• Firmware version strings on hubs that do not match any official Aqara release manifest.
• Unusual device reboots or behavior changes immediately following an OTA update window.

Detection Strategies

• Inspect network flow records for HTTPS traffic from Aqara hubs and compare destination IPs and SNI fields against the vendor's known update infrastructure.
• Deploy passive TLS monitoring to log server certificate fingerprints presented to IoT devices and alert on changes.
• Use a network tap or span port to capture firmware download sessions and validate file hashes against vendor-published values.

Monitoring Recommendations

• Segment IoT devices onto a dedicated VLAN with logging at the gateway to centralize visibility into outbound update traffic.
• Alert on ARP table changes and DHCP anomalies on segments where Aqara hubs reside, since MITM positioning often relies on these techniques.
• Track firmware version inventory across all Aqara devices and investigate any version that deviates from approved baselines.

How to Mitigate CVE-2025-65290

Immediate Actions Required

• Identify all Aqara Camera Hub G3, Hub M2, and Hub M3 devices on the network and confirm their current firmware versions.
• Restrict the affected hubs to trusted network segments and block lateral access from untrusted Wi-Fi or guest networks.
• Monitor vendor channels for an Aqara firmware update that addresses improper certificate validation in the OTA client.
• Avoid triggering manual firmware updates on untrusted networks until a patched release is confirmed.

Patch Information

At the time of publication, no vendor advisory or patched firmware version is listed in the NVD record for CVE-2025-65290. Administrators should monitor the Aqara support site and the public vulnerability report for updates on a corrected OTA client that enforces TLS certificate validation.

Workarounds

• Place Aqara hubs on a dedicated network segment with egress filtering that only permits connections to verified Aqara update endpoints.
• Use DNS filtering or static host entries to ensure firmware update domains resolve only to legitimate vendor infrastructure.
• Disable automatic OTA updates where the device permits, and perform updates only over a controlled and monitored network path.
• Apply strong Wi-Fi security and disable legacy protocols on the local network to reduce the likelihood of an attacker gaining a MITM position.

# Example: isolate Aqara hubs on a dedicated VLAN and restrict egress
# (adjust interface, VLAN ID, and update endpoints to your environment)

# Create IoT VLAN
ip link add link eth0 name eth0.40 type vlan id 40
ip addr add 192.0.2.1/24 dev eth0.40
ip link set eth0.40 up

# Allow only DNS and HTTPS to known Aqara update infrastructure
iptables -A FORWARD -i eth0.40 -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0.40 -p tcp --dport 443 -d <aqara-update-endpoint> -j ACCEPT
iptables -A FORWARD -i eth0.40 -j DROP