mH-DEVELOPER CVE-2026-82928

Exploitation requires possession of the specific private key matching the hardcoded public key baked into /root/.ssh/authorized_keys on the mH-DEVELOPER module; with that key, an attacker on an adjacent/local network segment (CVSS AV:A) can log in as root over the always-running SSH daemon with no user interaction. Limiting factors: the private key is not published in the provided sources (raising practical attack complexity, reflected as AC:H), and network reachability is adjacent rather than fully Internet-remote. The backdoor is persistent - it survives a factory reset and can only be removed by remounting the filesystem or upgrading to fixed version 3.0.30.

This is a hardcoded-credential backdoor (CWE-1242): a fixed SSH public key shipped in /root/.ssh/authorized_keys with root key-auth login enabled and sshd autostarting. Severity of impact is maximal - full root compromise with VC:H/VI:H/VA:H. However, the vendor CVSS 4.0 vector reports AV:A (adjacent network, not full Internet-remote) and AC:H, and critically the exploit requires possession of the matching PRIVATE key, which is not published in any provided source. There is NO EPSS score, NO CISA KEV listing, and NO public exploit code identified in the intelligence - so this is a serious latent risk (a permanent backdoor that survives factory reset and cannot be removed without remounting the filesystem) rather than a confirmed mass-exploitation event. The practical priority hinges on whether the private key leaks or is recovered from firmware: if it does, every unpatched device on a reachable LAN segment falls instantly. Conflicting signal to note: the input Tags label this 'Information Disclosure,' which contradicts the actual technical impact (unauthenticated root shell / full compromise) - the labeling understates the vulnerability.

An attacker who has obtained the vendor's service private key (e.g., extracted from firmware or leaked from the vendor) reaches an affected mH-DEVELOPER module on the same or an adjacent network segment and authenticates over SSH as root using key authentication. The session yields an immediate root shell and total device control. No public exploit code is identified at time of analysis, and exploitation is gated by needing the specific matching private key (reflected in AC:H).