Unsichtbarer Text, sichtbare RCE: Fünf quelloffene Android-KI-Agenten führen über 2-Prozent-Opazität-Text Befehle auf dem Host aus

TL;DR — 90 Sekunden

Betroffen? Fünf quelloffene Android-KI-Agent-Frameworks: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM und MobA — jeweils die aktuellen main-Branches (Stand 17. Juli 2026).

Was ist passiert? Eine arXiv-Studie zeigt, dass für Menschen praktisch unsichtbarer Bildschirmtext (2 % Deckkraft) von Vision-Modellen zuverlässig gelesen und von den Frameworks ungefiltert an Shell-Befehle weitergereicht wird — mit Codeausführung auf dem Host-PC als Ergebnis.

Wie kritisch? In kontrollierten Tests gelang die Ausführung von calc.exe in 20 von 20 Versuchen gegen vier der fünf Frameworks. Es gibt keinen CVE-Eintrag; die Projekt-Maintainer haben auf die private Meldung nicht reagiert.

Wird es ausgenutzt? Nach aktuellem Kenntnisstand nicht außerhalb kontrollierter Forschungsumgebungen — die Autoren betonen ausdrücklich, keine Hinweise auf reale Ausnutzung gefunden zu haben.

Was jetzt? Wer eines dieser Frameworks produktiv oder auch nur testweise mit Host-Zugriff einsetzt, sollte shell=True-Aufrufe entfernen, Screenshot-Verarbeitung härten und Debugging-Zugänge einschränken (Details unten).

Was ist das Problem?

Android-KI-Agent-Frameworks wie AppAgent oder Mobile-Agent-v3 steuern ein Android-Gerät, indem sie Screenshots an ein Vision-Language-Model senden, dessen Antwort interpretieren und daraus Befehle ableiten — meist über die Android Debug Bridge (adb), teils mit direktem Zugriff auf die Host-Shell, auf der der Agent läuft. Diese Architektur setzt implizit voraus, dass der Bildschirminhalt vertrauenswürdig ist.

Genau diese Annahme bricht die Studie: Eine Android-App mit Overlay- und Speicherberechtigungen kann für Menschen kaum wahrnehmbaren Text (2 % Deckkraft) über den eigentlichen Bildschirminhalt legen. Die Autoren testeten sechs Vision-Modelle und stellten fest, dass alle sechs diesen praktisch unsichtbaren Text in mindestens 18 von 20 Testläufen zuverlässig lasen — das Modell unterscheidet nicht zwischen dem, was ein Mensch sieht, und dem, was tatsächlich im Bild kodiert ist.

Der entscheidende dritte Schritt ist ein klassischer Command-Injection-Fehler: Die Frameworks reichen die vom Modell zurückgegebenen Befehle ungeprüft an die Shell weiter. Konkret dokumentieren die Autoren, dass AppAgents Controller subprocess.run(adb_command, shell=True) mit zusammengesetzten Strings ausführt, die unsanitisierte Modellausgaben enthalten. Sobald der unsichtbare Text die Modellausgabe beeinflusst, landet er direkt in einem Shell-Aufruf.

Die Studie beschreibt insgesamt sieben Angriffsvektoren: Screenshot-File-Race (TOCTOU, 50–500 ms Zeitfenster zwischen Aufnahme und Abruf des Screenshots), Invisible-Text-Overlay (der beschriebene Hauptvektor), Frame-Buffer-Injection (versteckte Pixel unter Display-Rändern — 78+ Pixel allein auf einem Pixel 4), gefälschte Login-Overlays via Accessibility Services, Abgreifen von Broadcast-Eingaben über den ungeschützten ADB_INPUT_B64-Broadcast, Mitlesen von Klartext-Passwörtern über TYPE_VIEW_TEXT_CHANGED-Accessibility-Events sowie eine nicht vollständig gemessene Chrominance-Channel-Kodierung.

Wer ist betroffen?

Betroffen ist, wer eines dieser fünf Frameworks in den aktuellen main-Branches (Stand 17. Juli 2026) betreibt — insbesondere mit Zugriff auf ein physisches oder emuliertes Android-Gerät, auf dem eine nicht vollständig vertrauenswürdige App installiert werden könnte, oder mit aktiviertem USB-/Wireless-Debugging. Keines der fünf GitHub-Repositories verfügt laut Studie über eine Security-Policy; die Autoren berichten, nach privater Meldung keine Reaktion von den Maintainern erhalten zu haben.

Auswirkungen

Der demonstrierte Worst Case ist Codeausführung auf dem Host-PC, auf dem der Agent läuft — im Proof of Concept exemplarisch durch den Start von calc.exe belegt, in der Praxis übertragbar auf beliebige Kommandos, die über denselben ungefilterten Shell-Pfad laufen. Wer einen solchen Agenten mit weitreichenden Rechten (Entwickler-Workstation, CI-Runner, Automatisierungs-Host) betreibt, riskiert damit vollständige Kompromittierung dieses Hosts durch eine böswillige App auf dem gesteuerten Android-Gerät.

