On November 2, 2026, Google announced that, working with partner organizations, it had disrupted the previous week a large botnet called XCPE, which had taken over more than 1.3 million set-top boxes. XCPE is a system that lets an outside party control many devices remotely. Google assesses with high confidence that device maker Videostrong intentionally developed, deployed, and operated it for financial gain. According to Google, a backdoor planted at the manufacturing stage slipped through certification testing and loaded malicious code after a device's first boot, using the devices for illicit money-making activity without buyers' knowledge. Google estimates that its actions against related malware will also cut off access to at least 10 million more compromised devices, but these are a separate group from the XCPE devices. In this case, what matters is not only the scale of the infection but also which communication paths were blocked and what remains inside the devices.
A backdoor built in at the factory, slipping past certification tests
XCPE's defining feature is that the malicious program was embedded in the devices from the manufacturing stage. According to Google, Videostrong combined code obfuscation with a mechanism that loads additional code after the first boot, evading existing compatibility and security tests. In other words, the software that could be examined at inspection time differed from the code that actually ran after purchase.
The entry point for the backdoor was a program called "x.cpe" and, on some devices, "com.oemservice." These were built into the firmware that controls a device's basic operation and ran with strong system privileges. They could even reinstall themselves from the device's "/oem/" directory on reboot, even if a user deleted them. Unlike ordinary malicious apps, they ran without users installing anything and were hard to remove through normal app deletion.
Google's reasons for concluding that Videostrong operated the system deliberately include that the backdoor was used across multiple models and brands over several years, that dedicated control infrastructure existed, and that its configuration was continually changed. Google does not believe this was the work of a single rogue insider or a simple development oversight. However, this is Google's high-confidence attribution, not a criminal finding established through judicial proceedings.
The security firm Synthient, which assisted in the investigation, reported its own hands-on analysis and several clues linking the operation to Videostrong. It found com.oemservice on a "MECOOL KM9PRO Max" purchased in late 2025, and confirmed a document signed by Videostrong's head of research and development stored in a publicly accessible directory on the operators' side. It also pointed out that Videostrong's domain and the management-side domain shared an IP address, and that the backdoor's signing information contained several of the company's email addresses. Some signatures from third parties were also found, so the manufacturer was not identified from a single signature alone.
Separating the backdoor from the malware to monetize home connections
In XCPE, the backdoor that handled outside communication, the mechanism that ran additional programs, and the malware that actually generated revenue were kept separate. According to the technical report Google published on November 2, by at least late 2024 the setup had evolved from a single program that installed additional code into a three-layer structure with divided roles.
The entry point, x.cpe, communicated with an external command-and-control (C2) server, while another program, "com.abc.nexus," loaded and ran additional modules. Beyond that, monetization programs prepared by other organizations did the actual work. Google suggests that the separation of communication and execution functions may have been intended to evade detection by security tools.
The configuration and countermeasures confirmed in this case are summarized below.
| Role | Main components and function | Google's response |
|---|---|---|
| Backdoor | x.cpe and others. Built into firmware; relays command-and-control communication with outside parties | Legal action against related domains and servers |
| Execution of additional code | com.abc.nexus and others. Loads and runs additional modules from outside | Command paths blocked. This does not mean complete removal from the devices |
| Illicit monetization | Residential proxy and ad fraud programs operated by other organizations | Action also taken against the control domains of a dozen or so related malware families |
| Device and software supply | Device manufacturing and software supply by Videostrong | Business relationship with Google severed; barred from making or selling certified devices and from supplying software to other certified vendors |
With this structure, even if the device manufacturer and the organizations carrying out the illicit monetization are different, the devices can be exploited through the backdoor. Because additional programs could be loaded later, functions could be changed and new malicious processes added even after devices were sold. For that reason, Google extended its countermeasures beyond the backdoor's control infrastructure to the control domains of the multiple malware families installed through it.
A typical form of illicit monetization is the "residential proxy." This relays third parties' internet traffic through ordinary households' connections, and in XCPE many of the additional modules were related to proxy functions and bandwidth sharing. In "AppSalt/Honeygain," Google found code that called the optIn() function to run processing that normally requires user consent, without displaying a consent screen. This means a household's internet connection could be used for third parties' traffic without the user ever granting permission.
An ad-fraud module called "HiddenView" was also identified. HiddenView loads web pages in a WebView that is not shown on screen and automatically mimics actions such as clicks. This produces fraudulent ad traffic and clicks out of sight of people watching video on their TVs. XCPE's backdoor deleted consent-related settings and disabled Google Play Protect's app verification, installing such additional software without user permission.
The three-layer structure was not kept as is, however. According to Google, from August 2026 the operators moved to single-function installer programs disguised as system apps, timed with a mass deletion of com.abc.nexus. The malware's configuration was changed continually, so the removal of any one program does not mean a device is safe.
Over 1.3 million infected, plus 10 million more: the two figures cover different things
Google's announcement contains two figures of different scope that should be kept apart. The 1.3 million-plus figure is the number of set-top boxes that had been incorporated into the XCPE botnet. The additional "at least 10 million" refers to compromised devices that Google estimates attackers will lose access to as a result of blocking the command-and-control domains of related malware families. The latter includes devices compromised through routes other than XCPE, so it cannot be added to the number of XCPE-infected devices.
In addition to the domains and servers serving as XCPE's entry point, Google took legal action against the control domains of a dozen or so malware families installed through it. This can cut off the paths attackers use to send instructions to devices, but it does not mean the backdoors and malicious firmware left inside the devices have been removed. In XCPE in particular, a mechanism that reinstalls the backdoor after reboot has been confirmed, so this disruption cannot be taken as meaning all infected devices have been repaired.
The malicious activity observed is not limited to proxying and ad fraud. According to Google, the main commands were installing, deleting, and reconfiguring modules, but the exfiltration of account information and logs, live screen capture, and key-input-related operations were also observed. However, the fact that such functions were actually used is not the same as information having leaked from every user, so the extent of harm cannot be judged uniformly.
Most of the affected devices were Android TV set-top boxes, but XCPE activity was also observed on telemedicine devices, karaoke machines, and digital signage. That said, not all Android TV devices or all MECOOL-brand models were infected. The investigation has not confirmed a specific number of infected devices in Japan. Google worked with relevant bodies including Japan's National Police Agency, taking steps not only to block the botnet's communications infrastructure but also against the suppliers of the problematic devices.
The next challenge: verifying code added after shipping
XCPE was discovered not through malfunctioning devices but through suspicious network traffic. According to Plume's explanation, the company noticed communication to suspicious domains several months earlier and, while investigating connection destinations common to devices in various countries, traced it to a malicious agent embedded in firmware. Even when a device plays video normally, a household's connection may be being misused behind the scenes. It is hard to find such problems simply by checking how a device behaves on screen.
Synthient recommends disconnecting suspicious devices from the internet. Google also urged people to choose trustworthy manufacturers and app stores, check app permissions, and enable Google Play Protect. These are, however, general preventive measures and not a way to fully remove a backdoor built in at the manufacturing stage. Where firmware contains a reinstall function as in this case, there is no stated guarantee that ordinary app deletion, updates, or a factory reset can restore a safe state.
Google also took action against Videostrong, the devices' supplier. It barred the company from manufacturing devices preloaded with Google apps, and also prohibited future subsidiaries or affiliates from making or selling certified Android devices and from supplying software to other certified vendors. It further asked distributors and retailers to conduct independent audits of original design manufacturers (ODMs), which design and build products for other brands, and to exclude manufacturers involved in the problem. This appears intended to keep the same backdoor from being brought back to market under different brand names or supply channels.
Google says that, in response to the case, it has revised its certification review procedures and improved the mechanism for verifying firmware integrity on certified Android TV devices. However, details of the new review requirements have not been published, so it is unclear whether similar tactics can be fully prevented.
What XCPE highlights is that verifying safety at shipping time cannot fully guard against malicious code added after sale. Going forward, the key questions will be who can supply new code to devices, and how far that authority and the content of changes can be verified. How well Google's revised certification review and independent audits on the distribution side can address this problem remains to be seen.