CVE-2025-22426: Android ComputerEngine URI Escalation Privilege Vulnerability

Technical summary

The vulnerability exists in ComputerEngine.java where insufficient access control validation permits one user's context to access URIs designated for another user's account. The root cause is classified as CWE-284 (Improper Access Control / Permissions), indicating the application fails to properly check whether the requesting user has authorization before granting access to sensitive resources. Multiple functions within the component contain this logic error, suggesting a systematic gap in how URI ownership and user boundaries are enforced. An attacker with local access and a standard user privilege level can exploit this without triggering additional privilege escalation mechanisms or requiring elevated capabilities.

Business impact

This vulnerability creates a significant insider threat and device compromise risk. On a multi-user Android device (common in enterprise deployments, shared devices, or family setups), a single compromised user account or malicious user can laterally access private data, contacts, calendars, messages, or application data belonging to other users. In enterprise environments using Android for work, this could expose confidential business information across separate user profiles. The ease of exploitation—requiring only local access and no special permissions—means the attack surface is every user on the device, and the barrier to execution is minimal. Remediation delays increase exposure window significantly.

Affected systems

Google Android is the affected platform. The source data indicates multiple Android versions are impacted, though specific version boundaries are not enumerated in the provided advisory data. Organizations should verify the exact Android release versions and security patch levels affected by consulting Google's official security bulletin and testing against their deployed fleet. Devices running unpatched or older Android versions are at highest risk.

Exploitability

Exploitability is straightforward. An attacker requires only local access to the device and a standard user account—no root, no special system privileges, and no user interaction needed for the attack to succeed. This makes the vulnerability highly exploitable in real-world scenarios where users have physical or networked local access to a device. The lack of prerequisites combined with the high-severity impact makes this an attractive target for attackers seeking to escalate from compromised user accounts or establish persistence across user boundaries.

Remediation

Apply the Android security patch released by Google that addresses CVE-2025-22426. The fix corrects the logic error in ComputerEngine.java to properly validate and enforce URI access controls across user boundaries. Verification of the exact patched Android version should be performed against Google's official advisory. Until patching is feasible, limit the number of active user accounts on shared devices, disable multi-user features on high-sensitivity deployments if operationally viable, and enforce strong authentication to reduce the risk of account compromise as an attack vector.

Patch guidance

Google has released a security patch for this vulnerability; verify the specific Android version and security patch level from the official Google security bulletin. Apply the patch according to your organization's Android device management process. For enterprise deployments, use Mobile Device Management (MDM) solutions to automate patch distribution and verify compliance. Test patches in a staging environment first, particularly if your organization runs custom applications or ROMs. Monitor the Google Security & Privacy Blog and AOSP announcements for official patch dates. Note that patch availability may vary by device manufacturer and carrier; coordinate with your device suppliers for timeline confirmation.

Detection guidance

Detect exploitation attempts by monitoring for unexpected URI access patterns across user boundaries. On managed devices, enable audit logging and monitor for cross-user resource access requests that would normally be denied. Review Android security logs for permission denial events and access control violations related to ComputerEngine or URI handling. Intrusion detection systems (IDS) monitoring local file system and inter-process communication (IPC) activity may flag anomalous cross-user data access. Additionally, behavioral indicators such as rapid scanning of user directories or URI enumeration from a single user process warrant investigation. After patching, verify the patch version is active across your fleet using MDM compliance reporting.

Why prioritize this

This vulnerability merits immediate prioritization due to its HIGH CVSS score (7.8), local attack vector with low complexity, and complete lack of exploitation barriers. The combination of confidentiality, integrity, and authenticity impact (C:H/I:H/A:H) means a single exploitation can fully compromise user data or device integrity. The logic error affects multiple functions, reducing the likelihood of accidental mitigation through other controls. Multi-user Android deployments and devices with multiple local accounts should be patched first. The absence of KEV designation does not diminish risk—this remains a critical privilege escalation path that should not await active exploitation evidence before remediation begins.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: Local attack vector (AV:L) with low attack complexity (AC:L), requiring only a standard user privilege level (PR:L) and no user interaction (UI:N). The scope is unchanged (S:U), meaning the impact is confined to the vulnerable system. However, all three impact categories are rated high (C:H/I:H/A:H), indicating complete compromise of confidentiality (access to other users' data), integrity (ability to modify other users' resources), and availability (ability to disrupt or destroy other users' data). This high impact across all dimensions, combined with minimal exploitation friction, justifies the HIGH severity classification and places it among the more serious Android vulnerabilities in any given release cycle.

Frequently asked questions