EUVD-2025-210010
GHSA-972f-8p3j-73wm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInstall low-privileged app on head unit
-
DeliveryInvoke CarDevicePolicyService.setUserDisclaimerAcknowledged
-
ExploitBypass missing permission check
-
ExecutionMark disclaimer accepted silently
-
PersistTrigger managed-account addition flow
-
ImpactGain enterprise account privileges on vehicle
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires (1) an Android device that ships the Car/Automotive framework where CarDevicePolicyService is present - typically Android Automotive OS head units, not standard phones or tablets; (2) the device must be in or be transitioning into a managed-device configuration where the user disclaimer dialog is the gating control for account addition; and (3) attacker code must already be running locally on the device with at least low privileges (PR:L), i.e. as an installed app. Exploitation does NOT require user interaction (UI:N), does NOT require network access (AV:L), and does NOT require pre-existing high privileges. Limiting factors: the bug is unreachable on Android builds without the Car framework, has no remote attack surface, and its practical impact is constrained to bypassing the disclaimer consent step rather than achieving arbitrary code execution as system. |
| Impact | The CVSS 7.8 base score is driven by AV:L/AC:L/PR:L/UI:N with C:H/I:H/A:H, meaning a locally installed, low-privileged app can exploit it with no user interaction - high theoretical impact on a single device. Counter-signals dampen real-world urgency: EPSS is 0.01% (1st percentile), SSVC reports Exploitation=none and Technical Impact=partial (notably less alarming than the CVSS H/H/H triad would suggest, since the practical effect is bypassing one consent dialog rather than full system compromise), and Automatable=no. There is no public exploit identified at time of analysis and this CVE is not on CISA KEV. There is a notable tension between the CVSS impact ratings and SSVC's 'partial' technical impact - security teams should weight SSVC here, as the underlying flaw is a consent-UI bypass on a niche surface (managed automotive devices) rather than a generic root escalation. Net: legitimate to patch on schedule, not an emergency for fleets that don't deploy managed Android Automotive units. |
| Exploit ScenarioDerived | A malicious app installed on a managed Android Automotive head unit (e.g., a fleet vehicle, rental, or rideshare car) calls CarDevicePolicyService.setUserDisclaimerAcknowledged directly, marking the disclaimer as accepted without ever showing it to the driver. The device-policy flow then proceeds to silently add an attacker-controlled enterprise account to the vehicle, granting it the elevated capabilities a managed account is normally trusted with on the head unit. No public exploit is identified at time of analysis and no user interaction is required once the malicious app is running locally. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jun 03, 2026
Local privilege escalation in Google Android 14 and 15 allows a low-privileged app to bypass the user disclaimer dialog when adding an account to a managed automotive device, due to a missing permission check in CarDevicePolicyService.setUserDisclaimerAcknowledged. The flaw enables silent account provisioning on managed (enterprise) car devices without the user's awareness or consent, and no public exploit is identified at time of analysis. EPSS is negligible (0.01%) and SSVC marks exploitation as 'none', so the issue is real but not currently weaponized.
Earlier versions of this analysis (2)
Local privilege escalation in Android 14 and 15 stems from a missing permission check in CarDevicePolicyService.setUserDisclaimerAcknowledged, allowing a low-privileged local app to bypass the user disclaimer dialog when adding an account to a managed Automotive (Android Auto) device. No public exploit identified at time of analysis, and EPSS is very low (0.01%), but Google addressed the issue in the June 2026 Android Security Bulletin. The flaw requires no user interaction and yields high confidentiality, integrity, and availability impact within the device user scope.
Local privilege escalation in Android's CarDevicePolicyService allows any unprivileged local process to silently bypass the user consent dialog required when adding an account to a managed device. Affecting Android 14 and Android 15, the flaw resides in the setUserDisclaimerAcknowledged method of CarDevicePolicyService.java, which performs no permission check before marking a disclaimer as acknowledged, effectively suppressing a mandatory user interaction gate. No public exploit identified at time of analysis and EPSS sits at the 1st percentile, but the zero-privilege-required local vector makes this notable in corporate Android fleet and automotive managed-device deployments.
RemediationAI
Apply the patch level from the Android Security Bulletin dated 2026-06-01 (https://source.android.com/docs/security/bulletin/2026/2026-06-01) on all Android 14 and Android 15 Automotive devices; the bulletin lists the exact source-tree fix for CarDevicePolicyService.setUserDisclaimerAcknowledged and the corresponding security patch level OEMs must ship. Vehicle OEMs and fleet operators should coordinate the OTA rollout with their Tier-1 supplier, since Android Automotive patches lag mainline Android and are gated by per-OEM release trains. As a compensating control until the OTA lands, restrict which apps can be sideloaded or pre-installed on managed car devices via Device Owner allow-listing, and avoid enrolling vehicles into managed-account workflows that rely on the disclaimer dialog for user awareness - the trade-off is reduced enterprise account-provisioning convenience. Generic compensating controls such as 'don't install untrusted apps' are weak here because exploitation only requires PR:L (any low-privileged app), so app vetting on the head unit is the highest-leverage interim mitigation.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability lives in CarDevicePolicyService.java, part of the Android Automotive (Car) framework used by Android-based in-vehicle infotainment systems and managed by Device Policy Manager APIs. The setUserDisclaimerAcknowledged method is intended to be callable only after the user has interactively seen and accepted a disclaimer when an enterprise/managed account is provisioned, but the method omits the caller-side permission check that gates this state transition. This is a textbook CWE-862 (Missing Authorization) issue: the trusted internal state ('user has acknowledged the disclaimer') can be set by an unprivileged caller, short-circuiting an explicit security UX control built into Android's managed-device account flow. The affected platform identified by CPE is cpe:2.3:a:google:android (any version field), with EUVD scoping the practical impact to Android 14 and Android 15 automotive builds.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Primary rating from Vendor (google_android) · only source for this CVE.
CVSS VectorVendor: google_android
Lifecycle Timeline
7DescriptionCVE.org
In setUserDisclaimerAcknowledged of CarDevicePolicyService.java, there is a possible way to bypass the user dialog when adding an account to a managed device due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
Executive ViewAI
A privilege escalation in Google Android 14 and 15 enables unauthorized account provisioning on enterprise-managed automotive devices, bypassing user consent controls that organizations rely on for fleet governance. Organizations deploying managed connected vehicles face direct loss of administrative control over device provisioning and potential compliance violations, as attackers with low-privilege app access can silently add accounts without detection.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Enforce managed app installation policies to block unauthorized third-party apps; (2) Enable and monitor audit logs for account provisioning activity across managed automotive devices; (3) Conduct weekly account audits on managed devices to detect unauthorized additions; (4) Restrict local shell/debug access on all managed devices to limit attack surface.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB