CVE-2026-28657 in Android
Summary
by MITRE • 09/08/2026
In onActivityResult of AppWidgetConfigActivityProxy.java, there is a possible unauthorized URI permission grant due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in the Android application component AppWidgetConfigActivityProxy.java represents a classic instance of a confused deputy problem, specifically manifesting as an unauthorized URI permission grant within the onActivityResult callback method. This flaw arises from insufficient validation of incoming data and improper handling of intent extras when processing results from launched activities. In the context of Android security architecture, intents are frequently used to pass references to resources between components, often utilizing Uniform Resource Identifiers (URIs) that require specific permissions for access. When an activity is started with a request code and later receives a result via onActivityResult, it must rigorously verify the source and content of that intent before granting any temporary or persistent URI read/write privileges. The failure to perform these checks allows malicious applications on the same device to craft intents that mimic legitimate responses from trusted system components or other apps, thereby tricking the vulnerable application into granting access to sensitive data without proper authorization.
From a technical perspective, this vulnerability leverages the Android permission model where activities can be launched by any app if exported and lacks sufficient protection mechanisms such as signature-level permissions or explicit component name validation. The attacker exploits the lack of input sanitization in the onActivityResult handler by supplying a crafted URI that points to private files or content providers belonging to other applications or system services. Because the vulnerable code assumes the integrity of the incoming intent based on its origin rather than validating its actual contents, it inadvertently grants read access to these protected resources. This mechanism bypasses standard Android sandboxing rules because the permission is granted by a privileged application component that has legitimate access, effectively acting as an intermediary for unauthorized data exfiltration.
The operational impact of this flaw is significant, particularly regarding local privilege escalation and privacy violations. An attacker with minimal privileges on the device can exploit this vulnerability to read sensitive information stored in private directories or accessed through content providers without requiring user interaction or additional execution privileges. This capability enables the theft of personal data such as contacts, messages, authentication tokens, or other confidential files that are not meant for public consumption. The absence of required user interaction makes this attack vector particularly dangerous and difficult to detect by users, as it occurs silently in the background while potentially running applications may be active.
This vulnerability aligns with CWE-269 Improper Privilege Management, where a process or application fails to properly manage its own elevated privileges, leading to unauthorized access. It also maps closely to ATT&CK technique T1055 Process Injection and related data exfiltration methods in mobile contexts, specifically under the category of Local Application Exploitation. The confusion deputy aspect highlights CWE-842 Uncontrolled Resource Consumption or more accurately CWE-937 Use of Broken Access Control for Sensitive Data, as the application fails to enforce access control policies on sensitive resources exposed via URIs.
Mitigation strategies must focus on rigorous input validation and strict adherence to Android security best practices. Developers should validate all incoming intents in onActivityResult by checking the source package name against a whitelist of trusted applications rather than relying solely on the intent action or data type. Additionally, implementing explicit checks for URI permissions using ContentResolver.takePersistableUriPermission only after verifying the legitimacy of the request is crucial. Applying signature-level protection to exported activities ensures that only apps signed with the same certificate can interact with them, thereby preventing third-party applications from launching these components and triggering the vulnerable code path. Regular security audits focusing on intent handling and permission grants are essential to prevent similar confused deputy attacks in mobile application development.