mH-DEVELOPER CVE-2026-82929

Two concrete prerequisites, both required: (1) the attacker must extract the static SSH host keys from the mH-DEVELOPER firmware - feasible because every device ships the same non-per-device keys; and (2) the attacker must occupy a man-in-the-middle position on the network path between an SSH client and the device (reflected in the CVSS 4.0 AT:P attack requirement), e.g., via LAN ARP/DNS spoofing or an intercepted route. No credentials or user interaction are needed once these hold. Exploitation is limited to affected firmware before version 3.0.30; devices upgraded to 3.0.30 (which introduces proper key handling) are not vulnerable. The on-path requirement is the main factor that reduces real-world risk relative to the network attack vector.

This is a moderate, on-path-dependent flaw rather than a mass-exploitable one. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N, base 6.3) is internally consistent with the description: no authentication is required (PR:N), but the AT:P (attack requirement, Present) captures the key limiter - the attacker must both extract the shared firmware host keys AND achieve a man-in-the-middle position on the network path between a client and the device. No EPSS score, KEV listing, or POC is present in the input, so all three exploitation-likelihood signals are absent or negative. There is no SSVC data supplied. The impact is correctly bounded low (VC:L/VI:L, VA:N): the payoff is interception of SSH credentials and session tampering via a rogue trusted server, not direct code execution or availability loss. Net assessment: a legitimate cryptographic-hygiene defect (CWE-321) worth patching, but the MITM prerequisite and niche product footprint make it a lower real-world priority than the network-vector, unauthenticated framing alone would suggest. Note the primary reference URL points to CVE-2026-82928, a sibling CVE, not to 82929 - advisory linkage should be verified.

An attacker extracts the static SSH host keys embedded in mH-DEVELOPER firmware (identical across all devices) and stands up a rogue SSH server presenting those keys. Positioned on the same network path (e.g., ARP spoofing on a LAN or a compromised upstream link), the attacker transparently proxies client connections; because the host key matches, clients connect without any trust warning and disclose credentials. No public exploit is identified at time of analysis, though key extraction from firmware is straightforward.