CVE-2026-28626 in Android
Summary
by MITRE • 09/08/2026
In onCreate of SetupPassthroughActivity.java, there is a possible way to launch arbitrary activity due to Intent redirection . This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in the SetupPassthroughActivity component represents a critical flaw in Android application security architecture, specifically manifesting as an intent redirect or open redirect issue within the onCreate lifecycle method. This defect arises from improper validation of incoming Intent data, allowing attackers to manipulate the navigation flow by supplying maliciously crafted parameters that cause the activity to launch arbitrary components rather than proceeding with its intended setup logic. In modern Android development, activities often serve as gateways for user interaction and state transitions; when these gates fail to verify the integrity or origin of their input triggers, they become vectors for unauthorized control transfer within the application sandbox.
From a technical perspective, this flaw is categorized under CWE-918, which addresses Server-Side Request Forgery (SSRF) variants in client-side contexts, though more accurately it aligns with CWE-20: Improper Input Validation and CWE-643: Exposure of Incorrectly Resolved URI or URL. The core issue lies in the failure to sanitize or validate the action string, data URI, or extra parameters passed via the Intent before initiating a new activity. By exploiting this weakness, an attacker can redirect the application's execution context to any other exported component within the same package or even external applications if permissions allow, effectively bypassing intended security boundaries and logical controls designed by the developers.
The operational impact of this vulnerability is significant due to its potential for local privilege escalation without requiring additional execution privileges on the device itself. While Android enforces strict sandboxing between apps, an attacker who can trick a privileged or sensitive application into launching a malicious activity gains substantial leverage within that app's security context. This could lead to unauthorized access to private data stored in internal storage, shared preferences, or SQLite databases associated with the compromised application. Furthermore, if the redirected activity interacts with system services or performs actions on behalf of the user without proper re-authentication, it may facilitate further attacks such as session hijacking or manipulation of critical app states that affect overall device security posture.
User interaction is a mandatory prerequisite for successful exploitation, which classifies this vulnerability under social engineering vectors within the MITRE ATT&CK framework, specifically aligning with techniques like T1566: Phishing and potentially T1059: Command and Scripting Interpreter if subsequent actions involve script execution through UI automation. The attacker must deceive a victim into triggering the vulnerable activity, often by embedding malicious links in emails, messages, or web pages that invoke the specific intent action associated with SetupPassthroughActivity.java. Once triggered, the application processes the malformed input and redirects to an arbitrary target, completing the attack chain without requiring root access or prior compromise of other system components.
Mitigation strategies must focus on rigorous input validation and secure component handling practices recommended by industry standards such as OWASP Mobile Application Security Verification Standard (MASVS). Developers should implement strict allow-listing for all Intent actions and data URIs processed within critical activities, ensuring that only expected values are accepted during the onCreate phase. Additionally, utilizing explicit Intents rather than implicit ones where possible reduces ambiguity in component resolution and prevents unintended targeting of other applications. Implementing digital signatures on exported components can also ensure that only trusted sources can invoke these activities, thereby neutralizing redirection attacks originating from untrusted third-party apps or web views embedded within the application environment.