Aqara Hub Security Patch Status: Are the 2025 CVEs Fixed?

Three vulnerabilities affecting the Aqara Hub M2, Hub M3, and Camera Hub G3 were publicly disclosed on December 10, 2025. One of them carries a CVSS score of 9.8. Aqara quietly shipped firmware updates months before the disclosure. Whether those updates actually fix the problems is, as of this writing, an open question.

This article goes through each CVE, what the researcher found, what Aqara released, and what the current state of verification actually is. If you run one of these hubs under Home Assistant, this is the clearest picture available from public sources.

No sensationalism warranted here — but some honest accounting is.

A note on scope: the same researcher disclosed eight Aqara hub CVEs on December 10, 2025 (CVE-2025-65290 through CVE-2025-65297). This article focuses on the three highest-severity, broadest-impact issues — the unauthenticated RCE, the OTA integrity bug, and the TLS validation bypass — because those drive the practical question of whether the hub is safe to run. The remaining five (command injection variants, NULL-pointer DoS, unauthorized data upload) are real and worth reading in the researcher’s repo, but the patch-status story is the same: shipped silently, documented opaquely.

Three CVEs, One Hub Family

All three vulnerabilities share the same baseline: Hub M2 firmware 4.3.6_0027, Hub M3 firmware 4.3.6_0025, and Camera Hub G3 firmware 4.1.9_0027. All were publicly disclosed the same day (December 10, 2025) by the same researcher (GitHub: Chapoly1305). Here’s what each one actually is.

CVE-2025-65294 — Unauthenticated Remote Code Execution (CVSS 9.8)

This is the serious one. The affected hub firmware exposes an undocumented CoAP endpoint at /lumi/gw/rpc that accepts arbitrary shell commands and executes them as root. No authentication required. No user interaction required. The endpoint supports both synchronous execution (where you get back the command output) and asynchronous execution (background, no output returned) — and neither mode generates an audit trail on the device.

CWE classification is CWE-94, Improper Control of Code Generation. The NVD record assigns it a 9.8 critical score, which is appropriate: unauthenticated root shell access is about as bad as it gets for a consumer IoT device.

The researcher reported this to Aqara on July 3, 2025. Aqara acknowledged receipt and provided a mitigation schedule in October 2025. The researcher’s follow-up regression testing later that month found the remediation was incomplete — Aqara had added filtering mechanisms around the endpoint rather than removing it. Follow-up communication with Aqara after that point received no response.

The researcher’s GitHub advisory includes an affected-version table that lists some models — E1, G3, M1S2, M1S22, M2PoE, M3 — as having fix points from firmware 4.1.7 onward. Hub M2 remained listed as still vulnerable in that table at the time of writing.

CVE-2025-65295 — OTA Firmware Update Insecurity (CVSS 8.1)

The hub’s firmware update script (fw_manager.sh) can be invoked with a flag that disables cryptographic signature verification entirely. An attacker who can position themselves to serve a firmware image — or who can alter the update process — could push unsigned or malicious firmware to the device.

The underlying cryptographic choices make this worse: the OTA process uses 1024-bit RSA keys, which have been considered inadequate since roughly 2010, and MD5 for integrity checking. A sufficiently motivated attacker doesn’t need to disable signature checking — they could potentially forge valid signatures with those primitives. Separately, firmware headers expose uninitialized stack memory in the model_id field, which is a secondary information-disclosure issue tagged under CWE-457.

CWE classifications: CWE-326 (Inadequate Encryption Strength), CWE-347 (Improper Verification of Cryptographic Signature), CWE-457 (Use of Uninitialized Variable).

CVE-2025-65291 — TLS Certificate Validation Bypass (CVSS 7.4)

The hub does not validate server certificates in TLS connections used for discovery services and CoAP gateway communications. An attacker on a network path between the hub and its upstream services can intercept or modify control traffic without the device detecting it. CWE-295 (Improper Certificate Validation). The NVD record was last modified January 15, 2026.

What Aqara Released — and What They Said

Aqara issued OTA updates for Hub M2 and Hub M3 (firmware V4.3.8) on August 28, 2025. A Camera Hub G3 OTA followed in October 2025. All of these predate the December 10, 2025 public disclosure — the researcher coordinated privately with Aqara first, which is standard responsible disclosure practice, and Aqara did respond with releases.

The problem is what those releases said about themselves.

The most recent publicly visible Hub M3 changelog (version 4.5.40_0019 at the time of research) lists: “Optimize device-related functions” and “Fix known issues.” No CVE numbers. No mention of security fixes. No description of what changed. A forum user commenting on that thread called the changelog “really useless,” which is hard to argue with when you’re trying to evaluate whether a CVSS 9.8 vulnerability is actually closed.

Aqara’s Security Response Center page, as of May 2026, lists no public advisories for any of these CVEs. The page describes their vulnerability reporting process and states a general intent to release security patches. It references no specific CVEs, no disclosure timelines, no fixed firmware versions.

This is a transparency gap that matters. Silent patches before a coordinated disclosure are acceptable practice — vendors often patch before going public to give users a window to update. But releasing a patch and then providing no public documentation of what it addresses, even after the researcher has published, is a different posture.

Is It Actually Fixed? What We Know and Don’t Know

This is the section every Practitioner wants answered, and the honest answer is: partially confirmed, partially unverified.

What’s confirmed: Aqara released OTA updates (V4.3.8 and subsequent 4.5.x releases) across all three affected hub models before the public CVE disclosure. The researcher’s advisory acknowledges that some models have documented fix points from firmware 4.1.7 onward.

