Major DDoS vulnerability that could cost Wyze millions found

So, by having a web view implementation, you officially have opened a can of bees for potential DDoS abuse and other types of abuse such as users having their cameras on all the time on their desktops 24/7 and just running up a huge bill on your AWS account.

How about this for a money saving tip:

I know it sounds super crazy and impossible to fathom, but why don’t you make it so that the webview accesses the cameras directly VIA Wifi if watched from a machine on the same network!

I mean how hard could it be to simply modify the firmware to have a few bytes of memory available to store a couple of IP addresses that could be retrieved from the Wyze API response that lists any connected network addresses that have been authorized to also receive the camera picture data.

Then, using the very same implementation that is used on the wyze servers to receive the picture and convert it to a viewable video, you instead port just the necessary code to decode/encode the video into the web browser and connect to the camera directly using websockets!

Whats that ? Web sockets too complex? Why not just implement a server-side websocket receiving API that works on the same exact implementation, thereby making sending the packets as simple as:

for each (ip in send_list) {
send_camera_packet(ip, camera_video)

This way you can REMOVE the REMOTE packet sending when nobody is watching or NOTHING IS HAPPENING, or ADD A LOCAL NETWORK IP ADDRESS OBTAINED FROM THE Wyze API if somebody wants to stream 24/7 but still watch remotely sometimes!!

Whats that? Your chips don’t have enough memory to add a for loop??

Why don’t you add another 1 megabyte of memory to those cameras for an extra $4.99? Then you could do this:

Save the entire frame onto the camera memory, save the next frame in the memory, compare the pixels and if enough pixels are different in color value from the previous frame, send it remotely, otherwise discard the old frame, and repeat. This process takes around 3ms to do if you only do low-res comparisons and will save your company hundreds or even thousands yen or dollars or whatever for years to come.

If you don’t do the steps listed, you will find that you will not be able to meet the demands of users in terms of bandwidth due to you having a non-scalable API

Keep everything local except for what NEEDS to go remote… NEVER send ANYTHING remote that can be sent over a LOCAL NETWORK!!!


1 Like

Umm, they don’t? The Kinesis service they use defaults to local WebRTC connections. Traffic stays local when it can.

1 Like

Then why does it not show a video when the internet is not running? Shouldn’t the camera keep running if I unplug the router or somehing?

I would think it should, at least for a while. I’m speaking only based on what I read on the Amazon Kinesis site. I don’t know what exactly Wyze is doing… I suppose they could be avoiding the P2P option but I can’t imagine why they would. I posted a series of questions about this at

I’m confused by your question…if you access the camera feed via a Wyze web server, why should it function without an internet connection on your end?



Not sure what you meant to say with last post…

1 Like

This IS how the app works, you are correct there, I was going to mention that as well, but I am not so sure that it’s how the webview when viewing from a desktop or PC works. That is something I would definitely like some clarification on :-). I have a buddy that loves digging out just this type of sub knowledge…and is really good at it. @carverofchoice might you know anything on this one? I don’t remember hearing exactly how the web viewer functions

Everything I know about it is discussed in the link @Customer posted. If one starts reading right where he linked to I join in on that conversation and include everything that has been stated by Wyze about it.

In summary, Wyze indicates that somehow the way they have set up the webview is different than they way they have the app set up to do viewing. Somehow the webviewing charges Wyze by the usage and there is a limit for how many streams can be active at once, and that it COULD be expensive, so they needed to keep a close eye on how it is used in the wild (the beta test).

But, as Customer said, the service they seem to be using indicates that it can also be P2P, so the question is how is it different? They haven’t elaborated on it or answered any of those questions, so we just don’t know for sure at this point. We only have assumptions and guesses.

Though, we do know that streaming to the app, or Google/Alexa using WebRTC can do a local stream. It is still authenticated through the internet first, but the VIDEO stays totally local if both devices are on the same network. The reason it doesn’t continue to stream if you disconnect the modem may even be intentional and something to do with authentication and security precautions. I know Google and Alexa basically cancel everything when they lose internet, even most things that don’t require internet…so this is SOP for them, and the Wyze app is probably the same just for authentication and security precautions would be my guess. In theory the stream could be set up to continue, but as a general standard I am not upset that it stops working when it can’t verify authentication any longer. I know others want purely 100% local options and there are good options out there for that.


It would be really easy for a motivated individual to monitor the network and determine some of these answers - is the video traffic local?

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.