Microsoft’s AI Framework Can Let Hackers Control Android Devices Without a Login
- The Mess: A critical vulnerability in Microsoft’s open-source UFO automation framework can expose connected Android devices to unauthenticated remote attackers. CVE-2026-73296, rated CVSS 9.4, affects UFO’s Mobile MCP servers when they are configured for remote access.
- The Damage: An attacker who can reach an exposed server may be able to capture screenshots, inspect the Android UI and use ADB-backed functions to tap, swipe, type text, launch apps and control the connected device. No UFO login, API key or user interaction is required.
- The Fix: Upgrade UFO to version 3.0.8 or later, restrict Mobile MCP services to localhost or trusted networks, and block unnecessary access to ports 8020 and 8021.
Microsoft’s UFO framework is designed to automate devices.
That’s the whole point.
It can connect AI-driven workflows to Android devices and perform actions through Android Debug Bridge.
Unfortunately, the affected Mobile MCP servers could also hand those controls to an attacker.
Without asking for a password.
The AI Agent Wasn’t the Problem
The vulnerable component sits inside UFO’s Mobile Model Context Protocol implementation.
Two services expose Android automation capabilities:
- a data-collection server on port 8020
- an action server on port 8021
By default, the services bind to localhost.
The problem appears when operators expose them for remote access.
In vulnerable versions, the exposed services failed to properly enforce authentication and authorization before accepting MCP requests.
That turns an AI automation interface into a remotely reachable control panel.
Screenshots, UI Data and Device Control
The data-collection service can expose information from the connected Android device, including screenshots, UI hierarchy data, installed applications and device metadata.
The action server is worse.
It exposes functionality backed by ADB.
An attacker may be able to interact with the Android device by sending commands that simulate taps, swipes, text input, key events and application launches.
In other words, this isn’t just another information disclosure bug.
A vulnerable deployment can potentially give an unauthenticated network attacker eyes on the device.
And fingers.
The Dangerous Part Is Remote Deployment
The default configuration limits exposure by binding the services to localhost.
That doesn’t make the vulnerability harmless.
UFO includes remote deployment scenarios where administrators may deliberately bind the services to 0.0.0.0.
Once that happens, every system capable of reaching ports 8020 or 8021 becomes part of the threat model.
An attacker doesn’t need to compromise the Android device directly.
They target the automation server controlling it.
That is a very different attack surface.
One Server Can Become a Bridge to the Phone
Think about what may be visible on a connected Android device:
Email.
Chat messages.
One-time passwords.
Authentication prompts.
Corporate applications.
Private data.
The impact depends on the state of the connected device and what ADB access can reach.
But an attacker doesn’t necessarily need a traditional Android exploit if the automation layer already has permission to interact with the screen.
They can abuse the trusted control channel instead.
That’s where AI and agent infrastructure creates a new security problem.
The agent needs powerful tools to automate things.
Those tools also need to be protected like privileged infrastructure.
A Critical Bug With No Login
The CVSS vector is almost exactly what defenders hate:
AV:N/AC:L/PR:N/UI:N
Network reachable.
Low complexity.
No privileges.
No user interaction.
The vulnerability received a 9.4 Critical rating because it can expose sensitive information and allow unauthorized manipulation of connected Android devices.
This isn’t malware exploiting a phone through a browser.
It’s a management and automation service exposing the controls it was explicitly designed to provide.
To the wrong person.
Patch the Automation Layer
Microsoft UFO versions before 3.0.8 are affected.
Administrators should update, verify whether Mobile MCP servers are remotely exposed and check firewall rules around ports 8020 and 8021.
Teams running AI agents should also start asking a broader question:
What can the agent control?
Because every connected tool is another privileged interface.
An AI agent connected to a database needs database security.
An agent connected to a cloud environment needs cloud security.
And an agent connected to Android through ADB needs the same level of protection as any other remote device-management system.
Bugstoday Opinion
CVE-2026-73296 is a good example of where AI infrastructure is heading.
The dangerous code isn’t necessarily the language model.
It’s everything the model can touch.
Give an agent access to a device.
Add an automation layer.
Expose that automation layer over the network.
Forget authentication.
Congratulations.
You’ve built a remote Android control interface for anyone who can reach it.
Bugstoday verdict: AI agents don’t need to become sentient to become dangerous. Sometimes all it takes is an unauthenticated HTTP server sitting between an attacker and an ADB-connected phone.
Today’s Bugs. Tomorrow’s Breaches.
