Android CVE-2025-48633: when the advisory label and description disagree
Google’s record labels this flaw information disclosure but describes adding a Device Owner after provisioning. Keeping both parts visible changes what a device-management review needs to check.
Android’s bulletin calls CVE-2025-48633 an information-disclosure issue. Google’s detailed description says a logic error could allow a Device Owner to be added after provisioning, with local elevation of privilege. That discrepancy is in the public record, and choosing just one label would hide part of it.
Read the description alongside the label
Google identifies a logic error in hasAccountsOnAnyUser in DevicePolicyManagerService.java. Its prose describes possible post-provisioning addition of a Device Owner and local elevation of privilege without additional execution privileges or user interaction. The same CVE record’s problem-type field says information disclosure. Listed affected versions are Android 13, 14, 15 and 16.
Google’s CVE record, including the classification discrepancy
The December bulletin lists CVE-2025-48633 as a high-severity Framework information-disclosure issue in the December 1 patch set. It reports indications of limited, targeted exploitation for this CVE and CVE-2025-48572. That second identifier is a separate vulnerability; its effects should not be silently merged into this one.
Android’s December 2025 security bulletin
CISA added CVE-2025-48633 to its Known Exploited Vulnerabilities catalog on December 2, 2025, using the information-disclosure classification. The catalog does not resolve the difference between the short label and Google’s mechanism description.
CISA’s Known Exploited Vulnerabilities catalog
Device Owner is a management role
An Android device policy controller can manage a work profile as a Profile Owner or manage a fully managed device as a Device Owner. Those scopes are different. Neither term simply means the person signed in to a Google account, and neither should be confused with ownership of the physical handset.
Android’s device policy controller documentation
Provisioning establishes which controller may enforce policy and over what scope. A check deciding whether to assign that authority is an authorization decision, even when it looks like a routine query about existing accounts.
A device can hold several users or profiles while an eligibility decision concerns the whole device. Reviewing only part of that state may not be enough. The named function points to an account-state check, but Google does not publish the faulty branch or enough prerequisites to reconstruct an attack.
Check the management state as a whole
State to reconcile | Why it matters to the authorization decision |
|---|---|
Existing users and profiles | A device-wide decision must account for the scopes relevant to its policy. |
Account and management state | An ordinary account and an authorized policy controller are different identities. |
Provisioning lifecycle | A transition allowed during controlled setup may be inappropriate afterward. |
Recorded administrative authority | The active controller should agree with the organization’s enrollment record. |
The table lists general questions for a provisioning review, not a claim that Google changed every item in this fix. The implementation needs to evaluate its promised policy against the relevant platform state and reject invalid requests without partly assigning authority. A reassuring settings screen cannot repair a wrong service-side decision.
Google calls this a logic error. There is no disclosed basis for calling it a race condition or supplying a particular account-removal or setup sequence.
Why both descriptions belong in the triage record
A review based only on the information-disclosure label may concentrate on data-read permissions and miss the management-state issue. A review based only on the words Device Owner could overstate access to every resource. The available description needs both its mechanism and its stated limits.
Keep the vendor classification and described authority change together in the record. Ask the supplier to confirm coverage for the exact CVE and build. If there are signs of targeting, include the active management controller, enrollment history and unexplained policy changes alongside evidence of data access.
Check the repair before changing the evidence
Map the installed build to the manufacturer’s December 2025 correction or a later release including it, then reconcile the expected management owner with the inventory. An unexpected controller warrants investigation. A missing console entry alone does not identify this CVE as the cause.
A factory reset cannot explain what happened. It can remove useful state while leaving questions about copied sessions or data unresolved. When targeting is credible, preserve relevant records and plan recovery with the incident responder. This case is also a reminder to review ordinary authorization logic as carefully as memory handling.
Source check: September 8, 2026. This is a historical case from the December 2025 fixes, with public reports of targeted exploitation. It is not a claim about a newly discovered September 2026 vulnerability.
Continue building your baseline.
All articles ↗
Qualcomm CVE-2026-21385: when memory-allocation arithmetic goes wrong
Qualcomm’s flaw concerns alignment calculations during memory allocation. The public record describes local access and targeted exploitation, while device-specific patch coverage depends on the manufacturer.
Android CVE-2025-48595: why the June 2026 patch date matters
The CVE carries a 2025 identifier, but Google’s June 2026 bulletin reports the fix and targeted exploitation. The disclosed issue involves integer overflows and local privilege escalation.