Aqara Hub M2 CVE-2025-65296

No vendor-released patch was identified in the available data for Hub M2 4.3.6_0027, Hub M3 4.3.6_0025, or Camera Hub G3 4.1.9_0027, so remediation must currently rely on compensating controls. The most effective is network segmentation: place the hubs on an isolated IoT VLAN or dedicated SSID that no untrusted clients - including guest Wi-Fi, vendor/contractor devices, or compromised home endpoints - can reach, since the vulnerability requires an adjacent-network position and blocking lateral reachability removes the attack vector entirely (trade-off: cross-VLAN automation and third-party integrations may need explicit allow rules, and mobile-app control from non-IoT VLANs requires routing exceptions). Verify the hub's management/JSON interface is not exposed through router port-forwarding, UPnP, or a DMZ, and disable any remote-access or cloud-relay features that widen the layer-2 adjacency (trade-off: loses off-site control). Where the hub supports it, restrict inbound connections to a known controller IP or MAC allowlist and enable AP/client isolation on the IoT WLAN (trade-off: isolates hubs from each other and from local controllers). Monitor hub uptime and log unexpected reboots or unresponsiveness as a possible exploitation indicator, and monitor the researcher write-up at https://github.com/Chapoly1305/myCVEReports/blob/main/Aqara/JSON-NULL-Dereference.md plus Aqara's firmware release notes for a fixed version, applying it as soon as it is published. Given the availability-only impact, low EPSS (0.28%, 19th percentile), lack of KEV status, and the adjacent-network prerequisite, these controls can be prioritized below internet-facing exposures; note that public proof-of-concept material is already available, which reduces the effort required for an on-network attacker to reproduce the crash.