← Back to blog AdvisoryHigh

Mobile MCP Unvalidated URL Android Intent Injection - CVE-2026-35394

Q: What can an attacker do with the unvalidated URL?

Because the `mobile_open_url` tool forwards user-supplied URLs straight to Android's intent system without scheme validation, an attacker can supply non-web schemes such as `tel:`, `sms:`, or content provider URIs. A representative payload is a `tel:` URI carrying a call-forwarding USSD string, which the dialer executes. The impact ranges from placing unauthorized calls and sending SMS messages to USSD-based account manipulation and reading sensitive content providers on the device, all triggered through the Mobile MCP server interface rather than direct device access.

Anomity Research Anomity Threat Research · May 19, 2026 · 4 min read

MCP Server Security·High·CVE-2026-35394·May 19, 2026

Affected Mobilenexthq Mobile MCP prior to v0.0.50

An MCP server with no URL scheme validation can place phone calls, send SMS, and dial USSD codes on a connected Android device - and most security stacks would never see the server, let alone the tool call. That is Mobile MCP intent injection, tracked as CVE-2026-35394, an intent injection flaw in Mobilenexthq Mobile MCP prior to v0.0.50. This advisory covers what the flaw allows, why it is an agentic-endpoint risk, and how Anomity surfaces and governs MCP tool calls at the agent hook.

What happened

CVE-2026-35394 is an intent injection vulnerability in Mobile MCP from Mobilenexthq, an MCP server that lets an AI agent drive a mobile device. In versions before v0.0.50, the mobile_open_url tool passes user-supplied URLs directly to Android's intent system with no scheme validation. Because any URI scheme is accepted, an attacker can trigger sensitive intents far beyond opening a web page - including USSD codes, phone calls, SMS messages, and content provider access.

A representative payload uses a tel: URI carrying a call-forwarding USSD string, delivered through the Mobile MCP server interface, which the device dialer then executes. The impact ranges from unauthorized calls and SMS to USSD-based account manipulation and reading sensitive content providers on the device. The fix in v0.0.50 enforces proper URI scheme validation so only safe schemes reach the intent system. This is the same class of unreviewed, high-capability MCP wiring covered in the MCP Server Security guide.

Why this is an agentic-endpoint risk

Mobile MCP is an AI artifact: an MCP server installed next to an agent so the agent can act on a device. It is one of the eight AI artifact types that live on managed endpoints and that traditional controls were never built to inventory. The flaw is not a classic network exploit - it is the agent invoking a tool exactly as designed, with input that was never constrained. That is what makes intent injection an endpoint problem rather than a perimeter one.

CVE-2026-35394 also widens the MCP attack surface in a direction defenders have not had to model. Earlier MCP cases concentrated on servers and shells - for example the standard-I/O execution surface covered in Anthropic MCP stdio RCE by design and the unauthenticated transport in MCPJam Inspector Remote Code Execution - CVE-2026-23744. This flaw pushes the surface into device-level actions: a single unvalidated tool argument reaches the Android intent system and the telephony stack behind it. The wiring that grants that capability lives in a config no perimeter tool reads, which is exactly the blind spot Anomity covers alongside your stack.

How Anomity surfaces and governs it

Anomity inventories the MCP servers wired into agents on every managed endpoint and treats Mobile MCP as a first-class artifact. It captures the configuration metadata, surfaces the exact version in use, and classifies the server - so finding every Mobile MCP instance prior to v0.0.50 is one query against your fleet inventory rather than a manual hunt across laptops.

Inventory tells you where the risk is; the hook is where it stops. On agents that expose a hook (for example, the PreToolUse event in Claude Code), Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A mobile_open_url call carrying a tel:, sms:, or other non-web scheme can be denied even on an unpatched server, which gives you runtime governance while the upgrade to v0.0.50 rolls out. Anomity collects metadata only, with on-endpoint secret redaction, so a tool argument is evaluated without shipping its contents off the device.

Every added, changed, or removed server, and every allow or deny decision, is recorded in a queryable 90-day audit trail you can route to SIEM, Slack, email, or Jira. That gives you proof of which endpoints ran a vulnerable Mobile MCP, when it was upgraded, and which intent-bearing tool calls were blocked in the interim.

What to check across your fleet

Inventory every endpoint for Mobilenexthq Mobile MCP and record its version; upgrade anything prior to v0.0.50.
Where upgrading is not immediate, front the tool with a proxy that restricts URLs to http and https, or disable mobile_open_url entirely until patched.
Add a policy at the agent hook that denies mobile_open_url calls carrying non-web schemes such as tel:, sms:, or content provider URIs.
Identify which agents can drive a connected or emulated Android device through Mobile MCP, and scope that capability to who actually needs it.
Review the audit trail for recent mobile_open_url calls and for Mobile MCP installs or version changes triggered outside normal workflows.

This advisory is part of our MCP Server Security guide. To see which endpoints run a vulnerable Mobile MCP and govern the tool calls before they reach the device, book a 30-minute demo.

Frequently asked questions

Am I affected by CVE-2026-35394?

You are exposed if any managed endpoint runs Mobilenexthq Mobile MCP at a version prior to v0.0.50 and that server can drive a connected or emulated Android device. The mobile_open_url tool accepts any URI scheme with no validation, so an attacker who can influence the agent's input can reach the Android intent system. Upgrading to v0.0.50 enforces scheme validation. The harder problem is knowing which endpoints run the server in the first place, which requires a fleet inventory of the MCP servers wired into your agents.

What can an attacker do with the unvalidated URL?

Because the mobile_open_url tool forwards user-supplied URLs straight to Android's intent system without scheme validation, an attacker can supply non-web schemes such as tel:, sms:, or content provider URIs. A representative payload is a tel: URI carrying a call-forwarding USSD string, which the dialer executes. The impact ranges from placing unauthorized calls and sending SMS messages to USSD-based account manipulation and reading sensitive content providers on the device, all triggered through the Mobile MCP server interface rather than direct device access.

How do I remediate CVE-2026-35394 if I cannot upgrade immediately?

The fix in v0.0.50 enforces URI scheme validation so only safe schemes reach the intent system, and upgrading is the durable answer. Where you cannot upgrade right away, front the tool with a proxy that restricts URLs to http and https, or disable the mobile_open_url tool entirely until the server is patched. Both are stopgaps. Pair either one with a policy at the agent hook that denies the specific tool call, so an unpatched server still cannot reach the intent system through the agent on your endpoints.

How does Anomity help with Mobile MCP intent injection?

Anomity inventories the MCP servers wired into agents on every managed endpoint, surfaces the version in use, and flags Mobile MCP instances prior to v0.0.50 so finding every vulnerable copy is one query. On agents that expose a hook, it evaluates each tool call before it runs and returns allow, deny, or log, so a mobile_open_url call carrying a non-web scheme can be denied even on an unpatched server. Every install, version change, and decision lands in a queryable 90-day audit trail you can route to SIEM, Slack, email, or Jira.