Eine Gruppe von Forschenden der Simon Fraser University, der Chinese University of Hong Kong, der Shandong University und des Xingtu-Labors (QAX) hat auf arXiv eine Arbeit veröffentlicht, die sieben Angriffe gegen fünf offene Frameworks für mobile AI-Agenten demonstriert: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM und MobA. Die Angriffskette beginnt mit für Menschen unsichtbarem Text auf dem Bildschirm eines Android-Geräts und endet mit der Ausführung beliebiger Befehle auf dem PC, der den Agenten steuert. Jedes der fünf Frameworks erwies sich als mindestens gegenüber sechs der sieben gezeigten Techniken verwundbar. Nach Angaben der Autoren wurde eine Ausnutzung unter Realbedingungen bislang nicht beobachtet, und die betroffene Software ist Entwickler-Tooling, das aktivierte USB-Debugging und eine installierte Hilfs-App erfordert.
Anatomie der Kette: vom Pixel bis zur Shell
Das Kernproblem ist das Fehlen einer Sicherheitsgrenze zwischen dem, was das AI-Modell auf dem Screenshot „sieht“, und dem, was es an die System-Shell des Hosts weitergibt. Der Angriff nutzt drei Schwachstellen gleichzeitig aus: die Wahrnehmung des Modells, das Dateisystem des Geräts und den Mechanismus zur Befehlsübergabe.
Unsichtbarer Text, für Modelle sichtbar
Nach Angaben der Forschenden haben alle sechs getesteten Modelle für maschinelles Sehen – darunter GPT-4o, Claude Opus 4.5, Gemini 3 Pro und GLM-4V – Text mit 2% Transparenz in mindestens 18 von 20 Versuchen erkannt. Vier davon erzielten 20/20 Treffer. Unter normalen Betrachtungsbedingungen nimmt das menschliche Auge solchen Text nicht wahr. Das erzeugt eine Asymmetrie: Eine bösartige App mit dem Recht, über anderen Fenstern zu zeichnen, kann Anweisungen platzieren, die für den Nutzer unsichtbar, für den Agenten aber vollständig lesbar sind.
Die Hardware-Variante desselben Problems sind abgerundete Ecken und Kamera-Aussparungen. Der Framebuffer bleibt rechteckig, und die durch den Rahmen verdeckten Pixel landen auf jedem Screenshot. Auf einem Pixel 4 sind das laut der Arbeit rund 78 Pixel Breite in einer Ecke – genug für einen kurzen Befehl. Alle fünf Agenten konnten die Nutzlast aus diesen Bereichen auslesen.
Wettrennen um den Screenshot
Die Frameworks speichern Screenshots im allgemein zugänglichen Speicher des Geräts, bevor sie auf den Host hochgeladen werden. Open-AutoGLM schreibt die Datei an einen festen Pfad /sdcard/tmp.png. Mobile-Agent-v3 verwendet /sdcard/screenshot.png mit einer halben Sekunde Pause zwischen Aufnahme und Abruf. AppAgentX nutzt vorhersagbare Dateinamen mit einem inkrementellen Zähler. Die Standardkonfiguration von AppAgent verweist auf /sdcard.
Die Forschenden haben das Zeitfenster zwischen Schreiben und Lesen der Datei gemessen: von 50 bis 500 ms, im Mittel etwa 210 ms über 100 Durchläufe. Ein Hintergrunddienst, der die Datei alle 5–10 ms abfragt, schafft es, das PNG auszutauschen, bevor der Agent es abholt. Die Erfolgsquote der Ersetzung lag bei vier der fünf Frameworks zwischen 19/20 und 20/20.
Vom Screenshot zur Codeausführung auf dem Host
Das kritischste Glied ist der Controller von AppAgent, der subprocess.run(adb_command, shell=True) aufruft und die Ausgabe des Modells direkt in die Konstruktion adb shell input text {input_str} einsetzt. Der Code entfernt Leerzeichen und einfache Anführungszeichen, filtert aber keine Shell-Metazeichen wie ;, &, >. Die vom Modell vom Bildschirm gelesene Zeichenkette wird von der System-Shell des Hosts aufgespalten, und der zweite Teil wird auf dem Rechner der Bedienperson ausgeführt.
Nach Angaben der Forschenden funktionierte eine Nutzlast zum Start von calc.exe in 20 von 20 Versuchen gegen AppAgent, AppAgentX, Mobile-Agent-v3 und MobA. Ein separater Test mit der Konstruktion test;pwd>rce_success schrieb das Arbeitsverzeichnis des Hosts in eine Datei.
Ungeschützter Eingabekanal
Die Agenten verwenden die Debugging-Mechanismen von Android als primären Kanal zur Interaktion mit dem Gerät. Open-AutoGLM codiert Text in Base64 und sendet ihn über einen impliziten Broadcast ADB_INPUT_B64, der für ADB Keyboard – ein Tool für Testautomatisierung – gedacht ist. Jede App, die sich für denselben Action registriert, erhält dieselben Daten, ohne dass dafür Berechtigungen erforderlich wären.
MobA prüft die Zeichenkette mit text.isascii(): Ein einziger nicht-ASCII-Buchstabe in der Nachricht führt dazu, dass der gesamte Text unverändert per Broadcast gesendet wird. Ein separater Angriff über den Accessibility-Service ermöglicht das Abfangen des eingegebenen Textes, einschließlich Passwörtern, über das Ereignis TYPE_VIEW_TEXT_CHANGED – nach Angaben der Forschenden funktionierte dies gegen alle fünf Frameworks.
Eine weitere Demonstration: Eine gefälschte Login-Activity, die über die echte App gelegt wurde, sammelte in allen 100 Testläufen die Zugangsdaten ein. Keiner der fünf Agenten erkannte die Täuschung.
Kontext: Das Muster wiederholt sich
Das beschriebene Angriffsmodell – LLM-Ausgabe, die in einer System-Shell landet – ist bereits formell anerkannt. Microsoft hat im Mai 2026 ein ähnliches Problem beschrieben in seinem Framework Semantic Kernel, ihm die Kennungen CVE-2026-25592 und CVE-2026-26030 zugewiesen und einen Fix veröffentlicht. Die Formulierung von Microsoft – „your LLM is not a security boundary“ – lässt sich ohne Änderungen auf mobile Agenten anwenden.
Frühere Arbeiten von Wu et al. (Mai 2025) und Ding et al. (Oktober 2025) hatten bereits Prompt Injection über Overlays gegen AppAgent und Mobile-Agent demonstriert. Die neue Arbeit verlängert die Kette über das Gerät hinaus – bis auf den Host der Bedienperson.
Abschätzung der Auswirkungen
Das unmittelbare Risiko wird durch mehrere Faktoren begrenzt: Betroffen sind offene Forschungs-Frameworks und keine integrierten Assistenten (Samsung Bixby und Xiaomi XiaoAi lagen außerhalb des Untersuchungsumfangs); die Angriffe erfordern aktiviertes USB-/drahtloses Debugging und eine installierte App. Allerdings benötigt eine der Angriffsvarianten überhaupt keine bösartige App – die Nutzlast kann in die Farbebenen eines Bildes eingebettet werden, das das Opfer in einem Messenger erhält. Die Autoren präsentieren dies als konzeptionelle Erweiterung, nicht als gemessenen Befund.
Open-AutoGLM hat auf GitHub mehr als 25 000 Sterne, und seine Dokumentation führt Nutzer Schritt für Schritt durch das Aktivieren von USB-Debugging und die Installation der Tastatur – und schafft damit alle Voraussetzungen für die beschriebenen Angriffe, abgesehen von der bösartigen App selbst.
Keines der fünf Repositories verfügt nach vorliegenden Informationen über eine veröffentlichte Security Policy oder einen Kanal zur Meldung von Schwachstellen. Die Forschenden meldeten die Probleme vor Veröffentlichung des Preprints per E-Mail, erhielten nach Aussage des Erstautors jedoch keine Antwort. Für die beschriebenen Probleme wurden keine CVEs vergeben.
Empfehlungen zur Behebung
Die vorgeschlagenen Maßnahmen erfordern keine Modifikation der Modelle selbst:
- Verzicht auf
shell=True– Übergabe der Argumente als Liste (argv), damit Metazeichen Literale bleiben. Open-AutoGLM setzt diesen Ansatz bereits um und ist nach Angaben der Forschenden als einziges der fünf Frameworks gegenüber Command Injection auf dem Host widerstandsfähig. - Streaming von Screenshots über
exec-outstatt Speichern auf dem Gerät mit anschließendem Abruf. MobA verwendet diese Methode bereits und eliminiert damit das Race-Fenster. - Absicherung der Broadcast-Eingabekanäle – Einsatz von Berechtigungen auf Signature-Ebene oder expliziten Intents statt impliziter Broadcasts.
- Kontrolle der Activity – Vergleich der im Vordergrund laufenden Activity vor und nach jeder Aktion und Führen einer Positivliste erlaubter Paketnamen für eine Aufgabe.
- Erhöhung des Kontrasts der Screenshots vor der Übergabe an das Modell – eine teilweise Maßnahme gegen unsichtbaren Text, aber keine vollständige Lösung.
Für Injection über hardwarebedingte Bereiche (Ecken, Aussparungen) stellen die Autoren ausdrücklich fest: „Eine wirksame Software-Lösung existiert nicht.“ Das Maskieren der Ecken ist nur ein Workaround für einen Hardware-Fakt. Der in Open-AutoGLM implementierte Bestätigungsmechanismus für sensitive Aktionen ist nach Einschätzung der Forschenden unzureichend: Wahrnehmungsangriffe überschreiben das Urteil des Modells darüber, was sensibel ist.
Entwickelnde von Frameworks für mobile Agenten sollten umgehend die Command Injection über shell=True beseitigen und auf streamingbasierte Screenshot-Übertragung umstellen – diese beiden Maßnahmen schließen die kritischsten Glieder der Kette, von der Dateimanipulation bis zur Codeausführung auf dem Host. Ebenso wichtig ist die Einrichtung eines formalen Kanals zur Meldung von Schwachstellen: Das Fehlen einer Security Policy in Repositories mit zehntausenden Sternen ist ein systemisches Problem, das Responsible Disclosure in einen Brief ins Leere verwandelt.
