mH-DEVELOPER CVE-2026-82933

Requires the attacker to be positioned on the same local network segment as the mH-DEVELOPER module and able to intercept its traffic, because the web interface and API are served over unencrypted HTTP with no TLS. Passwords, auth tokens, and device commands are transmitted in cleartext, so a passive sniffing or MITM (e.g., ARP-spoofing) position on the LAN is the core prerequisite. Limiting factors: the attack is adjacent-network only (not internet-reachable by default), on switched/isolated networks the attacker must actively achieve an interception position, and the module must be on a version prior to 3.0.30. No user interaction or prior authentication on the module is needed to capture the credentials.

This is a genuine but bounded confidentiality risk rather than a critical, mass-exploitable flaw. The vendor CVSS 4.0 vector (AV:A/AC:L/AT:P/PR:N/UI:N/VC:H) correctly frames it as an adjacent-network attack: exploitation requires the attacker to already be on the same LAN/broadcast segment as the module, which sharply narrows the threat population versus a network-facing (AV:N) bug. The AT:P (attack requirement present) and the practical need for a traffic-interception/MITM position are the real limiting factors - on a switched or WPA2-isolated network the attacker must first achieve ARP spoofing or a shared/mirrored medium, which I reflect as AC:H in my 3.1 mapping. There is no EPSS score, no CISA KEV listing, and no public POC, so this is 'no public exploit identified at time of analysis' and should NOT be treated as actively exploited. The 6.0 medium score is consistent with impact scoped to confidentiality only (VI:N/VA:N), though note that stolen session tokens can be replayed for full API/device control per the sibling authz issue (CVE-2026-82930), giving a downstream integrity effect the base score does not capture. Net: real and worth patching on affected units, but low real-world priority given adjacent-only vector, no exploitation evidence, and niche deployment.

An attacker who has gained a foothold on the same LAN as the mH-DEVELOPER module (e.g., via a compromised device or rogue Wi-Fi association) passively sniffs or MITMs the unencrypted HTTP traffic between the admin browser/app and the module. They capture the cleartext password and authentication token, then replay the token to hijack the session and issue device/building-automation commands. No public exploit code exists, but the attack requires only standard packet-capture/ARP-spoofing tooling.