On October 18th, we were contacted by a security researcher who identified some vulnerabilities in a third party library found in Wyze Cam v3’s firmware that required local network access (i.e. access to your WiFi network). We quickly worked with this 3rd party to patch this exploit, and released a new firmware update. On October 22nd, that update was automatically being pushed to most cameras while we started an investigation to see if other Wyze products also needed to be patched.
Unfortunately, another security researcher had to withdraw from an independent security competition called Pwn2Own because this firmware update addressed his planned demonstration on Wyze Cam v3. This person then disclosed details about the vulnerability to the public before we had concluded all our updates. We urge those in the infosec community to work with us through responsible disclosure programs or our Bug Bounty Program in the future to mitigate any unnecessary risks to the public.
Today at 3:59 PM PT, we started sending in-app messages to users that had cameras not yet updated to the most recent firmware. To be extra safe, we’ve now sent notifications to all users with a Wyze Cam v3.
We strongly encourage all users to make sure their v3 firmware is updated to version 4.36.11.7095. Your security is incredibly important to us. We will continue to investigate and will release firmware updates to any other affected products as soon as possible.
I did some looking into this issue, and it appears that this exploit is another overreaction by some people similar to last Winter’s issue where you needed to be on the local WiFi.
I do have several Wyze v3’s, but I’ll tell you why I’m not too concerned about this:
Major point:
From what I am reading…like the issue brought up last winter, this vulnerability is only exploitable if someone has direct access to your WiFi router. They basically need physical access to the Camera so they can send it specially crafted packets over the local network which then allows them to do an authentication bypass…but if someone unauthorized is on your local network, you have WAY BIGGER PROBLEMS and they aren’t going to give a rip about your camera compared to other targets. This means it’s basically another non-issue, because you either gave them access to your network already, or your whole digital life is already in a crisis, and a V3 camera is the least of your worries.
Minor points
So far it seems to be an iCamera daemon using a derivative part of the TUTK protocol in the V3. It seems like it’s limited to that.
I’m glad it’s already patched. THANK YOU WYZE for listening to everyone asking you to address these things FAST now. Last winter you promised us that you’d invested on handling these kinds of reports as a priority so they are addressed way FASTER from now on, and this one was done within 4 days! That’s a HUGE turnaround and improvement! I honestly never expected to hear that Wyze would be criticized and complained on for fixing security reports too FAST. instead of waiting longer. It’s kind of funny. Tech sites will blast you if you’re too slow and blast you if you’re too fast. It is the life of a tech company.
Also, in the Youtube Video, they said that lots of other companies also patched before the contest started. Only Canon and Google didn’t patch before the event started. Apparently this is VERY common. Not sure why some people/places see this as newsworthy against Wyze for doing the same thing as every other company besides 2?
Apparently, from what I am reading, Trend Micro found that RCE vulnerabilities were present in over half of all IoT devices they tested…so keep in mind that this is not something specific to Wyze, but probably half of all your IoT devices from all companies. These are the kind of things that are usually just updated by every company without explanation and filed as part of update logs saying “security improvements”…especially since it requires access to the local network to initiate anyway.
In general, I would recommend people always use a second network SSID like their guest network with Device isolation turned on for all IoT devices.
Only connect your camera or other IoT devices to a trusted encrypted (passworded) network that you control.
If you are away from home like at a hotel or Airbnb or something, use another device as an intermediary. You can even use a computer or phone running a VPN that re-broadcasts a secure hotspot for your other devices to connect through. Then nobody is actually on your same network in that sense because you’re on a VPN instead of the public network.
But I don’t work for, speak for, or represent Wyze in any way. The above is just what I learned by reading through everything publicized on this issue, looking into RCE’s, looking through things said by other researchers, etc. I don’t claim to be some kind of expert on RCE exploits, myself. I’m just some Wyze user who was wondering how concerned I should be about the risk.
Thank you very much for your post on this! Well done to the teams that had this patched so quickly and for taking it seriously! This is the kind of transparency I really appreciate and love to see from Wyze!
Agreed! Great reaction time! Thanks for the update!
I’m not sure what I find more disturbing, that they have publicized contests for exploiting security vulnerabilities or that a self proclaimed “Security Researcher” would turn hacker so quickly after his contest entry was shut down from a patch and publicly post the vulnerability out of pure unprofessional spite offering to help others exploit it. That isn’t a Security Researcher. That is a hacker with no future in the InfoSec sector.
No kidding! This kind of behavior is the opposite of being an ethical/white hacker by any means. In this case, the “researcher” who tried to hurt people on purpose (a different person from the “researcher” Wyze references above who reported the issue in their bug-bounty program) said he purposely tried to release it early to compromise people’s security because he was mad about it being fixed too quickly. That is something my 3-year-old would do and what I would label as an entitlement tantrum.
Then I am drop-jawed at the closing words where the “researcher” says if people give him a good incentive then he’ll HELP them to hack people with this.
SMH…that kind of behavior should bring on blacklisting from ethical hacking contests, and blacklisting by all major companies, institutions, organizations, Universities, etc after that. I mean, what happens if someone like that ever doesn’t like something their boss asks them to do as part of their job? Would they throw a tantrum and ruin the entire organization and their security and all their customers? I wouldn’t want to do business with a company that hires him. How could I trust my data with them EVER? How can you take that chance? How can someone ever be trusted by a company after doing and saying something like that?
I mean, I get it if someone is disappointed that their plan went down, but a person can’t go out of their way to hurt security for innocent people on purpose like that. That’s just really disappointing that a “security researcher” did all that.
RCE vulnerabilities aren’t super rare…but what is super rare is a self-proclaimed ethical security researcher purposely trying to compromise people’s security on a massive public scale with an immature tantrum. I just can’t believe it. Where’s the article about that, is what I really want to know? That’s the real scoop here IMO.
Maybe there is some information or context I’m not aware of, but so far, my opinion of the researcher is pretty low now, and I just found out he was on the team that figured out the failOverflow on the Wii (which I loved and implemented on my own Wii for a while to try out for fun)! But that one that he shared didn’t purposely compromise people’s security like was done intentionally this week. Now I’m sad to hear of what it’s come to. Very disappointing from someone I actually once appreciated.
i updated to 7095 and my v3 went offline few days after update.
i would be very careful when approached by these “researchers”, especially please do not do anything “quickly”, take time to understand whether exploit is acutally exploit or whether you are being played to implement one, take time to test and test thoroughly in all kinds of scenarios, make sure you do not fix only to break something else.
From what I am reading…like the issue brought up last winter, this vulnerability is only exploitable if someone has direct access to your WiFi router. They basically need physical access to the Camera so they can send it specially crafted packets over the local network which then allows them to do an authentication bypass…but if someone unauthorized is on your local network, you have WAY BIGGER PROBLEMS and they aren’t going to give a rip about your camera compared to other targets. This means it’s basically another non-issue, because you either gave them access to your network already, ““or your whole digital life is already in a crisis, and a V3 camera is the least of your worries.””
I want people to really understand having access to a camera be it from the internet or local is a huge privacy and security problem! It is a “issue”. You cannot shift the blame to the user.
The patch has already been issued. Who is blaming anyone? Wyze acted quickly to patch the vulnerability.
What @carverofchoice was pointing out was that this particular vulnerability is NOT able to be exploited from the Internet unless users are running an Open Network with NO security. If that is the case, this vulnerability is the least of the problem for that user and I would have to seriously question the user’s ability to comprehend the concept of internet security.
If the user does have a STRONG password set with updated firewalls in place on the router the only way to get to the cams is to be inside that network behind the firewall. That comes by user invitation only. That is why many users operate a secure IoT network separate from a Guest network. If the user is sharing that IpT network with every stranger that asks, again… questioning comprehension of internet security.
For those who do understand network security and have a multilayered network security platform, this is really no different than any other security update. If they can’t get into my network, they can’t get to my cams to exploit anything.
While the door to the safe may be unlocked, don’t leave the front door wide open and invite everyone in to snoop around and steal your cams.
Both of mine had already been updated but I received the in app notification when I tried to view each camera. Message would tell me to upgrade firmware and then show me same firmware numbers.
I am implying that anyone who uses ANY IoT device, listening, video, or otherwise, in ANY area wherein there is an expectation of ANY degree of personal privacy should, out of even the smallest exercise of common sense and caution, consider every IoT device to be suspect of security by default and secure their network using a multilayer approach.
Users who trust in the security of ANY IoT device alone also trust that there are no hackers out there with the intelligence, will, and desire to break it.
If users are placing any cams of any make or model on an unsecured public network with only the cam’s firmware as security and still have the expectation of privacy, something is seriously missing in their security logic.
Internet and Network Security starts with the user. Ignorance of security is not an excuse to shift the responsibility to the hardware when the proper steps to secure a network and the devices on it are ignored.
Then i would happily buy any cheap white-labelled cameras for like 20$ and keep it inside a firewall.
oh wait! a normal user can easily write firewall rules and understands how multilayer networking works and run everything through a personal VPN.
I am not here to play who is right game.
My point is that that an RCE from a local network is a serious issue and belittling as non-issue is actually reverse of educating people about security! Real attacker don’t gain anything by hacking into a camera but the asset it is protecting.
A simple example: An attacker can somehow steal the wifi credential from some out of bound devices(not like wyze itself stores creds encrypted) and use it to gain local network access and if wyze is vul to RCE there. They have a free eye and ears inside.
A serious issue that was patched very quickly after being discovered.
Normal users have no idea what an RCE is or how it is used to exploit a vulnerability. Nor do they have any means within their control beyond updating their firmware to do anything about it. The majority don’t even know what the update is for. The only defense a normal user has against unknown device security vulnerabilities such as this is to secure the network on which they operate. A open public network does not achieve that defense.
The education about Internet and Network Security is this: Operate on the basic assumption that EVERY device is vulnerable and take the steps necessary to secure your network properly. This starts with not using simple network passwords, configuring router firewalls, enabling new device login approval, sequestering sensitive devices to reserved networks with limited access and disabling the broadcast of that network SSID, among others.There are experts who can be consulted to show users how to do this.
Placing your devices on an unsecured Public Open Network and expecting privacy, regardless of who makes those devices, is like walking thru the mall stark naked with the expectation that no one will look because they are all too honest and respectful. Both are highly unrealistic expectations.
Anyone who expects any IoT device to be 100% secure 100% of the time is delusional. They haven’t invented that product yet. Internet and Network Security starts with the user. The only means within their control to defend against an unknown vulnerability is to secure their network properly.
It’s kind of funny. Tech sites will blast you if you’re too slow and blast you if you’re too fast. 
It is the life of a tech company.
Good luck!