Die begleitenden sechs weiteren Vektoren erweitern die Angriffsfläche über reine Codeausführung hinaus: Accessibility-Service-Snooping erlaubt das Mitlesen von Klartext-Passwörtern, gefälschte Login-Overlays ermöglichen Credential-Phishing direkt im Agenten-Workflow, und das Abgreifen von Broadcast-Eingaben kann Eingaben anderer Apps auf demselben Gerät kompromittieren.

Einschränkend: Es handelt sich um eine kontrollierte Forschungsarbeit, keine bestätigte Kampagne. Die Angriffsvoraussetzung — eine bösartige App mit Overlay-/Speicherberechtigungen auf demselben Android-Gerät, das der Agent steuert — ist real, aber nicht trivial in jeder Betriebsumgebung gegeben.

Mitigation / Sofortmaßnahmen

Code-seitige Fixes (für Framework-Betreiber und -Contributor)

# 1) shell=True konsequent vermeiden -- Argumente als Liste uebergeben,
#    damit Metazeichen (;, &, |, >) buchstaeblich bleiben:
#
# Schlecht:
#   subprocess.run(f"adb shell {command}", shell=True)
#
# Besser:
#   subprocess.run(["adb", "shell"] + shlex.split(command), shell=False)
#
# 2) Screenshots streamen statt "write-then-pull", um das
#    TOCTOU-Zeitfenster (50-500ms) zu schliessen.
#
# 3) Signaturbasierte Berechtigungen fuer Input-Broadcasts setzen,
#    statt den offenen ADB_INPUT_B64-Broadcast zu akzeptieren.
#
# 4) Pro Task ein Allowlist fuer im Vordergrund erlaubte Packages
#    fuehren, statt jeden Bildschirminhalt bedingungslos zu verarbeiten.

Operative Maßnahmen (für Betreiber, bis ein Fix vorliegt)

# - USB-/Wireless-Debugging nur aktivieren, wenn unmittelbar benoetigt,
#   danach wieder deaktivieren.
# - Bestaetigungs-Prompts vor sicherheitsrelevanten Aktionen einbauen
#   (mindert den Schaden, verhindert aber die unterschwellige
#   Text-Injection selbst nicht zuverlaessig).
# - Kontrastanhebung auf Screenshots anwenden, bevor sie an das
#   Vision-Modell gehen -- laut Studie eine Teil-Mitigation, kein
#   vollstaendiger Schutz.
# - Agenten mit Host-Zugriff nicht mit Geraeten koppeln, auf denen
#   Drittanbieter-Apps aus unbekannten Quellen installiert werden
#   koennen.

Für Corner-/Cutout-Pixel-Injection (Frame-Buffer-Vektor) beschreiben die Autoren ausdrücklich, dass es keine einfache, wirksame Software-Lösung gibt — hier hilft im Zweifel nur, welche Geräte für Agenten-Steuerung überhaupt zugelassen werden, bewusst einzuschränken.

Detection / Prüfung

Da kein CVE und keine offizielle Signatur existiert, ist Verhaltenserkennung der einzig praktikable Weg:

# ADB-Logs auf ungewoehnliche Kommandostrukturen mit Shell-Metazeichen
# durchsuchen:
adb logcat | grep -E '[;&|>]'

# Dateisystem-Aktivitaet auf schnelle Screenshot-Erstellungs-/
# Aenderungszyklen pruefen (Hinweis auf TOCTOU-Ausnutzung):
watch -n 0.1 'ls -la /sdcard/*.png 2>/dev/null'

# Unerwartetes Spawning von Prozessen aus ADB-Input-Handlern
# im Prozessbaum des Agenten-Hosts beobachten (z.B. via ps --forest
# oder Process-Monitoring-Tools).

# Accessibility-Service-Registrierungen verdaechtiger Apps auf dem
# gesteuerten Geraet pruefen:
adb shell settings get secure enabled_accessibility_services

Betreiberempfehlung

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.

Fazit

Diese Studie reiht sich in ein wiederkehrendes Muster bei KI-Agenten mit Systemzugriff ein: Eingabekanäle, die für Menschen als „nur Anzeige“ gelten — hier ein Screenshot —, werden vom Modell buchstäblich gelesen und ungeprüft in Handlung übersetzt. Ohne CVE und ohne Herstellerreaktion liegt die Verantwortung bei den Betreibern selbst: shell=True entfernen, Eingaben validieren, und grundsätzlich hinterfragen, welchem Bildschirminhalt ein Agent mit Systemrechten eigentlich vertrauen darf.

Quellen

Diese Analyse stützt sich auf die zugrunde liegende, im Juli 2026 auf arXiv veröffentlichte und am 14. Juli 2026 aktualisierte Forschungsarbeit sowie begleitende technische Berichterstattung. Da es sich um eine Preprint-Studie ohne offizielle CVE-Zuordnung handelt, wurden Versionsstände und Erfolgsquoten wie in der Studie berichtet übernommen; eine unabhängige Reproduktion der Ergebnisse war im Rahmen dieser Analyse nicht möglich.