What’s not confirmed: The researcher’s own regression testing in October 2025 found that the remediation for CVE-2025-65294 (the unauthenticated RCE) was incomplete at that point — the endpoint remained reachable, just with added filtering on top. No widely-circulated community verification surfaces in public sources at the time of writing — searches across the Home Assistant forums, the Aqara forum, GitHub, and Reddit do not turn up an independent test confirming that firmware 4.5.x has removed the /lumi/gw/rpc endpoint on Hub M2 or that the CoAP execution surface is fully closed.

What “fix points listed” actually means: The researcher’s advisory table listing firmware 4.1.7 onward as a fix point for some models describes what Aqara told the researcher, or what the researcher observed in testing, not necessarily what’s been independently confirmed by third parties. The same advisory notes the Hub M2 remaining vulnerable even after the October 2025 regression check.

The net result: if you’re on firmware 4.5.x or later, you’re probably in a better position than 4.3.6, but “probably” is doing real work in that sentence. The absence of a transparent vendor advisory and the absence of community-confirmed endpoint testing means you can’t verify this from the outside without testing it yourself.

Risk Context for Local-First Setups

The severity of these vulnerabilities depends significantly on your network architecture.

CVE-2025-65294 (the unauthenticated RCE via /lumi/gw/rpc) and CVE-2025-65291 (the TLS bypass) both require network access to the hub to exploit. If your hub sits on a dedicated IoT VLAN — see the Aqara Hub M2 + Home Assistant local-only guide for the network setup — with no inbound traffic from untrusted sources, no port forwarding, no direct WAN exposure, your attack surface for those two is substantially reduced. An attacker would need to already be on your IoT VLAN to send CoAP commands to the hub.

CVE-2025-65295 (the OTA integrity issue) is different. Firmware updates are outbound-initiated by the hub. If the hub reaches Aqara’s update servers over an inadequately secured path — and given that CVE-2025-65291 describes TLS bypass on these same models — a sufficiently positioned attacker could potentially chain these. This is a less common attack scenario than a straightforward LAN breach, but it’s the reason CVE-2025-65295 remains relevant even for well-segmented setups.

For readers running hubs in a flat home network with no VLAN isolation, the risk profile is higher. The /lumi/gw/rpc endpoint (if unpatched) would be reachable by any device on the same network — a compromised laptop, a malicious app, anything with LAN access.

None of this is a reason to pull the hub off the wall. It’s a reason to understand your actual exposure and take the mitigations below seriously.

What to Do Right Now

1. Check your firmware version.

In the Aqara Home app, go to Hub settings > About. The Home Assistant Aqara integration surface-exposes firmware version as a device attribute — check Configuration > Devices for your hub entity. You want to be on V4.3.8 or later. V4.5.x is preferable if available for your model.

2. Update, even without confirmation the patch is complete.

Running 4.3.6 is definitively bad. Running 4.5.x may not be fully confirmed as clean, but it’s better than the baseline vulnerable firmware. Enable OTA updates if they’re not already on, and let the hub pull the latest available version. This is basic hygiene regardless of the CVE status.

3. Verify your network segmentation.

If your hub has a routable path from the internet or from untrusted LAN segments, fix that. The hub needs outbound internet access for OTA updates and (if you’re using cloud features) for app control. It doesn’t need to accept unsolicited inbound connections from anywhere. A simple firewall rule blocking inbound to the hub’s IP from everything except your Home Assistant server and your LAN subnet is reasonable baseline hardening.

4. Watch the researcher’s advisory and Aqara’s security page.

The researcher’s GitHub advisory (Chapoly1305/myCVEReports) is the most accurate public record of patch status. It has been updated before and may be updated again. Aqara’s Security Response Center page is the official channel, even if it has not yet demonstrated useful transparency on this particular issue.

5. Treat Hub M2 as higher-risk if you can’t verify your patch status.

Based on the researcher’s October 2025 regression findings, Hub M2 in particular had incomplete remediation at that point. If you run Hub M2 in a network position where it’s reachable from untrusted sources, and you haven’t confirmed your current firmware version, treat it as a higher-risk asset until you can verify otherwise.

The Broader Question: Aqara’s Security Posture

The researcher coordinated responsibly with Aqara. Aqara responded — they acknowledged the reports, provided a mitigation schedule, and shipped OTA releases before the public disclosure date. That’s not nothing. Coordinated disclosure worked here in the basic sense.

What didn’t work: the transparency layer. A CVSS 9.8 vulnerability in your product, publicly disclosed and indexed in NVD, warrants a public advisory. It warrants a changelog that says something like “security fix: removes undocumented remote execution endpoint.” It warrants some acknowledgment that specific firmware versions address specific issues.

Aqara’s changelog says “Fix known issues.”

This is a pattern worth factoring into a long-term evaluation of Aqara hardware. It doesn’t mean Aqara is malicious or uniquely bad — opaque changelogs are common across the consumer IoT space. But if your threat model includes supply-chain trust and you want to verify that a vendor’s patch actually addresses what they claim, you need a vendor who provides the tooling for that verification. Right now, Aqara doesn’t.

For readers who are primarily concerned with keeping a working, locally-controlled smart home, this probably isn’t a reason to switch hardware. For readers evaluating whether Aqara belongs in a higher-security environment — one where the expected attacker is more capable than an opportunistic script — it’s a real data point.

The researcher did the community a service by documenting these issues in detail. The community still needs someone to independently verify the current patch state on current firmware. That’s a gap this article can’t close from public sources alone — it’s noted here so you know what you’re working with.