Invisible text, visible RCE: five open-source Android AI agents execute host commands via 2%-opacity screen text

TL;DR — 90 seconds

Affected? Five open-source Android AI agent frameworks: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM, and MobA — their current main branches as of July 17, 2026.

What happened? An arXiv study shows that screen text practically invisible to humans (2% opacity) is reliably read by vision models and passed unfiltered by the frameworks into shell commands — resulting in code execution on the host PC.

How critical? In controlled tests, launching calc.exe succeeded in 20 of 20 attempts against four of the five frameworks. There is no CVE entry; the project maintainers did not respond to private disclosure.

Is it being exploited? As far as is known, not outside controlled research settings — the authors explicitly state they found no evidence of real-world exploitation.

What now? Anyone running one of these frameworks in production, or even just testing it with host access, should remove shell=True calls, harden screenshot processing, and restrict debugging access (details below).

What is the problem?

Android AI agent frameworks like AppAgent or Mobile-Agent-v3 control an Android device by sending screenshots to a vision-language model, interpreting its response, and deriving commands from it — usually via the Android Debug Bridge (adb), sometimes with direct access to the host shell the agent runs on. This architecture implicitly assumes the screen content is trustworthy.

That is exactly the assumption the study breaks: an Android app with overlay and storage permissions can lay text at 2% opacity, barely perceptible to humans, over the actual screen content. The authors tested six vision models and found that all six reliably read this practically invisible text in at least 18 of 20 trials — the model does not distinguish between what a human sees and what is actually encoded in the image.

The decisive third step is a classic command-injection flaw: the frameworks pass the commands returned by the model to the shell without validation. Specifically, the authors document that AppAgent's controller runs subprocess.run(adb_command, shell=True) with concatenated strings containing unsanitized model output. As soon as the invisible text influences the model's output, it lands directly in a shell call.

The study describes seven attack vectors in total: screenshot file race (TOCTOU, a 50–500 ms window between capture and retrieval of the screenshot), invisible text overlay (the main vector described above), frame buffer injection (hidden pixels under display bezels — 78+ pixels on a Pixel 4 alone), fake login overlays via accessibility services, interception of broadcast input via the unprotected ADB_INPUT_B64 broadcast, plaintext password capture via TYPE_VIEW_TEXT_CHANGED accessibility events, and a chrominance-channel encoding that was not fully measured.

Who is affected?

Affected is anyone running one of these five frameworks on its current main branch (as of July 17, 2026) — especially with access to a physical or emulated Android device on which a not-fully-trusted app could be installed, or with USB/wireless debugging enabled. None of the five GitHub repositories has a security policy, per the study; the authors report receiving no response to date from the maintainers after private disclosure.

Impact

The demonstrated worst case is code execution on the host PC running the agent — shown in the proof of concept via launching calc.exe, but transferable in practice to arbitrary commands running through the same unfiltered shell path. Anyone running such an agent with broad privileges (developer workstation, CI runner, automation host) risks full compromise of that host through a malicious app on the controlled Android device.

The six accompanying vectors widen the attack surface beyond pure code execution: accessibility-service snooping allows capturing plaintext passwords, fake login overlays enable credential phishing directly within the agent workflow, and intercepting broadcast input can compromise input from other apps on the same device.

A caveat: this is a controlled research study, not a confirmed campaign. The attack precondition — a malicious app with overlay/storage permissions on the same Android device the agent controls — is real but not trivially present in every operating environment.

Mitigation / immediate steps

Code-level fixes (for framework maintainers and contributors)

# 1) Consistently avoid shell=True -- pass arguments as a list so
#    metacharacters (;, &, |, >) stay literal:
#
# Bad:
#   subprocess.run(f"adb shell {command}", shell=True)
#
# Better:
#   subprocess.run(["adb", "shell"] + shlex.split(command), shell=False)
#
# 2) Stream screenshots instead of "write-then-pull" to close the
#    50-500ms TOCTOU window.
#
# 3) Set signature-level permissions on input broadcasts instead of
#    accepting the open ADB_INPUT_B64 broadcast.
#
# 4) Maintain a per-task allowlist of foreground packages instead of
#    processing any screen content unconditionally.

Operational measures (for operators, until a fix ships)

# - Enable USB/wireless debugging only when immediately needed,
#   then disable it again.
# - Add confirmation prompts before security-relevant actions
#   (reduces damage, but doesn't reliably prevent the subliminal
#   text injection itself).
# - Apply contrast enhancement to screenshots before they go to the
#   vision model -- per the study, a partial mitigation, not a
#   complete defense.
# - Don't pair agents with host access to devices that can install
#   third-party apps from unknown sources.

For corner/cutout pixel injection (the frame-buffer vector), the authors explicitly state there is no straightforward, effective software-based solution — here the only real lever is deliberately restricting which devices are allowed for agent control at all.

Detection / verification

Since there is no CVE and no official signature, behavioral detection is the only practical path:

# Search ADB logs for unusual command structures with shell
# metacharacters:
adb logcat | grep -E '[;&|>]'

# Check filesystem activity for rapid screenshot creation/modification
# cycles (an indicator of TOCTOU exploitation):
watch -n 0.1 'ls -la /sdcard/*.png 2>/dev/null'

# Watch for unexpected process spawning from ADB input handlers in
# the agent host's process tree (e.g. via ps --forest or process
# monitoring tools).

# Check accessibility-service registrations of suspicious apps on
# the controlled device:
adb shell settings get secure enabled_accessibility_services

Frequently asked questions about the Android agent invisible-text flaw

[Translate to English:] Operational Decision Block:

• Sofort handeln (heute), wenn: eines der fünf Frameworks mit Host-Zugriff auf einem Gerät läuft, das auch nicht vollständig vertrauenswürdige Apps installieren kann — shell=True-Aufrufe entfernen bzw. den Agenten pausieren, bis das behoben ist.
• Diese Woche prüfen, wenn: eines der Frameworks in einer kontrollierten Testumgebung ohne Fremdgeräte-Zugriff läuft — Risiko geringer, aber die Architekturschwäche bleibt bestehen und sollte vor produktivem Einsatz behoben werden.
• Beobachten, wenn: kein Android-Agent-Framework im Einsatz ist — das grundsätzliche Muster (Modellausgabe ungefiltert an Shell) ist jedoch nicht auf Android beschränkt und lohnt eine Prüfung bei jedem selbst betriebenen KI-Agenten mit Systemzugriff.

Weil keine der fünf Projektseiten eine Security-Policy führt und keine Reaktion auf die private Meldung erfolgte, sollten Betreiber nicht auf einen offiziellen Fix warten, sondern die genannten Code- und Betriebsmaßnahmen selbst umsetzen.

Sources

This analysis draws on the underlying research paper published on arXiv in July 2026 and updated July 14, 2026, along with accompanying technical reporting. Because this is a preprint study without an official CVE assignment, version states and success rates were adopted as reported in the study; independent reproduction of the results was not possible within the scope of this analysis.

I review AI agents with system or device access in your environment for unfiltered shell calls and screenshot/input trust boundaries, and set up detection for prompt and image injection.

Code review of agent controllers for shell=True and similar patterns, hardening of screenshot and input paths, detection setup for unusual shell commands originating from agent contexts.

Platform operation, not paper consulting: I continuously review, harden, and operate your AI agent and automation infrastructure.