Google shut down a *botnet hidden in Android TV boxes*. Here's what it means for product liability

A backdoor at the factory

In late October 2026, Google's Threat Intelligence Group announced it had disrupted XCPE, a botnet running on over 1.3 million Android TV set-top boxes. The backdoor wasn't installed by criminals who had hacked the devices. It was built into the firmware by the manufacturer, Videostrong Technology, which then sold access to criminal affiliates for proxy services, credential stuffing and ad fraud ^[1].

Google blocked the devices from its services and banned Videostrong from its Android TV partner programme. For the people who bought the boxes, many of which were sold under third-party brands, the question is simpler: who is responsible when the thing you bought comes with a vulnerability straight from the factory?

The answer is about to get clearer, because two new EU rules change who carries the risk when connected products go wrong.

In short

• From 9 December 2026, software counts as a product under the EU's new Product Liability Directive, with strict liability for damage to personal property and data not used professionally ^[2].
• From 11 September 2026, manufacturers must report actively exploited vulnerabilities and serious incidents to national authorities within 24 hours, and again within 72 hours with an assessment and any mitigation ^[3].
• Product liability covers death, personal injury, damage to property not used exclusively for work, and destruction or corruption of data not used for work. Courts can order defendants to hand over relevant evidence.
• The backdoor in XCPE illustrates both rules: it was part of the product, and it was exploited at scale.

Software as a product

The new Product Liability Directive treats software, including AI systems, as a product. That means strict liability: if a defective product causes damage, the person harmed doesn't have to prove the manufacturer was negligent, only that the product was defective, that they suffered damage and that the defect caused it ^[2].

Think of it like a kettle with a faulty element. If it catches fire and damages your kitchen table, the manufacturer is liable. You don't have to show they were careless. The same logic now applies to the firmware in your set-top box, the app on your phone and the software in your car's infotainment system, as long as the product reached the market after 9 December 2026.

The directive covers damage to property and data that isn't used exclusively for professional purposes. A backdoor that bricks your home TV box or uses it to harvest credentials for your personal email would fall within scope. Your work laptop, less obviously so.

Reporting duties under CRA

The Cyber Resilience Act, which applies from 11 September 2026 for reporting duties, sets out a tight timetable. Manufacturers must submit an early warning to ENISA's common platform within 24 hours of becoming aware of an actively exploited vulnerability or a serious incident. Within 72 hours they must follow up with an assessment, the severity, whether it affects other manufacturers, and any mitigation. A final report is due within 14 days ^[3].

The 24-hour clock starts when you become aware, not when it suits you. It's like losing your bank card: the timer starts when you notice, and saying you were busy doesn't reset it.

XCPE would have triggered both the vulnerability and incident reporting paths, had CRA been in force. The backdoor was actively exploited, it affected over a million devices, and criminal affiliates were using it for fraud and credential harvesting.

Who is liable, and for what

Under the Product Liability Directive, the manufacturer is the first in line. If the manufacturer is outside the EU and has no authorised representative here, the importer is liable. If neither can be identified, the distributor can be held liable ^[2].

Videostrong manufactured the devices. The retailers who sold them under other brands, if they were EU importers, could find themselves liable if Videostrong cannot be reached. That's a question any retailer of connected devices will want to ask before the goods leave the warehouse: if this thing turns out to have a backdoor, who is the manufacturer, and can we reach them?

Liability is strict, but it isn't absolute. A manufacturer can avoid it by showing, among other things, that the defect didn't exist when the product was placed on the market, or that the state of scientific and technical knowledge at the time made it impossible to discover. A backdoor deliberately built into the firmware at manufacture would struggle on both counts.

The evidence question

Product liability disputes often turn on which version of the software was running, and when. The directive gives courts power to order the defendant to disclose relevant evidence, and allows a rebuttable presumption of defectiveness or causation when the claimant faces excessive difficulties in proving their case ^[2].

So if a court asks what firmware version was on a device on a given day, and whether it has been changed since it left the factory, the question isn't hypothetical. Version control was built for engineers, not for litigation. The gap is whether the record can be shown unchanged, when the people keeping the record are the ones being questioned.

How a digital witness fits here

This is a case where a digital witness fits well, because the problem is showing which version existed and what it contained.

Here, the thing to seal is each firmware release as it is built: a fingerprint of the build, the release notes and, if they exist, test results. Your build system sends the fingerprint, not the firmware itself, to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. The firmware stays in your repository.

Sealing happens at release. When a dispute arises, anyone you share the release package with can calculate the fingerprint again and compare it with the sealed one. If it matches, the package is the one that existed at that time, unchanged. Change a single byte and it won't match.

Anyone can check it: the customer, a court, an insurer or a notified body. The first 2,000 witnesses a month are free. Read the docs.

What it doesn't do is show that the firmware was free of defects, that it was secure, or that the version sealed was the one actually shipped to a particular device. It shows that the release existed at a point in time, unchanged since then.

How it would work

1. At each firmware build, your CI/CD pipeline takes a fingerprint of the release package and test output, and sends it to WitniumChain.
2. The seal is recorded with a timestamp. The firmware itself never leaves your systems.
3. When someone questions which version ran on a device, you share the release package and the witness ID. They calculate the fingerprint and check it matches.

What this means for you

If you manufacture, import or sell connected consumer devices, here are three questions to ask before 9 December 2026:

• Can you show which firmware or software version was on a device when it left your control, and that it hasn't been altered in your records since?
• If a vulnerability is exploited in one of your products, do you have a process to detect it and report it within 24 hours?
• If your supplier is outside the EU and cannot be reached, are you prepared to be treated as the manufacturer for liability purposes?

The XCPE case won't be the last time a product reaches the market with a built-in flaw. The new rules put the risk squarely on the people who made it, imported it or sold it, and they expect you to have the records to show what you shipped and when.

What to watch

• 11 September 2026: CRA reporting duties apply.
• 9 December 2026: new Product Liability Directive applies to products placed on the market from this date.
• 11 December 2027: CRA essential requirements (Annex I) apply, including logging and vulnerability handling.