# Mobile GUI Agent Model Output Reaching Host Shell / ADB Unsanitized

- **Severity:** Critical
- **Signature ID:** `bb1f5a5f-8f9f-41c6-886f-a5d97ef4227b`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter), AML.T0051.001 (Indirect), AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** ASI05 (Cascading Failures in Multi-Agent Systems), ASI08 (Supply Chain Attacks on Agent Ecosystems), LLM01 (Prompt Injection), LLM05 (Improper Output Handling), LLM06 (Excessive Agency)

## Summary

Some AI agents that operate mobile apps take screenshots, have a vision-language model read the text on screen, and then type that text into the device using shell commands. If an attacker puts malicious text on screen, the model 'reads' it faithfully, and the agent's controller pastes it straight into a shell command without checking it, letting the attacker run arbitrary commands on the operator's own computer.

## How the attack works

An attacker places crafted text on a screen the mobile agent will look at, for example inside an app UI or a webpage the agent is told to interact with. The agent's vision-language model transcribes this text as if it were legitimate input to type. The controller then builds a command line such as an adb 'input text' command and inserts the transcribed text directly into it, often after only stripping spaces. Because the text can contain shell separators, command substitution, or redirects, the inserted content breaks out of the intended argument and executes as a separate command on the machine running the agent. This turns a passive 'read text off the screen' capability into remote code execution on the operator's workstation.

## Why it matters

An attacker who can get text displayed to the agent can execute arbitrary commands on the machine running the agent controller, potentially leading to full compromise of that host, not just the mobile device being automated.

## What you can do

- Never build shell commands by string-interpolating model output or transcribed screen text; use parameterized APIs or argument arrays instead of shell=True string concatenation.
- Apply strict allow-listing and escaping for any text passed to adb, shell, or subprocess calls, and reject or quote command separators, redirects, and substitution syntax.
- Run the agent controller in a sandboxed, low-privilege environment so that command injection cannot reach sensitive host resources.
- Treat all on-screen text as untrusted input and validate/sanitize it before use in any downstream automation action, even when it comes from a trusted-looking app.

## Known benign look-alikes

- Legitimate text typed by the agent that contains a separator immediately followed by a token colliding with a command name, e.g. an adb input text argument carrying 'invoice;rm 402' or 'lab;dd 12'.
- Automation scripts that deliberately chain a GUI action with a real host command on one line, e.g. 'adb shell am start -n com.x/.Main; chmod +x ./collect.sh'.
- Security research repositories, CTF write-ups and framework regression tests that embed the literal injected adb command as a sample payload.
- Controller code that uses shell=True but escapes correctly with shlex.quote(); condition 5 still matches the interpolation shape because the escaping call sits inside the interpolated expression.
- Screen-recording or QA tooling that redirects adb GUI-command output to a relative log file, e.g. 'adb shell input text abc > run.log'.

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02404
- https://arxiv.org/abs/2607.00333
- https://arxiv.org/html/2607.00333v2
- https://thehackernews.com/2026/07/open-source-android-ai-agents-could-let.html
- https://github.com/mnotgod96/AppAgent/blob/main/scripts/and_controller.py

---
Source: https://www.netzilo.com/threats/atr-mobile-gui-agent-model-output-reaching-host-shell-adb-unsani