How setResult Can Leak Sensitive Data: Android IPC Vulnerabilities Explained

Background

Android offers several inter‑process communication (IPC) mechanisms, and setResult is a relatively special one used for communication between two activities. If the protection around it is flawed, various vulnerabilities can arise, primarily caused by incorrect Intent handling, leading to sensitive data leakage, arbitrary file read/write, local privacy theft, and horizontal privilege escalation.

Principle Introduction

The startActivityForResult(Intent, int) method launches an activity and receives data via onActivityResult(int, int, Intent). When an activity finishes, it can call setResult(int) (optionally with an Intent containing additional data) to return results to its parent.

For example, Activity A starts Activity B with startActivityForResult. Before B is destroyed, it can invoke setResult to pass data back, which Activity A then receives in onActivityResult.

Note: startActivityForResult is deprecated; the official recommendation is to use the Activity Result API.

Typical use cases include dynamic permission requests, photo preview, media sharing, file access, contact selection, etc., making this a special form of cross‑process communication.

Case 1 – ID Theft

Vulnerability Analysis

An app validates user identity via a WebView, then returns the result using setResult. The method setResultAndFinish ultimately calls createResultIntent, which embeds highly sensitive user information.

Because the app returns data regardless of authentication success or user actions (e.g., pressing back, switching apps, closing the page), a malicious app can trigger the component and steal the information.

Exploitation

A malicious app launches the vulnerable component, receives the returned Intent, and extracts the leaked data without the user noticing.

Case 2 – Private File Read/Write

Vulnerability Analysis

The app’s initialization logic eventually calls handleRequestMode and handleResponseResult. In handleRequestMode, a token check passes and the returned Intent carries the entire external input. In handleResponseResult, regardless of the outcome, setResult is executed.

This allows any third party to receive a complete Intent without modification, enabling arbitrary file operations.

Exploitation

By crafting a privileged Intent and launching the victim app, the malicious app receives the original Intent with the victim’s permissions, allowing it to read or write private files.

Case 3 – Phone Number Theft

Vulnerability Analysis

A third‑party app exchanges data with the victim app via startActivityForResult. When the request code is 3, the victim app’s setResult returns the malicious app’s supplied Intent, exposing the same risks as Case 2.

Exploitation

Since the victim app has the CONTACTS permission, the malicious app can retrieve the contact URI from the returned Intent, effectively gaining access to the victim’s contacts, SMS, calendar, storage, etc.

Summary and Outlook

Are you really using setResult correctly and securely?

Widely used APIs are not automatically safe; the more common an API, the more attention developers must pay. Basic protective measures include:

Mark vulnerable components as non‑exported to reject external Intent s.

Validate the source of incoming Intent s (e.g., using getCallingActivity)—applicable only to startActivityForResult.

Sanitize incoming Intent s (e.g., using resolveActivity or rewriting the Intent).

Check Intent flags for URI permissions and remove them if unnecessary.

Anonymize or pseudonymize sensitive data before returning it.

Security must start with fundamental protections—don’t let a tiny hole bring down the whole dam.