A team of researchers from Simon Fraser University, the Chinese University of Hong Kong, Shandong University and the Xingtu (QAX) lab has published a paper on arXiv demonstrating seven attacks against five open mobile AI agent frameworks: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM and MobA. The attack chain starts with text on an Android device screen that is invisible to a human and ends with arbitrary command execution on the PC controlling the agent. Each of the five frameworks turned out to be vulnerable to at least six of the seven demonstrated techniques. According to the authors, no exploitation in real-world conditions has been observed, and the affected software consists of developer tools that require USB debugging to be enabled and a helper app to be installed.
Anatomy of the chain: from pixel to shell
The key problem is the absence of a security boundary between what the AI model “sees” on the screenshot and what it passes into the host’s system shell. The attack exploits three weak links at the same time: the model’s perception, the device’s file system and the command input mechanism.
Invisible text, visible to models
According to the researchers, all six tested computer vision models — including GPT-4o, Claude Opus 4.5, Gemini 3 Pro and GLM-4V — recognized text with 2% opacity in at least 18 out of 20 attempts. Four of them achieved 20/20. Under normal viewing conditions, human vision does not pick up such text. This creates an asymmetry: a malicious application with permission to draw over other apps can place instructions that are invisible to the user but fully readable by the agent.
The hardware version of the same problem involves rounded corners and camera cutouts. The framebuffer remains rectangular, and pixels hidden behind the bezel end up in every screenshot. On the Pixel 4, according to the paper, this is about 78 pixels in width in one corner — enough for a short command. All five agents were able to read the payload from these regions.
A race for the screenshot
The frameworks save screenshots to the device’s public storage before uploading them to the host. Open-AutoGLM writes the file to a fixed path, /sdcard/tmp.png. Mobile-Agent-v3 uses /sdcard/screenshot.png with a half-second pause between capture and retrieval. AppAgentX uses predictable filenames with an incremental counter. The default AppAgent configuration points to /sdcard.
The researchers measured the window between writing and reading the file: from 50 to 500 ms, averaging about 210 ms over 100 runs. A background service that polls the file every 5–10 ms has enough time to replace the PNG before the agent retrieves it. The success rate of the replacement ranged from 19/20 to 20/20 for four of the five frameworks.
From screenshot to code execution on the host
The most critical link is the AppAgent controller, which calls subprocess.run(adb_command, shell=True) and inserts the model’s output directly into the construct adb shell input text {input_str}. The code strips spaces and single quotes but does not filter shell metacharacters such as ;, &, >. The string read by the model from the screen is split by the host shell, and the second part is executed on the operator’s machine.
According to the researchers, a payload designed to launch calc.exe worked in 20 out of 20 attempts against AppAgent, AppAgentX, Mobile-Agent-v3 and MobA. A separate test using test;pwd>rce_success wrote the host’s working directory into a file.
Unprotected input channel
The agents use Android debugging mechanisms as the main channel for interacting with the device. Open-AutoGLM encodes text in Base64 and sends it via an implicit broadcast ADB_INPUT_B64 intended for ADB Keyboard, a test automation tool. Any application that registers for the same action receives the same data without requiring any permissions.
MobA checks the string using text.isascii(): a single non-ASCII character in the message causes the entire text to be sent as-is via the broadcast. A separate attack via the accessibility service makes it possible to intercept the entered text, including passwords, via the TYPE_VIEW_TEXT_CHANGED event — according to the researchers, this worked against all five frameworks.
Another demonstration: a fake login Activity overlaid on top of the real application collected credentials in all 100 test runs. None of the five agents detected the substitution.
Context: the pattern repeats
The attack model described — LLM output ending up in the system shell — has already received formal recognition. In May 2026, Microsoft described a similar issue in its Semantic Kernel framework, assigning it identifiers CVE-2026-25592 and CVE-2026-26030, and released a fix. Microsoft’s wording — “your LLM is not a security boundary” — applies to mobile agents without modification.
Earlier work by Wu et al. (May 2025) and Ding et al. (October 2025) had already demonstrated prompt injection via overlays against AppAgent and Mobile-Agent. The new paper extends the chain beyond the device itself — to the operator’s host.
Impact assessment
The immediate risk is limited by several factors: the affected components are open research frameworks rather than built-in assistants (Samsung Bixby and Xiaomi XiaoAi were out of scope); the attacks require USB or wireless debugging to be enabled and an application to be installed. However, one variant of the attack does not require a malicious app at all: the payload can be embedded in the chrominance channels of an image that the victim receives in a messenger. The authors present this as a conceptual extension rather than a measured result.
Open-AutoGLM has more than 25,000 stars on GitHub, and its documentation walks the user step by step through enabling USB debugging and installing the keyboard — creating all the preconditions for the described attacks except for the malicious application itself.
None of the five repositories, based on available information, has a published security policy or a channel for reporting vulnerabilities. The researchers reported the issues by email before releasing the preprint but, according to the first author, received no response. No CVEs have been assigned for the issues described.
Mitigation recommendations
The proposed measures do not require modifying the models themselves:
- Avoid
shell=True— pass arguments as a list (argv) so that metacharacters remain literals. Open-AutoGLM already implements this approach and, according to the researchers, is the only one of the five that is resistant to command injection on the host. - Stream screenshots via
exec-outinstead of writing them to the device and then pulling them. MobA already uses this method, eliminating the race window. - Protect input broadcast channels — use signature-level permissions or explicit intents instead of implicit broadcasts.
- Activity control — compare the foreground Activity before and after each action and maintain an allowlist of packages for a given task.
- Increase screenshot contrast before sending it to the model — a partial measure against invisible text, not a complete solution.
For injection via hardware regions (corners, cutouts), the authors explicitly state: “no effective software solution exists.” Masking corners is a workaround for a hardware fact. The sensitive-action confirmation mechanism implemented in Open-AutoGLM is, in the researchers’ assessment, insufficient: perception attacks overwrite the model’s own judgment about what is sensitive.
Developers of mobile agent frameworks should immediately eliminate command injection via shell=True and switch to streaming screenshots — these two measures close the most critical links in the chain, from file substitution to code execution on the host. It is equally important to create a formal channel for reporting vulnerabilities: the absence of a security policy in repositories with tens of thousands of stars is a systemic problem that turns responsible disclosure into sending a letter into the void.
