I'm a little frustrated with articles like this that scattershot their critique by conflating genuine failures with problems that even FAANGs struggle with.
In particular, I don't love it when an article attacks a best practice as a cheap gotcha:
"and this time it was super easy! After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced"
That is a good thing - don't encourage security through obscurity! The impact of an article like this is as likely to get management to prescribe a ham-handed mandate to lock down firmware as it is to get them to properly upgrade their security practices.
I think maybe you’re reading this wrong. Reverse-engineering blog posts like this are just a fun and instructive way of telling the story of how someone did a thing. Having written and read a bunch of these in the past myself, I found this one to be a great read!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
Yes, heavily, because of the use of adjectives and repeating the points.
Here, I'll emphasize the words that elicit the tone:
> After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced: [command elided] The entire output is here, for the curious. This provides access to the firmware image of every TP-Link device - routers, cameras, smart plugs, you name it. A reverse engineer’s candy store.
Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
To me the phrasing seems objective. Making your binaries available to the public is good (though source would be better).
Replace [firmware] with [random popular GitHub repo] and nobody would blink. Replace [firmware] with [customer email address] and it would be a legal case. Differentiating here is important.
I think it fails to be objective because of the repetition. It's an open S3 bucket. No need to state that no authentication was required, it's already open. It's not about economy of writing but the repetition emphasizes the point, elevating the perceived significance to the author or that the author wants the reader to take away.
Furthermore, the repeated use of every when discussing the breadth of access seems like it would easily fall into the "absolutes are absolutely wrong" way of thinking. At least without some careful auditing it seems like another narrative flourish to marvel at this treasure trove (candy store) of firmware images that has been left without adequate protection. But it seems like most here agree that such protection is without merit, so why does it warrant this emphasis? I'm only left with the possible thought that the author considered it significant.
An 'open S3 bucket' sounds really bad. If it were posted on an HTTPS site without authentication, like the firmware for most devices, it wouldn't sound so bad.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Full blown production SPAs are served straight from public access S3 buckets. The only hard requirement is that the S3 bucket enforces read-only access through HTTPS. That's it.
Let's flip it the other way around and make it a thought experiment: what requirement do you think you're fulfilling by enforcing any sort of access restriction?
When you feel compelled to shit on a design trait, the very least you should do is spend a couple of minutes thinking about what problem it solves and what are the constraints.
No, it clearly has a gloating tone to it. 'A reverse engineer's candy store' is clearly meant as a slur.
When in fact TP-Link is doing the right thing with keeping older versions available. So this risks some higher up there thinking 'fuck it, we can't win, might as well close it all off'.
> Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
It's a firmware distribution system. It's read-only access to a public storage account designed to provide open access to software deployment packages that the company wishes to broadcast to all products. Of course there is no auth requirement at all. The system is designed to allow everyone in the world to install updates. What compells anyone to believe the system would be designed to prevent public access?
I think this kind of critique often leans too hard on “security through obscurity” as a cheap punchline, without acknowledging that real systems are layered, pragmatic, and operated by humans with varying skill levels. An open firmware repository, by itself, is not a failure. In many cases it is the opposite: transparency that allows scrutiny, reproducibility, and faster remediation. The real risk is not that attackers can see firmware, but that defenders assume secrecy is doing work that proper controls should be doing anyway.
What worries me more is security through herd mentality, where everyone copies the same patterns, tooling, and assumptions. When one breaks, they all break. Some obscurity, used deliberately, can raise the bar against casual incompetence and lazy attacks, which, frankly, account for far more incidents than sophisticated adversaries. We should absolutely design systems that are easy to operate safely, but there is a difference between “simple to use” and “safe to run critical infrastructure.” Not every button should be green, and not every role should be interchangeable. If an approach only works when no one understands it, that is bad security. But if it fails because operators cannot grasp basic layered defenses, that is a staffing and governance problem, not a philosophy one.
I’m beginning to think maybe I’m the only one that read this whole thing. The firmware storage isn’t the security through obscurity problem being talked about here. The hardcoded TLS private key definitely is though. And yes, it deserves shaming… terrible practice leads to terrible outcomes. Nobody is surprised that this is coming from tp-link at this point though.
It's probably fair to assume that most of their other camera models are affected by the same or similar issues. It looks like they pump out quite a few models that I image have similar firmware.
This page[1] lists the C200 as last having a firmware update in October, but also lists the latest version as 1.4.4 while the article lists 1.4.2. It seems like they have pushed other updated in this time, but not these security fixes.
I looked at some older Zyxel products and came to the same conclusion a while back. There's a whole industry of labeling generic hardware as being part of someone's else ecosystem
it's a stretch to call it generic hardware, all of cheap cameras use similar hardware, but every few months there is a new version of chip which you need to adjust to. It's challenging to find an exact chip if you want to, because they get out of date faster than JS frameworks
This is exactly why network segmentation is critical for IoT devices. I always recommend putting all smart cameras and IoT devices on a separate VLAN with no direct internet access - only local network access through a firewall with strict egress rules.
For anyone concerned about their TP-Link cameras, consider:
1. Disable UPnP on your router
2. Use VLANs to isolate IoT devices
3. Block all outbound traffic except specific required endpoints
4. Consider replacing stock firmware with open alternatives when available
5. Regularly check for firmware updates (though as this article shows, updates can be slow)
The hardcoded keys issue is particularly troubling because it means these vulnerabilities persist across the entire product line. Thanks for the detailed writeup - this kind of research is invaluable for the security community.
A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.
When he opened his front door the conversation went something like this:
Him: "Ah hello, thanks for coming round to do this. It should be fun, come in and we can get started."
Me: "OK, but I'm already done."
Him: "What?"
Me: "I'm done. I've already got root on the machine and I left a little text file in root's home directory as proof."
Him: "What? But ... what? Wifi?"
Me: "Nope. Let me in and I'll explain how."
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.
I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.
I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.
He learned about all of the above mitigations that day.
I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.
do you happen to have a guide on how to achieve this - I am fairly technical but still configuring Vlans and moving devices there would be good with some step by step instructions.
P. Sure the camera in question breaks in fun ways. From my observations because it can’t update it’s time, so messing with it a bit leaving to a need to update, downgrade, block from the web again.
depends on your router, but you would want to stick to onvif or rtsp and connect to the camera using some sort of tailscale. Don't fail for installing open source firmware, there is only thingino and openipc, both are hard to install if you are a beginner, even if people say it's easy for technical specialist, it's not
it does not, there are 5 versions of C200 as of now and thingino only supports one or two, it is very important to get the right chip, you can check https://openipc.org/
I came here to post this, too :) What the thingino community managed to do with their firmware for these cameras is nothing short of amazing - if you happen to have a compatible camera, you really, really should give it a whirl!
I'd love to but... how? One alternative seems to be a programmer chip that must be puchased and then modified to not fry the camera with 5V. Another is maybe stripping a USB cable and soldering it to the wifi pads on the camera chip?
Neither of these seem like good ideas for someone like me, who is relatively hardware naïve and has small children running around making it hard to concetrate for more than 30 minutes at a time.
The question is genuine. I want to do this but don't actually know by which method.
In this case I'm asking specifically about the C200 this article is about. Sorry for not being more clear. From what I understand the C200 does not boot from SD card.
I think Thingino is great. But there are definitely still dragons lurking. I reported a bug last year and mostly forgot about it. Got a response a few months ago to check out a fix related to unexpected memory access.
I generally try not to be a huge Rust cheerleader but seriously. Yikes.
This is why all my cameras internal or external live on an isolated VLAN with no internet access. It’s nice because HomeKit can still talk to them and I can see it online or locally without an additional app even though the camera themselves has no internet access .
This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities? There must be many millions sold. Quite handy for some intel agencies.
I assume any Wi-Fi camera under $150 has basically the same problems. I guess the only way to run a security camera where you don't have Ethernet is to use a non-proprietary Wi-Fi <-> 1000BASE-T adapter. Probably only something homebuilt based on a single board computer and running basically stock Linux/BSD meets that requirement.
> This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities?
The camera sells for $17.99 on their website right now.
Subtract out the cost of the hardware, the box, warehousing, transit to the warehouse, assembly, testing, returns, lost shipments, warranty replacements, support staff, and everything else, then imagine how much is left over for profit. Let's be very optimistic and say $5 per unit.
That $5 per unit profit would mean an additional $100,000 invested in software development would be like taking 20,000 units of this camera and lighting them on fire. Or they could not do that and improve their bottom line numbers by $100,000.
TP-Link has a huge lineup of products and is constantly introducing new things. Multiply that $100,000 across the probably 100+ products on their websites and it becomes tens of millions of dollars per year.
The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development. They take a reference design from the chip vendor, have 1 or 2 low wage engineers change things in the reference codebase until it appears to work, then they ship it.
Both the parent and you can be right in this case.
The parent rightly suggested that there is the obvious intention to exploit these devices:
> This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities?
You explained that there could be an economic reason for the appalling absence of security:
> The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development.
But the parent's point is more convincing, based on the observable evidence and the very clear patterns of state-sponsored exploitation.
The vendors could set default passwords to be robust. The vendors could configure defaults to block upstream access. But maybe the vendors in this particular supply chain are more like the purveyors of shovels in a Gold Rush.
A less-charitable metaphor is possible where state-sponsored motives are unambiguously known.
Is there a table of supported hardware, that contains info about the USB-connection (or ethernet) on these devices. Like, which have data-lines connected, can the device electrically do host and device mode? Can I use a POE2USBC adapter, that presents itself as a USB-network device to the camera?
Ability to filter on those columns would be great.
Is thingino using the Ingenic linux kernel 3.ancient SDK version, or do they have/use something newer?
My initial read of proximity being sufficient to exploit 3 is incorrect, so yeah as long as you control the Wi-Fi network sufficiently then things should be fine.
I have a few of these that I use with unifi for non-critical things over ONVIF and there's a reason they are on a separate vlan and not allowed to access the internet... Thankfully they don't die when you block them from phoning home.
Do you think the S3 bucket with the firmware will be available for the foreseeable future? If not could someone archive it somewhere? Maybe make a torrent out if it? My network is very slow and I estimated it's about 990 GiB of data (by summing the column with the bytes in the ls output the author linked).
It might be useful to have it as a resource in the future for a variety of reasons.
Very interesting, I had a go with Ghidra and AWS Amazon Q, used it to reverse the video feed on a toy drone. I did not think to look for GhidraMCP, would of made it a lot quicker.
If you call up your contactless payment provider, most will send you a physical device that will do contactless payments on its own, for free even. You can tape it to the back of your phone, or anywhere else for that matter.
As soon as i read the author used grok as an ai assistant, i was somehow less interested to keep on reading. Not because of the usage of ai, but the chosen provider. (I don’t know whether grok is just the best choice for this kind of work.)
Is it wrong to judge people for their choice of ai providers?
It's worth interacting with all models. In my experience, for programming questions grok delivered better answers than ChatGPT (and Claude) often enough that at some point I wasn't sure which model I should be asking first.
As @tehlike said in a sibling comment, it looks like it is supported by https://thingino.com, so you can 'update' the firmware to a more secure (and FOSS) one!
Per the article, the attacker can restart the camera and potentially find the accurate position of it. However, if the attacker can be physically in proximity within the camera range, they can MITM it and intercept the video feed. So it depends on your friend's threat model. If the camera is recording something in a public location and they don't mind the location being exposed and potentially the video feed (like plenty of live public cameras), then it shouldn't be an issue. Otherwise, they need to disable it until it gets fixed.
Great article. I have the same model and few months ago I did notice it was restarting in a non-scheduled time, and you can tell it restarts because it does a full rotation. First time it happened I ignored it but the second time I knew something was up so I disconnected it and since then been offline, it was recording an insignificant thing anyway.
So which camera brand has adequately designed software? It’s hard to know as a consumer what to trust or not trust, because how do you evaluate the quality of their work when the device SEEMS to work as expected? Is Ring the only choice?
If the firmware is not open and buildable, then it can only be an untrustable black box.
If you don't want untrustable black boxes hanging around, then your options become pretty limited.
You can DIY something with an SBC like a Raspberry Pi or whatever. You can hang USB cameras off of your computers like it's 2002 again. You can try to find something that OpenIPC or thingino or whatever supports. (You'll never finish with this project as the years wear on, the hardware fails, product availability ebbs and flows, and the scope changes. Maybe that sounds like a fun way to burn time for someone, but it doesn't sound like fun to me.)
Or, you can accept that the world is corrupted -- and by extension, the cameras are also all corrupted.
The safe solution is then actually pretty simple: Use wired-only cameras that work with Frigate (or whatever your local NVR of choice may be), keep them on their own private VLAN that lacks Internet access, and don't worry about it.
The less-safe solution is also pretty simple: Do what everyone else is doing, and just forget the problem exists at all. Switch your brain off, buy whatever, and use it. (And if there's an area that you don't want other people to see, then: Don't put a camera there.)
(We probably are not as interesting as we may think we are, anyway.)
In particular, I don't love it when an article attacks a best practice as a cheap gotcha:
"and this time it was super easy! After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced"
That is a good thing - don't encourage security through obscurity! The impact of an article like this is as likely to get management to prescribe a ham-handed mandate to lock down firmware as it is to get them to properly upgrade their security practices.
Nobody tell them about Linux!
The blogger will blow a gasket when they discover that the likes of GitHub provides access to both installers and software. A hacker's candy store!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
Here, I'll emphasize the words that elicit the tone:
> After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced: [command elided] The entire output is here, for the curious. This provides access to the firmware image of every TP-Link device - routers, cameras, smart plugs, you name it. A reverse engineer’s candy store.
Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
Replace [firmware] with [random popular GitHub repo] and nobody would blink. Replace [firmware] with [customer email address] and it would be a legal case. Differentiating here is important.
Furthermore, the repeated use of every when discussing the breadth of access seems like it would easily fall into the "absolutes are absolutely wrong" way of thinking. At least without some careful auditing it seems like another narrative flourish to marvel at this treasure trove (candy store) of firmware images that has been left without adequate protection. But it seems like most here agree that such protection is without merit, so why does it warrant this emphasis? I'm only left with the possible thought that the author considered it significant.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Only to gullible, clueless types.
Full blown production SPAs are served straight from public access S3 buckets. The only hard requirement is that the S3 bucket enforces read-only access through HTTPS. That's it.
Let's flip it the other way around and make it a thought experiment: what requirement do you think you're fulfilling by enforcing any sort of access restriction?
When you feel compelled to shit on a design trait, the very least you should do is spend a couple of minutes thinking about what problem it solves and what are the constraints.
When in fact TP-Link is doing the right thing with keeping older versions available. So this risks some higher up there thinking 'fuck it, we can't win, might as well close it all off'.
It's a firmware distribution system. It's read-only access to a public storage account designed to provide open access to software deployment packages that the company wishes to broadcast to all products. Of course there is no auth requirement at all. The system is designed to allow everyone in the world to install updates. What compells anyone to believe the system would be designed to prevent public access?
What worries me more is security through herd mentality, where everyone copies the same patterns, tooling, and assumptions. When one breaks, they all break. Some obscurity, used deliberately, can raise the bar against casual incompetence and lazy attacks, which, frankly, account for far more incidents than sophisticated adversaries. We should absolutely design systems that are easy to operate safely, but there is a difference between “simple to use” and “safe to run critical infrastructure.” Not every button should be green, and not every role should be interchangeable. If an approach only works when no one understands it, that is bad security. But if it fails because operators cannot grasp basic layered defenses, that is a staffing and governance problem, not a philosophy one.
Isn’t the complaint that the location of the repo is not publicized?
Nobody would complain if it were linked directly from the company’s web page, I assume?
This page[1] lists the C200 as last having a firmware update in October, but also lists the latest version as 1.4.4 while the article lists 1.4.2. It seems like they have pushed other updated in this time, but not these security fixes.
[1]https://community.tp-link.com/us/smart-home/kb/detail/412852
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
Definitely a problem for regular users.
For anyone concerned about their TP-Link cameras, consider: 1. Disable UPnP on your router 2. Use VLANs to isolate IoT devices 3. Block all outbound traffic except specific required endpoints 4. Consider replacing stock firmware with open alternatives when available 5. Regularly check for firmware updates (though as this article shows, updates can be slow)
The hardcoded keys issue is particularly troubling because it means these vulnerabilities persist across the entire product line. Thanks for the detailed writeup - this kind of research is invaluable for the security community.
When he opened his front door the conversation went something like this:
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.
I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.
He learned about all of the above mitigations that day.
I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.
But it’s worth trying
Neither of these seem like good ideas for someone like me, who is relatively hardware naïve and has small children running around making it hard to concetrate for more than 30 minutes at a time.
The question is genuine. I want to do this but don't actually know by which method.
I’m more than happy to ditch the scrappy RTSP setup that I have to support these cheap cameras!
I generally try not to be a huge Rust cheerleader but seriously. Yikes.
I assume any Wi-Fi camera under $150 has basically the same problems. I guess the only way to run a security camera where you don't have Ethernet is to use a non-proprietary Wi-Fi <-> 1000BASE-T adapter. Probably only something homebuilt based on a single board computer and running basically stock Linux/BSD meets that requirement.
The camera sells for $17.99 on their website right now.
Subtract out the cost of the hardware, the box, warehousing, transit to the warehouse, assembly, testing, returns, lost shipments, warranty replacements, support staff, and everything else, then imagine how much is left over for profit. Let's be very optimistic and say $5 per unit.
That $5 per unit profit would mean an additional $100,000 invested in software development would be like taking 20,000 units of this camera and lighting them on fire. Or they could not do that and improve their bottom line numbers by $100,000.
TP-Link has a huge lineup of products and is constantly introducing new things. Multiply that $100,000 across the probably 100+ products on their websites and it becomes tens of millions of dollars per year.
The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development. They take a reference design from the chip vendor, have 1 or 2 low wage engineers change things in the reference codebase until it appears to work, then they ship it.
The parent rightly suggested that there is the obvious intention to exploit these devices:
> This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities?
You explained that there could be an economic reason for the appalling absence of security:
> The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development.
But the parent's point is more convincing, based on the observable evidence and the very clear patterns of state-sponsored exploitation.
The vendors could set default passwords to be robust. The vendors could configure defaults to block upstream access. But maybe the vendors in this particular supply chain are more like the purveyors of shovels in a Gold Rush.
A less-charitable metaphor is possible where state-sponsored motives are unambiguously known.
For the tech savvy, there is thingino as a firmware alternative - works local only, no cloud, and supports mqtt etc.
ftfy
How does this happen? Doesn’t pretty much every ISP give a router with their modem? How do people manage this?
In IPv6 they likely will auto configure onto a public ip address which may not have a stateful firewall.
(Phones is one notable exception. I need contactless payments to work.)
Is it wrong to judge people for their choice of ai providers?
Every single AI company in my opinion is committing fairly grave misdeeds with the ruthless scraping of the internet and lack of oversight.
Not to mention the shady backdoor deals going on with big tech and the current administration.
Grok is also pretty bad with its whole gas turbines in one state and datacenter in another and some possible environmental issues
It's more of a pick your poison at this point
But doesn't it need to have such free usage in order to overcome image problems? Referring to itself as a Nazi [1][2] for example.
[1] https://www.npr.org/2025/07/09/nx-s1-5462609/grok-elon-musk-...
[2] https://www.politico.com/news/magazine/2025/07/10/musk-grok-...
Can they? I thought they could only do it if they're in the same LAN.
If you don't want untrustable black boxes hanging around, then your options become pretty limited.
You can DIY something with an SBC like a Raspberry Pi or whatever. You can hang USB cameras off of your computers like it's 2002 again. You can try to find something that OpenIPC or thingino or whatever supports. (You'll never finish with this project as the years wear on, the hardware fails, product availability ebbs and flows, and the scope changes. Maybe that sounds like a fun way to burn time for someone, but it doesn't sound like fun to me.)
Or, you can accept that the world is corrupted -- and by extension, the cameras are also all corrupted.
The safe solution is then actually pretty simple: Use wired-only cameras that work with Frigate (or whatever your local NVR of choice may be), keep them on their own private VLAN that lacks Internet access, and don't worry about it.
The less-safe solution is also pretty simple: Do what everyone else is doing, and just forget the problem exists at all. Switch your brain off, buy whatever, and use it. (And if there's an area that you don't want other people to see, then: Don't put a camera there.)
(We probably are not as interesting as we may think we are, anyway.)
No guarantee that it'll be perfect either, obviously, but it's open source and actively maintained. Highly recommended.