CVE-2026-55287 in Android
Summary
by MITRE • 11/02/2026
In onCreate of GrantCredentialsPermissionActivity.java, there is a possible way to trick the user into granting account credentials due to misleading or insufficient UI. 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 • 11/03/2026
The vulnerability identified in the onCreate method of GrantCredentialsPermissionActivity.java represents a critical flaw rooted in deceptive interface design and inadequate user consent mechanisms. As a cyber security specialist, it is evident that this issue falls squarely under CWE-20: Improper Input Validation when considering how the application processes intent data to determine what credentials are being requested, but more critically, it aligns with CWE-829: Inclusion of Functionality from Untrusted Control Source if the activity's behavior is influenced by external inputs without sufficient verification. The core technical flaw lies in the failure to clearly distinguish between legitimate system-level permission requests and potentially malicious or misleading application-driven credential harvesting attempts. By manipulating the visual presentation within the onCreate lifecycle, an attacker can craft a scenario where the user interface displays information that does not accurately reflect the actual permissions being requested by the underlying service. This misrepresentation allows for social engineering attacks to succeed without requiring complex technical exploitation vectors beyond the initial trigger of the activity.
The operational impact of this vulnerability is severe because it facilitates local privilege escalation with minimal barriers to entry. Since user interaction is stated as not needed for exploitation in certain contexts, or rather that the deception occurs before meaningful user engagement can take place, the attacker does not need to trick a user into clicking a specific button after reading a warning. Instead, the misleading UI itself serves as the vector. This means that once an application with this vulnerability is launched or triggered by another component, it may present a fake permission dialog that appears authoritative, such as mimicking system settings or trusted identity providers. The victim may inadvertently grant access to sensitive account credentials because the interface lacks clear indicators of which entity is actually requesting the data. This leads directly to CWE-798: Use of Hard-coded Credentials if the application stores these obtained credentials insecurely, and more broadly to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. The attacker gains unauthorized access to user accounts, enabling further lateral movement within the device or exfiltration of personal data.
From a threat modeling perspective using the MITRE ATT&CK framework for mobile platforms, this vulnerability maps closely to T1589.002: Gather Victim Identity Information: Email Addresses and T1606: Forge Web Credentials. The attacker leverages the trust users place in standard Android permission dialogs by subverting their visual integrity. This is a form of UI redressing or clickjacking variant where the context of the request is obscured. Unlike traditional injection attacks that exploit code logic errors, this vulnerability exploits human-computer interaction design flaws combined with insufficient input validation regarding who initiated the credential request. The lack of robust verification ensures that even if an attacker cannot inject arbitrary code, they can still manipulate the flow to extract high-value tokens or passwords by making them appear as part of a routine system operation.
Mitigation strategies must focus on both technical enforcement and user experience design improvements. First, developers should implement strict validation in the onCreate method to verify the source component requesting credentials against an allowlist of trusted packages. This aligns with CWE-284: Improper Access Control by ensuring that only authorized entities can trigger credential requests through this specific activity. Second, the UI must be redesigned to explicitly display the package name and application label of the requester in a manner that cannot be easily spoofed or obscured. Android provides mechanisms such as using standard permission dialogs provided by the framework rather than custom-drawn views for sensitive operations like granting account credentials. This reduces the attack surface significantly because the system handles the trust verification visually. Additionally, implementing runtime checks to detect if the activity is being launched from an unexpected context can prevent exploitation attempts that rely on indirect invocation paths. Regular security audits focusing on UI/UX flows and adherence to OWASP Mobile Top 10 guidelines, particularly M2: Insecure Data Storage and M5: Insufficient Cryptography, are essential to identify similar deceptive patterns in other parts of the application.