This writeup is about CVE-2025-12080, which I discovered in March 2025 and was later awarded a bounty by the Google Mobile Vulnerability Reward Program.

TL;DR

A misconfigured intent handler in Google Messages on Wear OS allowed attackers capable of invoking intents to send messages on behalf of the user without confirmation or explicit permission.

Details

On Wear OS, when Google Messages is the default SMS/MMS/RCS app, ACTION_SENDTO intents using the sms:, smsto:, mms:, and mmsto: URI schemes are handled incorrectly. Because of this misconfiguration, an attacker capable of invoking intents can send messages on the user’s behalf to arbitrary receivers without user interaction and without any required permissions.

Google Messages is the default SMS/MMS/RCS app on many Wear OS devices and alternatives are limited, increasing the likelihood that the vulnerability is exploitable on the majority of Wear OS devices.

For the purposes of this report, the attacker model assumes an app installed on the target device that issues an ACTION_SENDTO intent using one of the vulnerable schemes. Other mechanisms that trigger intents may also be exploitable, though those vectors were not explored in detail here.

Intent Handling

On Android and Wear OS, intents are a core communication mechanism that allow apps and system components to request and perform actions. According to the official Android documentation, “An Intent is a messaging object you can use to request an action from another app component” (Android Developers Guide — Intents and Intent Filters).

An intent defines an action to perform and the data associated with that action. Intents can be explicit or implicit:

• Explicit intents specify the exact component (such as an Activity or Service) to start within a specific app.
• Implicit intents declare an action without naming a target component. In this case, the system searches for apps that have registered an intent filter matching the request.

Each app declares the intents it can handle through intent filters and specifies whether those actions are exposed to other apps or restricted for internal use.

For example, a dialer app can expose to other apps an intent filter that allows it to handle phone-related URI schemes such as tel:. This means other apps can issue an intent with the action Intent.ACTION_SENDTO and data like tel:+1234567890, which causes the system to open the dialer with the phone number pre-filled.

When an intent results in a sensitive operation, the receiving app should present a confirmation interface before executing it. This ensures that users explicitly approve the action and prevents other apps from triggering privileged behaviors indirectly.

This confirmation requirement should also apply to ACTION_SENDTO intents used for sending messages, such as those using the sms:, smsto:, mms:, or mmsto: URI schemes. Normally, the messaging app receiving these intents should prompt the user to confirm before sending the message, ensuring explicit consent for the action. However, on Wear OS, Google Messages does not enforce this expectation. Due to a misconfiguration in the way Google Messages handles these URI schemes, the app sends the message automatically without displaying a confirmation prompt or requiring user interaction.

As a result, any installed app, regardless of its permissions, can issue such an intent and cause a message to be sent on the user’s behalf. This behavior is an instance of the confused-deputy pattern: Google Messages performs a privileged action for an unprivileged caller and violates the expected permission model of Android.

Exploit

The proposed exploit requires an app installed on the target device:

• The app does not need to contain malicious code.
• The vulnerability arises from how Google Messages on Wear OS handles the intent; the intent call in the attacker app is standard and well-formed.
• No special permissions (such as SEND_SMS) are required.

Any app installed on the device could therefore exploit this vulnerability.

Intent Invocation

The application can automatically trigger an ACTION_SENDTO intent when opened or when a button is pressed.

Below is an example code snippet that can be used to invoke the SMS intent:

val smsIntent = Intent(Intent.ACTION_SENDTO).apply {
    data = Uri.parse("smsto:$phoneNumber")
    putExtra("sms_body", message)
}

try {
    context.startActivity(smsIntent)
} catch (e: ActivityNotFoundException) {
    // Handle the error gracefully if no SMS app is available
}

Proof of Concept (PoC)

The complete PoC is available on GitHub at io-no/CVE-2025-12080.

The PoC demonstrates usage of the sms:, smsto:, mms:, and mmsto: URI schemes. A similar behavior could potentially be triggered via Tiles or Complications on Wear OS, since those components can also launch intents.

Tested on:

• Pixel Watch 3 running Wear OS (Android 15 BP1A.250305.019.w3)
• Google Messages messages_android_2025_0225_RC03.wear_dynamic

Note: the PoC supplied leaves the recipient phone number field empty for privacy. Replace it with a real target number when reproducing.

Attack Scenario

An attacker could distribute an app that appears legitimate and silently send messages to arbitrary targets without requiring any user permissions and on behalf of the user. This could lead to several security and financial threats.

Because exploitation does not require permissions, the vulnerability is highly stealthy and difficult for a user to detect. Moreover, while this report focuses on exploitation via an installed app, other intent-triggering mechanisms on Wear OS could potentially be abused.

Disclosure Timeline

• 13 March 2025: Reported through the Google Mobile Vulnerability Reward Program.
• 1 April 2025: 🎉 Nice catch!
• 24 April 2025: A bounty of $2,250.00 was awarded.
• May 2025: A fix was released.