Possible security issue, bug in firmware

@Aaron @duncan

I’ve been working with @einars for a few months trying to figure out why his hub has been rebooting when using an IDLock (Z-Wave).

Here is the final issue, when using the stock ST Z-Wave Lock DH

  1. Running locally on the hub no issues
  2. Running in the cloud, when the lock is unlocked by a user code/manually, it causes the hub to panic and reboot

This has been replicated consistently now over the past few months. This appears to be limited only to IDLock, I’m guessing when a user unlocks the door the lock is sending some command to the hub which may not be formatted/handled properly and while communicating with the cloud it ends up causing a hub reboot. The hub should never reboot IMHO even if it gets corrupted or malformed or in compatible z-wave messages.

See the logs below:

Let me know how you would like to handle/investigate this. We had reported it to ST support earlier and they threw it back saying it was a custom DH, since then we’ve been able to replicate this using the stock ST DH also.


One important note.
in 99% of the cases the hub disconects a second after the lock is used.
Since the picture shows a 2 minute before boot, I thougt it was usefull info.



@slagle talking to security I hope someone’s looking into this. If z-wave messages can make a hub reboot…

1 Like

I think there are a few things that can cause the hub to reboot, not necessarily a security issue but certainly something that maybe could be handled better.

I still have a copy of the old Samsung TV (2013) DTH/SA that ST deprecated ages ago and told us not to use any more (with good reason). It can, without fail, instantly reboot my hub if I try and send my TV a command from the DTH.

1 Like

Anything that can cause a hub to reboot is a security issue, it’s about compromising the basic functionality of the hub. Rendering the hub inoperable is just as bad.