A payload designed to launch calc.exe did exactly that in 20 of 20 trials against four open-source Android agent frameworks, the researchers report — and in a separate run the same attack wrote the host's working directory to a file.
AppAgent, shell=True, and the path from model text to host shell
The core escalation the paper documents is stark and specific. AppAgent's controller assembles an adb command by interpolating model output into a string and runs it with subprocess.run(adb_command, shell=True). The shipped function performs no sanitization; the live code strips only spaces and single quotes and leaves shell metacharacters such as ;, &, and > intact. That lets a string the model reads from a screenshot become two commands on the operator's Windows host when the host shell splits it. The researchers show a payload that launches calc.exe succeeding 20/20 against AppAgent, AppAgentX, Mobile-Agent-v3, and MobA; a separate end-to-end AppAgent run used the payload test;pwd>rce_success to write the host's working directory into a file.
TOCTOU screenshot races across five agent projects
All five frameworks the team tested — AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM, and MobA — relied on device-side screenshots or fixed paths that created a time-of-check/time-of-use window an attacker can exploit. The researchers measured gaps from screencap write to adb pull at 50–500ms, averaging about 210ms over 100 runs. A background service polling every 5–10ms can take a file lock, repaint the PNG, and release it before the agent collects it; tampering landed 19/20 to 20/20 in four of the five projects. Two projects already show safer patterns: MobA streams screenshots over exec-out and never writes a device-side file, and Open-AutoGLM passes arguments as lists rather than concatenating strings — making it the only one of the five immune to host command injection.
Invisible overlays, corner pixels, and model vision vs. human sight
The paper demonstrates perception attacks that people would likely miss. Six vision-capable models fed to the agents read 2%-opacity text in at least 18 of 20 lab trials; GPT-4o, Claude Opus 4.5, Gemini 3 Pro, and GLM-4V each scored 20/20, while AutoGLM-Phone (a 9B on-device model) was 18/20. The authors observe a practical asymmetry: where humans apply a visibility threshold, the screenshot the agent consumes does not. Hardware quirks matter too — phone bezels and cutouts hide pixels from users but remain in the rectangular frame buffer; on a Pixel 4 the researchers found roughly 78 pixels of hidden width at one corner sufficient for a short command, and all five agents read payloads rendered there. The paper also shows an accessibility trick: a service dropping a fake login Activity and letting the agent type credentials succeeded against all five frameworks across 100 trials.
ADB broadcast plumbing and exposed typing
The agents repurpose debugging channels that were never designed as production input plumbing. Open-AutoGLM base64-encodes text and broadcasts it to ADB_INPUT_B64, a channel ADB Keyboard (a test automation tool) listens for; ADB Keyboard remains maintained, with an April pre-release that addressed Android 16. Mobile-Agent-v3 uses a narrow allow-list, sending non-ASCII characters one at a time over ADB_INPUT_TEXT; MobA tests the full string with text.isascii(), so a single emoji triggers broadcasting the entire message. Any app registering the same broadcast action receives the payload with no permission and no user notification. With accessibility permission, TYPE_VIEW_TEXT_CHANGED hands over the text in plaintext — passwords included — across all five projects. The researchers note that the affected software is open-source developer tooling, not handset-baked assistants, and that first‑party agents and iOS were out of scope.
What this means for open-source maintainers, security teams, and end users
- Open-source maintainers: the paper found no published security policy across the five repositories; the authors emailed maintainers privately before posting the arXiv preprint and, according to first author Zidong Zhang, "have not received a response to date." The Hacker News checked the projects' main branches and found the described screenshot paths, shell call, and broadcast fallback still present as of July 17.
- Security teams and developers: the researchers offer concrete fixes that do not touch the model — drop shell=True and pass argv lists, stream screenshots instead of write-then-pull, put signature-level permission on broadcasts or use explicit intents, diff the foreground activity and keep per-task allowlists, and run contrast enhancement on screenshots (the latter only partial). Open-AutoGLM already ships a confirmation prompt for sensitive actions, but the paper shows prompts are insufficient against subliminal injection, UI spoofing, and the broadcast/accessibility vectors.
- End users: the attacks require real preconditions — an app installed, an agent mid-task, and USB or wireless debugging enabled — but one variant the researchers describe as an extension could embed a payload in an image's chrominance channels so a victim's own agent screenshots it out of a messaging app, requiring no installation.
The paper went up on arXiv on July 1 and was revised July 14; the authors list Simon Fraser University, the Chinese University of Hong Kong, Shandong University, and the Xingtu Lab at QAX. The Hacker News reporting emphasizes there are no CVEs today and the team has "no evidence of the techniques being used outside a controlled setting," a caution the authors and reporters both supply. The episode nonetheless enlarges a simple lesson Microsoft stated in May about agents and shells: "your LLM is not a security boundary." It also leaves a practical governance gap — the projects lack formal vulnerability-disclosure channels, and the combination of developer-friendly documentation (Open-AutoGLM's README walks users through enabling USB debugging and sideloading the keyboard) with default behaviors effectively builds many of the attack preconditions into the standard setup guide.
