CVE-2026-21113 in Visual Voicemail
Summary
by MITRE • 09/09/2026
Improper export of android application components in Visual Voicemail prior to version 20.1.00.05 allows local attackers to initiate call without proper permission.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified as an improper export of Android application components within the Visual Voicemail application, specifically affecting versions prior to 20.1.00.05, represents a significant security flaw rooted in misconfigured component visibility settings. In the Android operating system architecture, applications consist of four primary building blocks: activities, services, broadcast receivers, and content providers. When these components are exported by setting their android:exported attribute to true without adequate access restrictions or permission checks, they become accessible to other applications installed on the same device. This configuration error allows any local application, regardless of its privilege level or intended functionality, to interact directly with the Visual Voicemail service. The core technical flaw lies in the failure to enforce strict intent filtering and permission validation when handling incoming intents from external sources, thereby bypassing the expected isolation boundaries between applications.
From a security classification perspective, this vulnerability aligns closely with CWE-269, which denotes Improper Privilege Management, as it allows lower-privileged entities to perform actions that should be restricted to higher-privileged contexts or specific authorized users. Furthermore, in the context of the MITRE ATT&CK framework for mobile platforms, this behavior is indicative of techniques related to Component Manipulation and potentially Service Execution. An attacker leveraging this flaw can construct malicious intents targeting the exported Visual Voicemail components. Because the component does not verify that the calling application possesses specific system-level permissions or user authorization, it proceeds with the requested operation based solely on the structure of the intent rather than its origin. This lack of validation creates a direct pathway for unauthorized interaction with telephony functions.
The operational impact of this vulnerability is primarily centered around privacy invasion and potential financial abuse through unauthorized call initiation. By exploiting the exported component, a malicious local application can trigger calls without requiring explicit user consent or proper permission grants such as CALL_PHONE. This capability enables attackers to initiate premium-rate calls, leading to unexpected charges on the victim's mobile bill, or simply make unwanted calls that disrupt service and consume network resources. Additionally, since Visual Voicemail often handles sensitive communication metadata, improper access could potentially expose call logs or voicemail content if further exploitation vectors exist within the component logic. The ability to initiate calls silently in the background exacerbates the risk, as users may remain unaware of the unauthorized activity until they review their billing statements or notice unusual network behavior.
Mitigation strategies for this vulnerability focus on both immediate patching and long-term secure coding practices. The most effective remediation is to upgrade the Visual Voicemail application to version 20.1.00.05 or later, where Google has addressed the improper export configuration by restricting component accessibility. For developers maintaining older versions, it is critical to audit all AndroidManifest.xml declarations and ensure that any exported components are protected with appropriate android:permission attributes that restrict access to only trusted applications or system-level processes. Implementing strict intent filters that validate both action types and data schemes can further reduce the attack surface. Additionally, adopting a defense-in-depth approach by utilizing runtime permission checks within the component code provides an additional layer of security against malicious intents. Security teams should also monitor for unusual telephony API usage patterns to detect potential exploitation attempts in real-time.