The vulnerability was in their backend cloud structure. The backend wasn't restricting access to only devices associated with your account.
> Out of sheer laziness, I connected to the Mysa MQTT server and subscribed to the match-everything wildcard topic, #. I was hoping I’d see messages from a few more MQTT topics, giving me more information about my Mysa devices.
> Instead, I started receiving a torrent of messages from every single Internet-connected production Mysa device in the whole world.
The devices had unique IDs, but they were all connected to one big MQTT pub/sub system that didn't even try to isolate anything.
It's lazy backend development. This happens often in IoT products where they hire some consultant or agency to develop a proof of concept, the agency makes a prototype without any security considerations, and then they call it done because it looks like it works. To an uninformed tester who only looks at the app it appears secure because they had to type in their password.
Quite ironically, they do install a unique TLS cert and key on each thermostat, although it's done on first-wifi-connection of each thermostat, rather than pre-installed at the factory.
And then the thermostat uses those keys to mutually authenticate itself with the MQTT server. It actually makes it quite tedious (not impossible :-D) to 2-way-MITM the device's connection to the server.
It's just that, as @Aurornis wrote, the MQTT server itself did not have any checks to prevent sending and receiving messages to other owners' thermostats. ¯\_(ツ)_/¯
[ I've actually discovered a whole lot more details about the Mysa thermostats than what I published. Many of them can be used to subvert and reconfigure the devices in interesting ways, but only with a witting/willing device owner who has local access. So I don't feel any obligation to disclose them, although I might eventually get around to building a de-cloud-ifying tool using them: https://github.com/dlenski/mysotherm/blob/main/README.md#fut... ]
I think it's about being a configuration management nightmare. If every device has a unique password, you need the decoder ring for serial number to password. However, not all processors have unique IDs. So you either need to find a way to reliably serialize each board during manufacturing and hope it stays (like a sticker/laser/printer/etc) or add a serial number chip which is cost and complexity. It's not impossible, it's just extra work that usually goes unrewarded.
I'm a long way from embedded development. But I was under the impression a lot of microcontrollers these days have some ID capability built in, even some relatively low-end ones. This strikes me more as laziness than anything.
I have not knowledge of this kind of software dev/hw production, so can you please explain why the units cant just be born with a default pass and then have the setup process (which is always there) Force the owner to set a new password?
Knowledge or not, this..
> It's not impossible, it's just extra work that usually goes unrewarded.
.. is just not an acceptable way for business to think and operate i 2026, especially not when it comes to internet connected video enabled devices
Aurornis|7 days ago
> Out of sheer laziness, I connected to the Mysa MQTT server and subscribed to the match-everything wildcard topic, #. I was hoping I’d see messages from a few more MQTT topics, giving me more information about my Mysa devices.
> Instead, I started receiving a torrent of messages from every single Internet-connected production Mysa device in the whole world.
The devices had unique IDs, but they were all connected to one big MQTT pub/sub system that didn't even try to isolate anything.
It's lazy backend development. This happens often in IoT products where they hire some consultant or agency to develop a proof of concept, the agency makes a prototype without any security considerations, and then they call it done because it looks like it works. To an uninformed tester who only looks at the app it appears secure because they had to type in their password.
JoshTriplett|7 days ago
The vulnerability is in having a backend cloud structure.
(There are plenty of ways to provide remote access without that, and no other feature warrants it.)
dlenski|6 days ago
And then the thermostat uses those keys to mutually authenticate itself with the MQTT server. It actually makes it quite tedious (not impossible :-D) to 2-way-MITM the device's connection to the server.
It's just that, as @Aurornis wrote, the MQTT server itself did not have any checks to prevent sending and receiving messages to other owners' thermostats. ¯\_(ツ)_/¯
[ I've actually discovered a whole lot more details about the Mysa thermostats than what I published. Many of them can be used to subvert and reconfigure the devices in interesting ways, but only with a witting/willing device owner who has local access. So I don't feel any obligation to disclose them, although I might eventually get around to building a de-cloud-ifying tool using them: https://github.com/dlenski/mysotherm/blob/main/README.md#fut... ]
Neywiny|7 days ago
HFguy|7 days ago
NegativeK|7 days ago
That sounds like profit motivated negligence, and it sounds like a standard justification for why Europe is going to hold companies liable.
Msurrow|7 days ago
Knowledge or not, this..
> It's not impossible, it's just extra work that usually goes unrewarded.
.. is just not an acceptable way for business to think and operate i 2026, especially not when it comes to internet connected video enabled devices