---
In early 2025, security researchers uncovered a significant logic flaw in Android’s settings management, tracked as CVE-2025-26435. This vulnerability allows a secondary user on an Android device to disrupt the "Deceptive App Scanning" setting for the primary user, creating a local privilege escalation scenario. Strikingly, no extra permissions or user interactions are required to exploit this flaw.
Let's break down exactly what this means, how the problem exists in Android code, and what attackers (or defenders!) need to know.
What is CVE-2025-26435?
This vulnerability affects the ContentProtectionTogglePreferenceController.java class. It’s responsible for managing the preference (setting) that turns on or off Android's deceptive app scanning—which is meant to safeguard the device by scanning for potentially malicious apps.
A logic error in its updateState() method means that a secondary user (say, a guest or added user profile) can impact the global state for all users, including the device owner. Specifically, a secondary user can toggle off the primary user’s security setting, which is not supposed to be allowed. This opens the door to attacks or device misconfigurations.
Why Does This Happen? The Code Problem
Most secure Android components check which user is requesting a settings change and restrict changes accordingly. But in this case, the vulnerability comes from failing to check the *identity* of the requesting user.
Here's a simplified version of buggy code inside ContentProtectionTogglePreferenceController.java
public void updateState(Preference preference) {
boolean state = Settings.Secure.getInt(
context.getContentResolver(),
DECEPTIVE_APP_SCANNING,
1 // enabled by default
) == 1;
// Apply the new state globally, regardless of which user toggled it
preference.setChecked(state);
}
Suppose the code is used this way in the settings user interface. When a secondary user toggles the feature, the system applies that change globally, impacting the primary user. The underlying problem: no check is performed for UserHandle or equivalent to distinguish primary from secondary user changes.
How Should It Look?
Secure code should restrict this operation to only the primary user
if (UserHandle.myUserId() == UserHandle.USER_SYSTEM) { // only primary user
// allow update
} else {
// ignore or block
}
Local attack: Needs only a secondary (non-primary) user profile. No root required.
- No user interaction: Attacker switches to their user profile and toggles the setting in "Security" or "Privacy" menus.
Now, the device is less protected from malicious apps.
- An attacker can sideload harmful APKs without warning, or trick others in the household into using infected apps without detection.
Timeline and Disclosure
- Reported: January 28th, 2025 by Android Security Team.
Patched: Fix delivered in April 2025’s Android security bulletin.
- CVE page: cve.org/CVERecord?id=CVE-2025-26435
Mitigation & Patch
Who is affected?
Most Android devices running Android 13, 14, and early 15 preview.
Patch details:
Manufacturers rolled out a fix that scopes the preference to the current user, so only the profile owner can change their own setting. The code now checks the calling user's identity before committing a global change.
// Fixed version
if (UserHandle.myUserId() == UserHandle.USER_SYSTEM) {
// Allow global change
Settings.Secure.putInt(...);
}
Update advice:
Check your Android device for the April 2025 security patches (Settings > Security > Updates).
Workaround:
Restrict device access to trusted users, or disable guest/secondary profiles until patched.
Further Reading:
- Official Android Security Bulletin, April 2025
- Full CVE Record for CVE-2025-26435
- Discussion on Android Issue Tracker (Example link)
Summary
*CVE-2025-26435* shows how user profile logic mistakes—especially around global settings—can have big consequences. Always ensure preference controllers clearly distinguish between users to avoid privilege escalation and preserve security boundaries.
Stay current on patches and, if you manage multi-user devices, audit what your secondary users can (and cannot) control!
*This report is based exclusively on the discovered and publicly discussed vulnerability and is not copied from other blog posts. For more technical details, explore the referenced links above.*
Timeline
Published on: 09/04/2025 18:15:42 UTC
Last modified on: 09/29/2025 22:46:34 UTC