Four Android AI agents ran host-PC commands in 80 of 80 lab trials
Security researchers tested five open-source Android AI-agent frameworks and found every one susceptible to at least six of seven attacks involving hidden screen instructions, spoofed interfaces, screenshot tampering, or unsafe control channels. Host-side command injection succeeded in all 20 trials against each of four frameworks, and a chained AppAgent demonstration turned an instruction hidden on a phone into a command on its Windows controller. The work was confined to laboratory devices and synthetic tasks. No users, production systems, or private data were involved, and the researchers knew of no exploitation in the wild.
Incident Details
Tech Stack
References
A hidden instruction escaped the phone
A July 2026 security paper examined five open-source systems that let a vision-language model operate an Android phone: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM, and MobA. These are third-party research and developer frameworks, rather than assistants built into ordinary retail phones.
Each framework ran on a host computer connected to an Android device through Android Debug Bridge, or ADB. The agent repeatedly captured the phone's screen, sent the image to a vision model, accepted the model's proposed action, and translated that action into an ADB command. Researchers found two places where this arrangement trusted far more than it verified: the pixels treated as an honest picture of the phone, and the debug channels pressed into service as permanent agent plumbing.
The team built seven attacks around those assumptions. Every tested framework was susceptible to at least six. In the most consequential demonstration, text hidden from the phone's user influenced AppAgent, reached an unsafe shell command on the connected Windows laptop, and caused the laptop to execute a second command.
This was a controlled security near miss. The researchers used their own devices, synthetic tasks, dedicated accounts, and harmless proof-of-concept payloads. No production system or private user data was involved. First author Zidong Zhang told The Hacker News that the team had no evidence of the techniques being used outside the laboratory.
Five frameworks under a very specific microscope
The tests used a Pixel 4 running Android 14 and a Motorola Moto G100 running Android 15, both unrooted, plus a Windows 11 host. The malicious test application targeted Android API 35. The ordinary threat model assumed that this app was installed while the user ran one of the agent frameworks with USB or wireless debugging enabled.
The framework tests paired AppAgent and AppAgentX with GPT-4o, Mobile-Agent-v3 with Qwen3-VL, Open-AutoGLM with AutoGLM-9B, and MobA with GPT-4o. The authors substituted Qwen3-VL because the framework's recommended GUI-Owl service was unavailable, and used GPT-4o in place of the deprecated GPT-4V. Those details matter: the results describe those versions, models, devices, tasks, and settings. They do not establish a universal failure rate for every Android agent.
Each applicable attack was run 20 times per framework. The seven tests covered low-opacity text, instructions placed beneath rounded screen corners, a fake login screen, tampering with screenshot files, interception of text sent through Android broadcasts, credential capture through an accessibility service, and command injection on the host PC.
Some attacks needed Android permissions commonly granted to utility apps, such as permission to draw overlays, read shared storage, or operate an accessibility service. Broadcast interception required no permission. The end-to-end host command chain used an already installed malicious app and the framework's required debugging connection, so it was neither a drive-by attack against any Android phone nor a stock handset spontaneously declaring war on its owner's laptop.
The screenshot contained more than the screen showed
Human eyes and image-processing models do not discard the same information. The researchers rendered text in an overlay at opacity levels from 2% to 20%, then measured whether six vision-language models could extract it. At 2% opacity, GPT-4o, Claude Opus 4.5, Gemini 3 Pro, and GLM-4V read the text in 20 of 20 trials. Qwen3-VL-Plus succeeded 19 times, and AutoGLM-Phone succeeded 18 times. Across every tested opacity, results ranged from 18 of 20 to 20 of 20.
That experiment measured text extraction, not automatic obedience to every command an attacker might dream up. The paper treats the hidden display method as a delivery channel that can be combined with prompt injection. It did not optimize a universal jailbreak or prove that any arbitrary sentence will control every model.
Another attack placed an instruction inside pixels physically hidden by rounded corners or camera cutouts but still present in the rectangular screenshot. All five frameworks extracted the hidden-zone payload in the researchers' setup. In a separate spoofing test, a malicious accessibility service placed a fake WeChat login activity over the genuine app. Every agent attempted to enter credentials into the counterfeit interface in 20 of 20 trials per framework, for 100 successful trials altogether.
A human might notice a strange login screen. The agents judged authenticity from the same screenshot the attacker controlled. Giving a model sharper vision did not give it provenance.
Shared storage offered a repainting window
Four frameworks wrote each screenshot to a predictable path on the phone before pulling the file to the host. The paper measured 100 screenshot cycles and found a gap of 50 to 500 milliseconds between those operations, averaging about 210 milliseconds. A background service polling every 5 to 10 milliseconds could lock the image, alter it, and release it before the host retrieved it.
Screenshot tampering succeeded in 19 of 20 AppAgent trials and 20 of 20 trials for AppAgentX, Mobile-Agent-v3, and Open-AutoGLM. MobA avoided that attack because it streamed screenshots directly through exec-out without leaving a device-side file to race. One sensible pipe defeated an entire attack category, which is a useful result amid the cemetery inventory.
The altered image could contain instructions that the user never saw on the physical display. The agent still treated the pixels as current, trustworthy state. This is the time-of-check-to-time-of-use problem in unusually literal form: the framework took a picture, an untrusted app repainted it, and the model received the forgery as evidence.
Model text landed in a host shell
Four frameworks constructed ADB commands by combining model-derived text with shell command strings. Their host code then executed those strings with shell expansion enabled. Characters such as semicolons and ampersands could therefore stop being phone text and become command separators on the computer running the agent.
The researchers tested a harmless payload designed to launch Windows Calculator. It succeeded in 20 of 20 trials against AppAgent, AppAgentX, Mobile-Agent-v3, and MobA, for 80 successes across 80 applicable trials. Open-AutoGLM resisted that particular attack because its command path neutralized the shell metacharacters. The rate applies only to the paper's command-injection setup, not to all seven attacks and not to mobile agents as a product category.
The full chain was demonstrated only against AppAgent during a synthetic WeChat task. A low-opacity overlay told the model to wait three seconds before another screenshot, widening the file-race window. The malicious app then replaced the screenshot with one containing a text payload. AppAgent transcribed that text into its action and passed it through a command built with shell=True. The harmless second command wrote the host's working directory to a file, proving execution outside the Android sandbox.
AppAgent's public Android controller showed the dangerous combination when The Hacker News reviewed it: model text was interpolated into an ADB command, and the helper ran command strings through the host shell. Stripping spaces and apostrophes did not neutralize the metacharacters that give a shell its regrettably broad vocabulary.
Text leaked through borrowed control channels
The study also tested how agents type on a phone. Open-AutoGLM used an Android broadcast accepted by ADB Keyboard. Mobile-Agent-v3 and MobA fell back to broadcasts for Unicode-bearing input. During a synthetic calendar task containing non-ASCII text, a malicious receiver captured the content in 20 of 20 trials against each of those three frameworks. AppAgent and AppAgentX used direct ADB text input and were not affected by that broadcast test.
An accessibility-service attack covered all five frameworks. Android emits text-change events so assistive software can observe interface content. In the test setup, the malicious service received the text the agents entered, including credential-shaped data, in 20 of 20 trials per framework. That route required the user to enable the malicious app as an accessibility service, a meaningful prerequisite rather than decorative fine print.
These results do not mean ADB or Android accessibility was newly broken. The frameworks repurposed debugging, shared storage, broadcasts, and accessibility as an agent control plane without preserving the boundaries those facilities were designed around. The model sat in the middle with permission to act and no reliable way to tell which pixels or messages deserved trust.
No victims, no CVE, and no excuse to round up
The paper covered open-source research prototypes. It did not test Bixby, XiaoAi, other first-party phone assistants, proprietary commercial agents, or iOS. The no-app variant involving an instruction hidden in an image's color channels was described as an extension of the work, not a measured end-to-end result. Claims that any innocent image could already seize thousands of phones would outrun the evidence by several exits.
The Hacker News reported that none of the findings had a CVE and that maintainers had not responded to the researchers by publication. Its own July 17 code review found the described screenshot paths, shell call, and broadcast fallback on the projects' main branches. That confirms relevant code paths remained visible at that snapshot; it does not prove every installation was reachable or that an attacker had used them.
The practical fixes are gloriously unromantic. Host programs should pass commands as argument lists rather than shell-expanded strings. Screenshots should stream through memory instead of resting in shared storage. Text-input broadcasts need authenticated or explicit recipients. Sensitive actions need confirmation based on the proposed action itself, outside the model's interpretation of a possibly poisoned image.
Mobile agents were built to turn what a model sees into what a device does. This research documented what happens when neither side of that sentence carries trustworthy provenance. The exploits stopped in a lab, but the architecture gave them a remarkably short commute from invisible pixels to a Windows shell.
Discussion