CVE-2026-28623 in Android
Summary
by MITRE • 09/08/2026
In writeToParcel of BleRssiRangingCapabilities.java, there is a possible way to obtain the Bluetooth MAC address due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in the writeToParcel method of BleRssiRangingCapabilities.java represents a critical security flaw rooted in insufficient access control mechanisms within the Android Bluetooth subsystem. Specifically, this component fails to verify whether the calling process possesses the necessary permissions before serializing sensitive data into a Parcel object for inter-process communication. In the context of Android architecture, Parcels are frequently used to pass structured data between different application components or system services. When permission checks are omitted during serialization operations that involve personally identifiable information such as Bluetooth MAC addresses, it creates an avenue for unauthorized entities to extract this data without proper authorization. This design oversight allows any local application, regardless of its privilege level, to potentially access the serialized output containing the device's unique hardware identifier through standard IPC mechanisms if they can trigger or intercept the relevant service call.
From a technical perspective, the absence of a permission check in writeToParcel violates fundamental principles of least privilege and defense-in-depth. The Bluetooth MAC address serves as a persistent local identifier that can be used for tracking user movement across different locations over time when combined with other data sources. By exposing this information through an unprotected serialization path, the system inadvertently facilitates local information disclosure attacks where malicious applications running on the same device can query or monitor these IPC calls to harvest sensitive identifiers. Since exploitation does not require additional execution privileges beyond what a standard app holds, and user interaction is unnecessary for triggering the vulnerability, the attack surface is significantly expanded. This means that even sandboxed apps with minimal permissions could potentially exploit this flaw by leveraging existing system APIs or services that invoke this method during normal operation.
The operational impact of this vulnerability extends beyond simple data leakage to include potential privacy violations and enhanced tracking capabilities for attackers. An adversary who successfully exploits this information disclosure can compile a database of Bluetooth MAC addresses associated with specific devices, which may correlate with user identities if other data points are available. This capability undermines the anonymity protections intended by operating systems like Android that aim to randomize or restrict access to hardware identifiers. Furthermore, such exposure could aid in device fingerprinting efforts where attackers build profiles based on unique network signatures observed over time. The lack of required user interaction makes this particularly dangerous as it enables stealthy background exploitation without alerting the victim through prompts or notifications typically associated with permission requests.
To mitigate this vulnerability, developers must implement strict permission verification within the writeToParcel method before any sensitive data is serialized. This involves checking for specific system permissions such as BLUETOOTH_CONNECT or equivalent privileges depending on the Android version and API level being targeted. Additionally, implementing proper exception handling to prevent serialization when authorization fails will ensure that no partial or complete payload containing private information reaches external processes. System-level mitigations should include enforcing stricter IPC security policies where services validate caller identity more rigorously before processing requests involving sensitive attributes. Regular code audits focusing on inter-process communication paths and adherence to secure coding standards like those outlined in CWE-200 Information Exposure can help identify similar flaws across the codebase. Keeping all system components updated with vendor-provided patches ensures that known gaps in access control logic are addressed promptly, reducing the window of opportunity for exploitation by malicious actors seeking local information disclosure opportunities.