
Google and industry partners have disrupted a backdoor that enrolled more than 1.3 million Android set-top boxes into the XCPE botnet. The case is a warning that a device can arrive compromised before an organisation ever connects it to a network.
In a 2 November 2026 report, the Google Threat Intelligence Group said the XCPE backdoor was intentionally developed, deployed, and operated for financial gain by Videostrong Technology, an Android original equipment and device manufacturer. The backdoor appeared in firmware used by set-top boxes and other Android-based devices, including white-label hardware.
The malware used names such as x.cpe and com.oemservice. It ran with system-level privileges, reinstalled itself from the firmware partition after reboot, and could disable Google Play Protect. A separate loader then delivered monetisation modules and additional malware.
Google observed the infected devices being used for residential proxy services and ad fraud. The backdoor also gave operators the ability to install applications silently, execute shell commands, capture screens, collect device and package information, and probe local networks. The result was not just a consumer botnet: an inexpensive connected device could become a privileged foothold inside a home, clinic, hotel, or business network.
The key issue is the trust boundary. XCPE was placed in the firmware ecosystem before the customer bought or configured the device. Traditional endpoint onboarding can therefore miss the most important event: the device was already running unauthorised code when it first appeared on the network.
This is a software supply chain failure with a hardware distribution layer. Certification and app-store controls did not prevent the firmware from carrying a persistent backdoor, while the malware's command and control channel allowed operators to change payloads after deployment. The model also created a market: different affiliates could load proxy, ad-fraud, and secondary malware modules onto the same installed base.
Google says it took legal action against XCPE infrastructure, cut ties with Videostrong, and blocked the company from using Google Android apps and services. That disruption matters, but it does not prove that every affected device is clean. Because some components were installed as system software, a factory reset may not remove them.
Organisations that use Android TV boxes, digital signage, karaoke systems, telehealth equipment, or other white-label Android IoT devices should treat provenance as a security control:
x.cpe, com.oemservice, and com.abc.nexus, but do not treat absence of those names as proof of safety; variants can use different package names.The broader lesson is uncomfortable but practical: certification badges and low-cost hardware do not establish firmware trust. Security teams need supply-chain evidence, network isolation, and an exit plan for devices that cannot be independently verified. When a vendor-controlled update path can install privileged code, the device belongs in the threat model from day one.
Written by
Research
A DevOps engineer and cybersecurity enthusiast with a passion for uncovering the latest in zero-day exploits, automation, and emerging tech. I write to share real-world insights from the trenches of IT and security, aiming to make complex topics more accessible and actionable. Whether I’m building tools, tracking threat actors, or experimenting with AI workflows, I’m always exploring new ways to stay one step ahead in today’s fast-moving digital landscape.
Get the latest cybersecurity insights delivered to your inbox.