MrSteam iSteamX EUVD-2026-86468

Requires a valid authenticated iSteamX mobile-application account (PR:L) that connects to the shared AWS IoT MQTT backend; the AWS IoT policy must be the vulnerable pre-9/18/2026 version that grants authenticated users access to WILDCARD MQTT topics rather than per-user-scoped topics. No user interaction and no non-default configuration on the victim side is needed - every user of the affected cloud deployment was exposed by default. Limiting factors: the attacker must hold app credentials, must know/enumerate the MQTT topic namespace, and the flaw was remediated server-side before 9/18/2026, so unpatched exposure now depends on the backend not having been updated. Affected products: MrSteam iSteamX Application and iSteamX Hub.

The vendor CVSS 4.0 score of 8.4 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:H) reflects a remotely reachable, low-complexity flaw requiring only low-privilege authentication (any registered app user), with high confidentiality impact and - notably - SA:H, i.e. a subsequent-system SAFETY impact (physical scalding via unintended steam activation). This CWE-653 improper-privilege-separation issue is a broken multi-tenant authorization boundary in the cloud/MQTT layer, not a memory bug. There is NO EPSS score, NO CISA KEV listing, and NO public exploit code in the provided data, so exploitation status is: no public exploit identified at time of analysis. Signals are internally consistent (network vector matches an app-to-AWS-IoT MQTT design; PR:L matches 'authenticated users'), and there is no CVSS-vs-description conflict. The realistic priority is MODERATE-to-HIGH for the affected population despite the high score: the barrier is that an attacker must be a legitimately provisioned iSteamX user, the product footprint is small (niche residential steam-shower IoT), and the fix was applied server-side prior to 9/18/2026 so most current users are likely already remediated. The distinguishing risk is the physical-safety dimension (scalding) rather than mass exploitability. Note the vendor set VI:N/VA:N even though the description explicitly says an attacker can 'start and stop other connected users' devices' - that device-control capability is arguably an integrity/availability impact that the vendor vector understates.

An attacker registers or already holds a legitimate iSteamX account, then subscribes to and publishes on wildcard MQTT topics that the overly-broad AWS IoT policy fails to scope per-user. From their own phone they read other households' device telemetry and profile data and issue start/stop commands to strangers' steam generators, potentially activating a unit and scalding an occupant. No public PoC is referenced; exploitation requires authenticated access and knowledge of the MQTT topic structure.