[Updated 02-13-20] Data leak 12-26-2019

IIRC…Wyze needs the SSID so if your cam(s) go off line it can reconnect.

signed…the newbie.

Not true. The camera must save both locally as well. Because, how can it get anything from the Wyze server if it can’t even connect to the WiFi?


Only Wyze can answer that specifically. I do have other brands of smart devices That save the network info to make adding additional devices easier. Amazon must save not only network SSID, but passwords I think also because when I’ve added a new Echo or Fire TV it connected to my network automatically. I don’t see any reason for Wyze to save SSID though because they don’t function like that, but perhaps in the future?

Fortunately I use unique email addresses for all services, specifically so that when they get leaked I can close them out and avoid the spam.

How do I change the email address on my Wyze account? It doesn’t seem to be possible.

It’s not currently possible to change your email address. The best you can do is create a new account and re setup all your devices.

I am guessing this may change soon but I am just guessing.

Here is the #wishlist topic where that is discussed and on which you can vote:


I’m in the process of deleting an old email address/account. I’ll report back how it went.

1 Like

Wyze storing the SSID on their servers makes no sense to me. Why are they doing this???

1 Like

@WyzeGwendolyn @WyzeTao

The # of replies in this thread makes it hard to keep up with notifications. I want to ask a few questions about the current response from Wyze and the latest blog posts from 12Security.

Based on the previous responses from Wyze there was the identification of a limited set of data that was accessible via ElasticSearch, however, the 12Security blogs is now going into claims about direct database access which goes well beyond the scope of what was previously identified by Wyze as being accessible. Based on the current claim it appears that the entire underlying SQL database was accessible which greatly expands the scope of data. Can you please confirm / make a statement (when appropriate) of the new claims / broader level of data accessible. Also, there are claims of source code which was accessible that contained hard coded AWS credentials. What were the roles/access of those credentials? are the limited to S3 access or were they more broad where the entire AWS infrastructure could have been compromised by a 3rd party and left behind “active” elements (eg is a detailed audit of the ENTIRE AWS infrastructure/OS elements planned) ?

The previous claims of data being exposed were tied to a Dec 4th date (which coincidently matched the dated of Shodan/Binary Edge) , however there are new claims about data being accessible since early 2019. can you please confirm how long data was accessible (FYI. if there is a first found data on Shodan/BE of X, then usually data was available prior to that date as they usually work on weekly / bi-weekly scans) how was your date of Dec 4th which matched Shodan/BE determined? was it confirmed with AWS/OS logs on the ElasticSearch server?

There was mention on the 12Security latest blog post about a notice from Dark Cubed about encryption “infrastructure” related issues reported (eg possible interception of the download of the cert used, which could lead to later snooping) The link on the 12security site are broken with regards to the details but it is unclear if Wyze was aware of this previous report. Was Wyze aware of this report? if so what was done with regards to the issure prior to this latest data breach (and why would it not lead to a more “Security” aware situation at wyze where the breach might have been prevented / discovered earlier by in-house staff and not 3rd parties) ?



Hi Darryl, we have seen the 12Security Essay #3 today. In short, we don’t believe our production database was compromised. We were aware of the Dark Cubed report. The issue was already addressed by Wyze. Wyze will go through the items listed in today’s post and reply as needed. We take customer’s security seriously and will try our best to protect our customers. Thanks!



Thank you for the quick reply

Same here! Deleted from both Alexa and Google, then added them back but nothing works. I cannot turn on lights unless I use the wyze app. When will this all be fixed?

Didnt work for me :frowning:

Did you logout and back in on both Wyze and the Alexa apps ?
Delete and add the Wyze skill in Alexa … delete Wyze affected devices …then Discover ?
May also need to redo the Routines affected.

If you did that open a support ticket

You don’t need to delete anything in fact doing so won’t resolve the issue as you have seen. Unlink the Wyze Alexa skill and then relink it. In IFTTT also unlink the Wyze skill and then relink it.

I tried that first and it didnt work. So I deleted all bulbs from IFTTT, Alexa, Google and Wyze. Added them back. into wyze snd Alexa. In Alexa app the bulb is showing as server is unresponsive. When i try to turn bulb on it shows waiting for wyze but doesn’t turn on. For now I’ve given up on google and IFTTT, I just want to get one to work.

I’d start a support ticket at this point

1 Like

I agree with @paindonthurt at this point. Something unusual is going on and you need to involve support at this point.

1 Like

Thank you for this response. While I don’t completely follow all of the technical aspects in the 12Security posts, some of the points do seem at least plausible.
I hope that you soon will clarify the issues raised by 12Security. I think that Wyze users understand that the company takes our security “seriously”, yet here we are.
I’m hoping for a positive conclusion to this whole event which has no doubt been a nightmare for a young, innovative company (which we all support). In the meantime it is so very important to keep your customers timely and transparently informed.