A home security camera has one job: to keep watch over the places people care about most, the nursery, the front door, the shop floor after hours. A buyer also places quiet trust in every company that had a hand in that camera’s software, almost none of them visible from outside the box.
Finite State recently tested one such camera, a popular budget model, and found the trust misplaced deep in the device’s software. Inside was a serious flaw, first disclosed in 2002, exploitable over the network by anyone who could reach it, and still shipping in units sold in 2026. The camera’s maker, Wansview, fixed the problem thoroughly once notified. The harder question is how it went unseen for so long, and how many comparable devices carry problems no one has thought to look for.
We needed a device for testing, and the only requirement was that an ordinary person could actually buy it. A cheap, well-reviewed camera with steady sales fit, so we pulled its firmware and traced what was running and what it could reach. The flaw was not obscure. A single check of the web server against public vulnerability data would have surfaced it, and no one in the supply chain had run that check before the camera reached people’s homes.
Wansview sells the WVC Q5 as a baby monitor, a pet cam, and a home security device, a low-cost indoor model of the sort that ends up sharing a home network with laptops, phones, and everything else in the house. Buried in its firmware, the software that runs the device, sat a small, long-forgotten web server named jdbhttpd/0.1.0, and inside that server lived CVE-2002-1819, a directory traversal flaw that let anyone on the same network pull private files off the camera without so much as a password.
Age alone rarely determines risk. Outdated components turn up in shipped firmware constantly, and most never matter, because the vulnerable code sits where the device never reaches it. This flaw was the exception, dangerous on the very dimensions that usually keep such bugs harmless. Any device on the network could reach it, and the process it ran in could read every file on the system. The flaw had also moved through the entire supply chain unexamined, from the platform vendor to the brand that relabeled the camera to the retailer that sold it, and none of them recorded it or checked it against a public advisory two decades old.
How One Directory Traversal Flaw Unlocked the Whole Camera
The flaw itself is a directory traversal, a bug security engineers see often and rank as moderate, where a web server returns files from outside the folder it is meant to serve. The camera’s server built the path to each requested file straight from the incoming web request and never checked that the result stayed within that folder. A path stuffed with ../ sequences therefore climbed out of the web root and reached arbitrary files elsewhere on the device, with no password, no login, and nothing but a single HTTP request that any host on the network could send.
What made it dangerous was privilege. The server’s only purpose was to serve saved video images, yet it ran with permission to read every file on the device, and that mismatch handed an attacker the run of the whole system. A handful of requests pulled back the most sensitive material on it:
- The system password and the administrator login, the latter left at the factory default of admin:123456, which unlock the device directly and, given how often passwords are reused across a home network, frequently everything else on it.
- A cloud access token, which logs straight into the manufacturer’s servers, where the live video feed and device settings sit. The footage from a nursery or a front hallway is on the far side of it.
- A copy of the web server program, which moved the rest of the work offline.
The program file proved the most valuable of the three. Pulled apart offline, it revealed two more ways into the camera, each an unauthenticated request that crashes the device on command, and each aimed at software built without the ordinary protections that would normally blunt such an attack. The project ran out of time before either could be pushed to a full remote takeover, but nothing about the device stood in the way, and a determined attacker with more time would likely get there.
These flaws are most dangerous in combination. An attacker who starts with one unauthenticated request can finish with the credentials, the cloud account, a reused password, or the camera itself, quietly repurposed as a permanent listening post inside the network. On a flat home or office network beside medical equipment, industrial controls, or work computers, the reach of that one small device extends to everything around it.
The full research report
This post walks through what we found. The full write-up goes further, with the disclosure timeline, the technical detail behind each finding, and the complete supply-chain analysis.
Read the research report
How a 2002 IoT Vulnerability Ends Up in a 2026 Product
None of this suggests sabotage, and the likely explanation is mundane. Someone building the camera reached for a lightweight, free web server, settled on one that worked, and moved on, most likely without a security review of the choice or any look into the component’s past. Having solved the immediate problem, that developer had no reason to revisit it, and so the web server rode along inside a shipping product for years, unexamined by anyone.
Underneath that is a gap in ownership. Each company in the chain trusted the one before it, and none took responsibility for auditing what it passed along. Nothing about the traversal was hidden or exotic, since it carried a public catalog entry and a freely available exploit the entire time. What was absent was any inventory to test the components against, along with anyone tasked with keeping such an inventory current across the years the product stayed on sale.
The economics of how these devices get built widen the exposure well beyond one product. A white-label device like the WVC Q5 carries a brand that did not build the electronics or write the software inside it. Those come from a platform maker, in this case AjCloud, that produces a base device many brands relabel and sell under their own names, much as store brands roll off the same line as the label beside them. A second manufacturer, IOTECH (Shenzhen) Company Limited, surfaced during disclosure as well.
When a flaw lives in that shared base, it never stays contained to a single product. It ships in every device built on the base, under every logo. Finite State confirmed a fix only on the Wansview unit we tested, so any other product on the same base should be treated as vulnerable until proven otherwise.
The true count is unknown, yet the structure all but guarantees the problem reaches past one brand. The vulnerable web server even makes the affected devices easy to find, since it answers any single request with its own name and version (Server: jdbhttpd/0.1.0), a banner an attacker can scan for at internet scale.
Know What You Ship, Then Prove Which IoT Vulnerabilities Actually Matter
An SBOM would have closed most of this gap on its own. With the components written down, a single query against public vulnerability data flags a 20-year-old known flaw long before the camera reaches a customer, and the failure to write them down is exactly what let this one through. A team cannot patch, monitor, or even weigh a component it has never recorded.
A written inventory is only the first step, and it does not by itself tell a team where the real danger lies. Most of the effort in security goes into counting known vulnerabilities, and most of that count overstates the real threat, because the flawed code usually sits where the device never runs it. Here the pattern reversed, and the camera’s one exposed component, reachable without authentication and running with full privilege, outweighed a thousand entries on a list. What a product contains matters only alongside what an attacker can actually reach, and reachability is where most of the real risk reduction happens.
That combination, an accurate inventory paired with a clear read on what is reachable, is what the Finite State Platform is built to provide. Rather than read the source a team intended to ship, the Platform analyzes the finished software as delivered and identifies the components inside, including the supplier-provided binaries that source-code scanners never see. The result is a ground truth inventory anchored in what actually ships, which then feeds exploitability-based prioritization that ranks findings by what an attacker can reach in a specific build and clears roughly 90% of the noise, so teams spend their hours on the findings that matter. Regulators are moving the same way, and the EU Cyber Resilience Act now requires device makers to keep a current, accurate inventory across a product’s entire service life.
The Right Fix, and the Warning Around It
Wansview handled the disclosure well, and the response deserves as much attention as the flaw. Instead of leaving the unsafe component in place with a patch bolted on, the vendor removed the web server entirely and rebuilt the video feature around a design that no longer exposes the weak point, then delivered the fix to customers automatically over the internet. The update installs on its own whenever a camera is online, so owners had to do nothing to receive it, a better outcome than most consumer devices manage, where unpatched units sit in the field for years because no one thinks to check. That choice, to cut the attack surface out rather than paper over it, is the one the other brands on the same base ought to follow.
A fix on one product does not address the conditions that let the flaw through in the first place. Other brands built on the same base may still be shipping it, and nothing on the packaging tells a buyer either way, which leaves the same obligation on both sides of the sale. Manufacturers should build their software inventory from the device they actually ship rather than from build intentions, keep it current, vet every third-party component for age and support status before it goes in, and put someone in charge of it across the product’s life. Operators should assume they do not know what a device contains and design around that uncertainty, which means a dedicated network segment and no inbound access, since a flaw reachable only over the network is no danger to an attacker who cannot reach it.
A connected device is really an assembly of other people’s code, with the brand serving as a label on the outside. This camera matters precisely because it was ordinary, and ordinary is the problem. The safer posture is to judge a product by what it actually contains rather than by the name on the box, through inventory review and, where the stakes justify it, direct analysis of the shipped software, before the device ever joins a network beside anything that matters. Supply-chain risk is not a threat waiting somewhere in the future; it already shipped, 20 years old, inside a product built in 2026, and catching the next one depends on knowing a product well enough to notice it is there.
See what your firmware actually contains. Book a demo to watch the Finite State Platform break a device’s software down to its components, surface the ones a routine scan never reaches, and rank the rest by what an attacker can actually reach.
Larry Pesce is VP of Technical Research and Offensive Security at Finite State, where he leads firmware and hardware security research on connected devices. This research was conducted by Larry Pesce, Edwin Shuttleworth, and the Finite State security research team.
References
- CVE-2002-1819, Tiny HTTPd / jdbhttpd 0.1.0 directory traversal (original 2002 disclosure)
- EDB-42790, Tiny HTTPd 0.1.0 Directory Traversal proof of concept (Touhid M. Shaikh, September 2017)
The complete write-up, with the disclosure timeline and per-finding detail, lives in the research report.
About Larry Pesce, VP of Services, Finite State
Larry Pesce is a lifelong hacker, educator, and leader in embedded and connected device security. As Finite State’s Vice President of Services, Larry drives strategic security initiatives across the software supply chain, helping product teams build resilient devices from the ground up. With over 15 years of hands-on penetration testing experience spanning IoT, healthcare, ICS/OT, and wireless technologies, he combines deep technical knowledge with real-world expertise. Larry is also a renowned SANS instructor and co-host of the long-running Paul’s Security Weekly podcast, shaping the next generation of security professionals.
Shark robot vacuum flaw exposes fleet-wide IoT risks
Posted in Commentary with tags IoT on July 22, 2026 by itnerdSecurity researcher “tokay0” recently published a serious vulnerability affecting Shark robot vacuums. A certificate extracted from one compromised Shark robot vacuum could be used to access other devices, exposing live camera feeds, stored home maps and Wi-Fi credentials held in plaintext. During a 24-hour observation, the researcher identified more than 1.5 million Shark serial numbers in one AWS region, with approximately 674,000 devices responding to a command probe.
Edwin Shuttleworth, Lead Penetration Tester and Security Researcher at Finite State, offered the following comments:
“This is a classic authentication-versus-authorization failure. The certificate issued to each device correctly authenticated the holder of that device’s private key. An attacker who had fully compromised a vacuum could extract the key and authenticate as that legitimate device. The cloud backend, however, did not correctly enforce authorization. As a result, a validly authenticated device was permitted to access data and perform actions involving other devices it should not have been able to reach.
“This is a common security design mistake: treating a successfully authenticated identity as broadly trusted instead of applying narrowly scoped, per-device permissions. Security professionals reviewing IoT systems should verify both that device identities are unique and that each identity is restricted to its own resources and required operations.
“Manufacturers must assess the complete connected-product environment because the most serious vulnerabilities often arise from interactions between multiple layers rather than a single isolated flaw. This case illustrates that clearly. Weaknesses in the device’s boot and debug protections allowed an attacker to obtain privileged access to the vacuum and extract its credentials. Those credentials were then accepted by the cloud service and granted access to MQTT resources belonging to other devices. Finally, dangerous command-handling functionality allowed cloud-delivered messages to result in remote code execution.
“Individually, each weakness might have appeared limited. Together, they created an attack chain that turned the compromise of one physical device into a potential fleet-scale compromise. Testing firmware, cloud permissions, credential storage or backend infrastructure only in isolation could therefore miss the true severity of the vulnerability.
“Manufacturers should avoid storing sensitive information that is not necessary for the device’s function or business operations and should avoid transmitting sensitive information to the cloud when it is not needed. When information must be transmitted, robust encryption should be used to prevent access by unauthorized parties. Security testing must also be performed early and regularly to prevent compromises like this and minimize their impact when they occur.”
This is precisely why I am working towards making all of my IoT gear, of which I don’t have a lot, not talk to the Internet. My concern is that I don’t know who they are talking to. That is a huge problem as evidenced by this report.
Leave a comment »