What is the CVSS score of CVE-2025-65290?

CVE-2025-65290 has a CVSS 3.1 base score of 7.4 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.2%.

Which versions of Aqara Hubs are affected by CVE-2025-65290?

Aqara Camera Hub G3 (4.1.9_0027), Hub M2 (4.3.6_0027), and Hub M3 (4.3.6_0025) devices are affected by a high-severity firmware-update integrity flaw that could allow an attacker on the network path…

Is there a public PoC exploit available for CVE-2025-65290?

Yes, a public proof-of-concept exploit is available for CVE-2025-65290. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate CVE-2025-65290?

Within 24 hours, inventory all affected Aqara Camera Hub G3 (4.1.9_0027), Hub M2 (4.3.6_0027), and Hub M3 (4.3.6_0025) devices; move them to an isolated VLAN/SSID or dedicated network segment with no access to corporate or sensitive VLANs; and temporarily disable automatic firmware updates unless a controlled update is required. Within 7 days, enforce strict egress allowlisting for the hubs to only approved Aqara firmware/update endpoints, monitor those connections for anomalies, confirm no unauthorized firmware has been installed, and contact Aqara for a patch timeline; if updates are unavoidable, perform them only during a maintenance window on a trusted, monitored network path. Within 30 days, apply the vendor-released patch as soon as Aqara provides an exact fixed firmware version, verify the updated versions, re-enable automatic updates only after validation, and if no patch is available, keep the hubs isolated and consider replacing them or limiting their deployment to non-critical environments.

Aqara Hubs CVE-2025-65290

HIGH

Improper Certificate Validation (CWE-295)

2025-12-10 cve@mitre.org

Information Disclosure IoT Hub M2 Firmware Hub M3 Firmware Camera Hub G3 Firmware

7.4

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.4 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

7.4 HIGH

AC:H and PR:N because no auth is needed but an on-path MITM during an update is required; C:H/I:H reflect traffic interception plus serving tampered firmware; A:N as availability is not directly impacted.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Metadata Corrected

Sep 26, 2026 - 00:40 vuln.today

tag: IoT added

Analysis Generated

Sep 25, 2026 - 23:51 vuln.today

CVE Published

Dec 10, 2025 - 22:16 cve.org

HIGH 7.4

DescriptionCVE.org

Aqara Hub devices including Camera Hub G3 4.1.9_0027, Hub M2 4.3.6_0027, and Hub M3 4.3.6_0025 fail to validate server certificates during HTTPS firmware downloads, allowing man-in-the-middle attackers to intercept firmware update traffic and potentially serve modified firmware files.

AnalysisAI

Aqara Hub devices - Camera Hub G3 (4.1.9_0027), Hub M2 (4.3.6_0027) and Hub M3 (4.3.6_0025) - skip TLS server-certificate validation when fetching firmware over HTTPS, so an attacker holding a man-in-the-middle position on the network path can intercept the OTA session and potentially deliver modified firmware to the device. The weakness is remotely triggerable without authentication or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N, 7.4), but exploitation is conditional: the attacker must already control the network path and must catch the device during an actual firmware-download window. Exploit detail is publicly available, and EPSS is low at 0.18% (6th percentile); there is no indication of confirmed active exploitation (not in CISA KEV).

Technical ContextAI

The root cause is CWE-295 (Improper Certificate Validation) inside the Aqara hubs' OTA firmware-update client: the device opens an HTTPS connection to its firmware distribution server but does not verify the presented server certificate - no chain-of-trust check, no hostname matching, and, in practice, no meaningful resistance to an attacker-supplied certificate. That reduces the transport to effectively plaintext-integrity terms: an adversary who can intercept and relay the TLS session (rogue access point, ARP or DNS spoofing, or upstream control of the local network segment) can present its own certificate and substitute firmware content. The impact class is integrity and supply chain, not simple data exposure: a modified firmware image, once accepted, executes with the hub's privileges and could persist across reboots, control smart-home devices, or expose sensor/camera data handled by the gateway. Affected CPEs are cpe:2.3:o:aqara:hub_m2_firmware:4.3.6_0027, cpe:2.3:o:aqara:hub_m3_firmware:4.3.6_0025, and cpe:2.3:o:aqara:camera_hub_g3_firmware:4.1.9_0027. Practical attack scope is usually local/adjacent network rather than arbitrary internet positioning, given the AV:N/AC:H profile and the need to coincide with an update cycle.

RemediationAI

No vendor-released patch was identified at the time of analysis, so treatment focuses on removing the man-in-the-middle precondition rather than fixing the client. First, place Aqara hubs on a dedicated, isolated IoT VLAN/Wi-Fi SSID and prevent that segment from being reachable by guest or general-purpose clients - this directly defeats the rogue-AP and ARP/DNS-spoofing paths the attack depends on, at the cost of some smart-home integration convenience. Second, enable switch-level protections on that segment: DHCP snooping and Dynamic ARP Inspection, plus static DNS configuration and, where supported, DNS-over-HTTPS on the gateway, to make spoofed resolution and ARP poisoning harder; note that these controls require managed network hardware and can break devices with static or unusual network configs. Third, monitor for the attack rather than just the condition: watch the hub's outbound connections for unexpected TLS endpoints, duplicate DHCP servers, or certificate-issuer anomalies during scheduled update windows, and stage firmware updates only over a verified trusted network. If Aqara publishes updated firmware that implements certificate pinning or validation, plan the upgrade immediately, since simply blocking OTA traffic removes the exposure window but also prevents any future security fixes from being applied. Consult the Aqara product support pages and the published technical report at https://github.com/Chapoly1305/myCVEReports/blob/main/Aqara/OTA-Certificate-Validation-Bypass.md for model-specific guidance.