Overview
MrSteam, maker of the iSteamX mobile app used to control connected steam-shower and steam-generator hardware (paired with the iSteamX Hub), shipped an AWS IoT Core authorization policy that was scoped far too broadly. Tracked as CVE-2026-95699 and published to the National Vulnerability Database (NVD) on September 24, 2026, the flaw meant that, prior to a fix landing on September 18, 2026, any authenticated iSteamX user could obtain access to wildcard MQTT topics — the messaging channels the app uses to talk to devices over AWS IoT Core. Because topic-level permissions weren't scoped per-user or per-device, an authenticated attacker could read telemetry and profile data belonging to other users' devices, and — more seriously — remotely start and stop steam equipment they did not own. The issue carries a CVSS 3.1 score of 9.6 (Critical), is classified under CWE-653 (Improper Isolation or Compartmentalization), and was assigned by ICS-CERT. This is a cloud authorization design flaw, not a code-execution bug — there is no RCE involved, and exploitation required an authenticated iSteamX session.
Technical Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-95699 |
| Severity | Critical (CVSS 9.6) |
| CVSS Score | 9.6 (CVSS 3.1) |
| Attack Vector | Network — client interaction with AWS IoT Core via the iSteamX app |
| Authentication | Required — a valid, authenticated iSteamX user session |
| Impact | Cross-user disclosure of device telemetry and profile data; unauthorized start/stop of other users' connected steam devices |
CWE Classification: CWE-653 (Improper Isolation or Compartmentalization).
How It Works
iSteamX devices talk to the cloud over MQTT, a lightweight publish/subscribe protocol that AWS IoT Core uses to route messages between the app, the backend, and each physical steam unit. In a correctly scoped deployment, each user's AWS credentials (typically issued through Amazon Cognito) should carry an IAM policy restricting iot:Publish/iot:Subscribe to that user's own topics — namespaced to their account or device ID.
In the vulnerable configuration, the policy attached to authenticated iSteamX sessions instead permitted those actions on wildcard topics (patterns using # or + in AWS IoT's topic syntax) rather than per-user or per-device paths. Because MQTT wildcards match broad swaths of the topic tree, an authenticated but otherwise unprivileged user's credentials could subscribe to — and publish on — channels carrying every connected device's state updates and command messages, not just their own.
In plain terms: the app correctly verified who you were, but the AWS-side policy failed to enforce what you were allowed to touch once logged in — a classic authorization, not authentication, failure. Everyone was let in the front door, but the internal doors between users' devices were left unlocked.
Impact Assessment
Who Is At Risk
| Impact Area | Description |
|---|---|
| Any registered iSteamX user | Any account holder, by virtue of being authenticated, could reach topics belonging to other users' hardware — no additional exploitation technique was required beyond using the app's own credentials against a broader topic scope. |
| Device owners generally | Owners of iSteamX-connected steam generators/showers had their device telemetry and control channel exposed to any other authenticated user, regardless of intent. |
| Personal data | User profile information transmitted or referenced over the exposed topics was also at risk of disclosure. |
Potential Attack Chains
- Cross-user telemetry harvesting — An authenticated attacker subscribes to wildcard topics and passively collects device status and usage data from other users' steam units.
- Unauthorized device control — The same wildcard access allowed publishing commands, meaning an attacker could remotely start or stop a steam generator they did not own — a physical-safety concern given the equipment involved, beyond the pure data-exposure angle.
- Profile data exposure — Profile information reachable through the same over-broad topic access could let an attacker correlate device activity with account details for a specific victim.
Mitigation
Immediate Actions
- Update the iSteamX mobile app to the current version, and confirm your account is operating against the corrected AWS IoT policy (the vendor's cloud-side fix predates September 18, 2026, but app updates may still be required to pick up related client changes).
- Rotate any credentials shared with other services. If you reused your iSteamX password elsewhere, change it — cloud IoT misconfigurations like this are frequently discovered alongside other account-security gaps.
- Review device activity logs in the app, if available, for start/stop events you don't recognize during the exposure window (prior to 2026-09-18).
Detection Opportunities
- AWS CloudTrail review (for the vendor/operators): Audit
iot:Subscribeandiot:Publishcalls for identities associated with the iSteamX application, looking for sessions touching an unusually large number of distinct device or user topic namespaces rather than a single owned device. - MQTT topic access patterns: Look for authenticated sessions matching against wildcard topic filters (
#,+) instead of fully-qualified, per-device topic strings — a strong signal of an overly permissive policy being exercised, whether maliciously or incidentally. - Anomalous command traffic: Start/stop commands originating from an account with no prior association to the target device are a clear indicator of cross-tenant access.
Defence-in-Depth for IoT Vendors
- Least-privilege IAM/Cognito policies: Scope every authenticated identity's AWS IoT permissions to only the specific topics tied to that user's own registered devices — never grant
iot:Publish/iot:Subscribeon wildcard patterns to end-user identities. - Per-device MQTT topic ACLs: Use AWS IoT Core policy variables (e.g., binding a topic to a Cognito identity ID or device certificate) so that authorization is enforced structurally, not just by convention.
- Regular IAM policy audits: Periodically diff deployed AWS IoT policies against the intended least-privilege baseline, especially after app updates or backend refactors that touch authentication/authorization plumbing.
- Separate data and control planes where possible: Treat device "start/stop" command topics with tighter scrutiny than passive telemetry topics, since command-channel exposure carries physical-safety implications for connected heating/steam hardware.
Why This Keeps Happening
CVE-2026-95699 is a textbook cloud IoT authorization misconfiguration rather than a traditional software vulnerability — no memory corruption, no injection, no malicious payload. As more consumer and light-industrial hardware ships with a companion app riding on a managed IoT backend like AWS IoT Core, product security increasingly depends on how carefully vendors scope IAM and Cognito policies rather than on the app's own code quality. Wildcard topic grants are a common development shortcut — every account can see every device during testing — but they need to be tightened before shipping. When they aren't, the blast radius extends to every user simultaneously, which is exactly why this scored a critical 9.6: no sophisticated exploit needed, just an ordinary authenticated session pointed at the wrong topic.