7月21日、The Hacker Newsが「Open-Source Android AI Agents Could Let Invisible Screen Text Run Code on Host PCs」と題した記事を公開した。オープンソースのAndroid AIエージェントフレームワーク5種すべてが、不可視のスクリーンテキストを介してホストPC上でコードを実行させられる脆弱性を持つことが研究者によって実証された。スマートフォンを操作するGUI自動化エージェントが急速に普及しつつある中、その土台となるフレームワーク群に共通して存在する構造的な欠陥が明らかになった形だ。
20回試して20回成功：calc.exeが起動した
Simon Fraser大学、香港中文大学、山東大学、中国セキュリティ企業QAXのXingtu Labの研究者チームが、5つのオープンソースAndroid AIエージェントフレームワーク（AppAgent、AppAgentX、Mobile-Agent-v3、Open-AutoGLM、MobA）に対して7種類の攻撃を試みた結果、5つ全てが少なくとも6種類の攻撃に対して脆弱であったと報告した。論文は7月1日にarXivに投稿され、7月14日に改訂されている。
攻撃の核心は、モデルの出力がそのままシェルコマンドに渡される点にある。
AppAgentのコントローラーは、subprocess.run(adb_command, shell=True)を呼び出し、モデルの出力を直接adb shell input text {input_str}に埋め込む。入力のサニタイズは一切ない。実際のコードでは多少改善されてスペースとシングルクォートが除去されているが、;、&、>といったシェルのメタキャラクターはそのまま残る。
結果として、モデルが画面から読み取った文字列がホスト側のシェルで分割され、後半部分がオペレーターのWindows上で実行される。calc.exeを起動するペイロードは、AppAgent、AppAgentX、Mobile-Agent-v3、MobAに対して20回中20回成功した。別のテストではtest;pwd>rce_successという文字列でホストのカレントディレクトリをファイルに書き出すことにも成功している。
CVEは現時点で付番されていない。筆頭著者のZidong Zhang氏はThe Hacker Newsに対し、研究室外でこの手法が悪用された証拠はないと述べた。The Hacker Newsが7月17日時点で各フレームワークのmainブランチを確認したところ、スクリーンショットのパス、シェル呼び出し、ブロードキャストのフォールバックといった問題のあるコードはいずれも修正されていなかった。Zhang氏によれば、プレプリント公開前にメンテナーへ個別連絡を送ったが「現時点で返答は得ていない」という。
人間には見えないテキストをAIは読む
コマンドインジェクションの前段として、悪意あるテキストをモデルに読ませる必要がある。研究者らはここで不透明度2%のテキストを用いた。
テストした6つのビジョンモデル（GPT-4o、Claude Opus 4.5、Gemini 3 Pro、GLM-4V等）はすべて、20回中少なくとも18回この低透明度テキストを正確に読み取った。GPT-4o、Claude Opus 4.5、Gemini 3 Pro、GLM-4Vは20/20。論文によれば、2%の不透明度は通常の閲覧条件下での人間の知覚閾値を下回る。テキストをより見えやすくしても精度が上がらないのは、すでに天井に達しているからだ。
スマートフォンの画面角丸とカメラ穴部分も攻撃に利用できる。スマートフォンのフレームバッファは矩形のまま保持されるため、ベゼル下に隠れたピクセルもスクリーンショットには映る。Pixel 4ではこの領域が片隅に約78ピクセル分あり、短いコマンドを仕込むには十分で、5つのエージェント全てがそこから命令を読み取った。
さらにスクリーンショットのファイル競合（TOCTOU）も利用された。エージェントフレームワークは多くの場合、スクリーンショットをSDカードに書き出してからadbでPCに転送する二段階の処理を取る。研究者はこの間隔を100回計測し、平均約210ms（50〜500ms）と測定した。5〜10ms間隔でポーリングするバックグラウンドサービスがファイルロックを取ってPNGを書き換え、解放する余地は十分にある。改ざんは5フレームワーク中4つで19/20〜20/20の成功率だった。
キーボードを誰も認証していない
AIエージェントはAndroid端末に対する公式チャネルを持たないため、デバッグ用の仕組みを流用している。Open-AutoGLMは入力テキストをBase64エンコードしてADB_INPUT_B64というimplicit broadcastに投げ、テスト自動化ツールADB Keyboardがそれを受け取る。ADB Keyboardは「誰からのブロードキャストでも受け付ける」ことを仕様として設計されており、ドキュメント通りに動いているだけだ。問題は、テスト用のハーネスが本番の入力配管として使われている点にある。
MobAはtext.isascii()でASCII判定し、1文字でも非ASCII文字（絵文字や発音記号付き文字）が含まれる場合はメッセージ全体を1つのブロードキャストで送信する。同じActionを登録しているアプリは全て同じペイロードを受け取れ、これにパーミッションは不要だ。
これらの攻撃の前提条件は、エージェント用アプリが既にインストールされており、エージェントがタスク実行中で、USB/ワイヤレスデバッグが有効であること。対象はストックのアシスタントではなく、開発者向けのオープンソースツールであることは付言しておく。
修正できるものとできないもの
研究者らが示した対策のうち、モデルに手を加える必要のないものは以下の通りだ：
shell=Trueを廃止し、argv リストでコマンドを渡す（メタキャラクターがリテラルとして扱われる）- スクリーンショットをストリームで取得する（デバイス側にファイルが存在しなければTOCTOU競合が発生しない）
- 入力ブロードキャストにsignatureレベルのパーミッションを設定するか、explicit intentを使用する
- 各アクション前後でフォアグラウンドActivityをdiffし、タスクごとにパッケージのallowlistを管理する
実際、MobAはスクリーンショットをexec-outでストリーミングしており、デバイス側にファイルが存在しないためTOCTOU競合は発生しない。Open-AutoGLMは引数をリストで渡すため、5つ中唯一ホストコマンドインジェクションに耐性がある。ただし、どちらも両方の対策を実装できているわけではない。
一方、スマートフォンの角丸・カメラ穴を使った攻撃については「ソフトウェアで直截かつ効果的に解決する方法がない」と論文は明言している。ハードウェアの事実に対するマスキングはあくまでワークアラウンドだ。
Open-AutoGLMには「センシティブなアクション」と判断した際の確認プロンプトが実装されているが、認知操作系の攻撃はそもそもその判断を書き換えるため、論文はこれを不十分と評価している。
報告先がない
5つのリポジトリのいずれにもセキュリティポリシーが存在せず、研究者チームはプライベートメールで連絡を試みたが現時点で返答がない。論文はTencentとAlibabaにも最初にアプローチしたと述べるが、研究段階のオープンソースプロジェクトは各社のSecurity Response Centerの対応範囲外とされている。
参考として、MicrosoftはMay 2026に自社のエージェントフレームワークSemantic Kernelにおける同種の問題（モデル出力がシェルに到達するパターン）に対してCVEを3件付番し、パッチリリースまで行っている。Microsoftの端的な表現はそのまま適用できる：「あなたのLLMはセキュリティ境界ではない」。
Open-AutoGLMはGitHubスター2万5千以上を持ち、そのREADMEはUSBデバッグの有効化、キーボードのサイドロード、入力の委譲を手順通りに案内している。ドキュメント通りにセットアップすれば、悪意あるアプリを除く今回の攻撃の前提条件が全て揃う。
詳細はOpen-Source Android AI Agents Could Let Invisible Screen Text Run Code on Host PCsを参照していただきたい。
