A software flaw first disclosed in 2002 was still shipping inside a home security camera sold in 2026, and nobody along the supply chain noticed. Finite State, a firmware security firm, found CVE-2002-1819 buried in the Wansview WVC Q5, a low-cost indoor camera sold as a baby monitor, pet cam, and home security device. The flaw sits in jdbhttpd/0.1.0, a tiny web server so old that its own banner announces its name and version to anyone who asks.
The flaw is a directory traversal. The camera's web server built the path to each requested file straight from the incoming HTTP request and never checked that the result stayed inside the folder it was meant to serve. A path stuffed with ../ sequences climbed out of the web root and reached arbitrary files elsewhere on the device, with no password and no login, from a single request that any host on the local network could send.
The nut graf: this matters now because the camera is ordinary, and ordinary is the problem. Larry Pesce, VP of Technical Research and Offensive Security at Finite State, said the team picked the device for one reason, that an ordinary person could actually buy it. A cheap, well-reviewed camera with steady sales was enough. The flaw was not obscure either. 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.
What made the bug dangerous was privilege. The server's only job was to serve saved video images, yet it ran with permission to read every file on the device. A handful of requests pulled back the system password and the administrator login, left at the factory default of admin:123456, a cloud access token that logs straight into the manufacturer's servers where the live video feed sits, and a copy of the web server program itself. Pulled apart offline, that program revealed two more unauthenticated ways to crash the device on command, both aimed at software built without the ordinary protections that blunt such attacks. Finite State ran out of time before pushing either to a full remote takeover, but nothing about the device stood in the way.
How the Flaw Moved Through the Supply Chain
The likely explanation is mundane, not malicious. 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. Underneath that sits 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, 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, and anyone tasked with keeping that inventory current across the years the product stayed on sale.
The economics widen the exposure well beyond one product. The WVC Q5 is a white-label device, meaning Wansview put its name on hardware and software it did not build. Those come from a platform maker, AjCloud, that produces a base device many brands relabel and sell under their own names. 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 it tested, so any other product on the same base should be treated as vulnerable until proven otherwise. The true count is unknown, but the structure all but guarantees the problem reaches past one brand.
The 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.
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. 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.
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. A team cannot patch, monitor, or even weigh a component it has never recorded. But 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.
What This Means for Buyers
Regulators are moving the same way. The EU Cyber Resilience Act now requires device makers to keep a current, accurate inventory across a product's entire service life, and that rule will bite hardest on the cheap white-label segment where no one owns the software. For buyers in Indonesia and elsewhere, the practical advice is dull but effective: put IoT cameras on a separate network segment, change the default admin password the day the device goes online, and block inbound access from the internet. A flaw reachable only over the network is no danger to an attacker who cannot reach it.
The camera matters precisely because it was ordinary. A connected device is really an assembly of other people's code, with the brand serving as a label on the outside. 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 the full research report at Finite State for the disclosure timeline and per-finding detail.
For more on connected-device coverage, see our IoT category page.