Zimperium

Insecure Mobile VPNs: The Hidden Danger

Written by Ignacio Montamat | Oct 02, 2025

Executive Summary

Virtual Private Networks (VPNs) are trusted by millions to protect privacy, secure communications, and enable remote access on their mobile device. But what if the very apps designed to safeguard your data are riddled with flaws?

While headlines have often highlighted the risks of VPNs linked to high-risk jurisdictions, a broad-scale security and privacy analysis by Zimperium zLabs of 800 free VPN apps for both Android and iOS reveals the threat is far more widespread. Our research found that a significant number of these applications exhibit dangerous behaviors, including:

  • Many apps provide no real privacy at all.
  • Some request dangerous permissions far beyond their purpose.
  • Others leak personal data 
  • Some rely on outdated, vulnerable code.

For organizations with bring-your-own-device (BYOD) policies, this isn’t just a consumer issue—it’s an enterprise risk. These mobile VPN apps, even popular ones, can become the weakest link in an organization’s security posture, exposing sensitive business data to unnecessary risk.

What is a VPN app and How Does it Work?

Virtual Private Networks (VPNs) have become essential tools for protecting online privacy and circumventing access restrictions on mobile devices. Many of us use them to browse securely, access geo-blocked content, and mask their digital location. But are these applications the digital panacea they claim to be? 

At its core, a VPN creates an encrypted tunnel between a user's device and a remote server. This process conceals the device's true IP address and encrypts all data in transit, making it difficult for third parties to monitor online activity. It’s the digital equivalent of sending a letter in a sealed, tamper-proof envelope instead of an open postcard.

But what if the envelope has holes? Or worse, what if the delivery service is secretly copying your mail before sending it along? This analogy illustrates the exact risks we discovered in many of the VPN apps we analyzed.

With the ubiquity of BYOD policies, C-level executives and CISOs face an unprecedented challenge in safeguarding sensitive enterprise data and infrastructure. While VPNs are often considered a primary line of defense, a critical distinction must be made: not all VPNs are created equal, especially free VPNs. While reputable solutions offer robust protection, many others can introduce significant risk to both the user and the organization, all while providing a dangerous and false sense of security.

A Deeper Dive: Unpacking the VPN Threat Landscape

Our research involved an analysis of approximately 800 unique, free VPN applications from official app stores. We found that a substantial share of these apps exhibit significant security and privacy issues, as illustrated in Figure 1. These issues fall into five recurring categories of vulnerabilities, which we will explore in the following sections.

Figure 1. Potential security and privacy issues found in our analysis.

Problematic Libraries

One of the most concerning findings from our analysis is the continued use of outdated third-party libraries with well-known, critical vulnerabilities. This practice exposes users to risks that have been understood and patched for years, indicating a significant lack of security maintenance on the part of the app developers.

A striking example of this is our discovery of three VPN apps still using a legacy version of the OpenSSL library, leaving them vulnerable to the infamous Heartbleed bug (CVE-2014-0160). First disclosed in 2014, this critical vulnerability allows a remote attacker to read sensitive information from the memory of affected servers by exploiting improper memory handling in the TLS heartbeat extension. This exposed data can include primary key material (secret keys), secondary key material (usernames and passwords), and other protected content.

The fact that applications are still being shipped with a decade-old, easily fixable vulnerability of this magnitude is a significant indicator of poor security hygiene and a disregard for user data protection.

Communications Channel Vulnerabilities

Arguably, the most valuable resource a VPN app provides to the user is secure and reliable communication. Weaknesses or a lack of robust security in this channel can lead to interception, identity spoofing, and the exposure of users to severe network-based threats.

Our research revealed that approximately 1% of the analyzed VPN apps were vulnerable to one of the most critical network-based threats nowadays: a Man-in-the-Middle (MitM) attack.

To understand this risk, consider how secure connections are established. When a user connects to a secure website or service, the server presents a digital certificate to your device to prove its identity. This certificate is like a digital passport, signed by a trusted Certificate Authority (CA). If a VPN app (or any app, actually) fails to validate this certificate, it's akin to a border agent waving through a traveler with a fake passport. 

This oversight allows an attacker to present a fake or self-signed certificate to your device. The vulnerable app, failing to perform the proper checks, accepts the fake certificate and establishes a connection, believing it is communicating to the legitimate server. Once this trust is established, the attacker is positioned directly in the middle of a communication channel able to intercept, decrypt, and read all traffic. The data can then be re-encrypted and forwarded to the intended destination, with neither the user nor the server aware that their "secure" channel is being secretly monitored.

Given their frequency and potential for devastating data exposure, MitM attacks remain one of the most significant threats in the cybersecurity landscape, and a vulnerable VPN app provides a direct pathway for such a compromise.

Misleading or Missing Labels

On iOS, Apple mandates developers to declare all the data their apps use and their motives through two main policies: Nutrition Labels and Required Reasons API. Nutrition Labels, displayed on an app's product page, are intended to help users understand how their data will be handled before they download. The Required Reason API, implemented via the app's privacy manifest, obligates developers to justify their use of specific APIs that could access sensitive data.

In principle, these declarations must align with the app's core functionality to ensure user data is not being misused. However, our study revealed that this is often not the case. Our analysis of iOS VPN apps found widespread discrepancies and non-compliance, as detailed in Figure 2. Furthermore, our data shows that a staggering 25% of the apps failed to include a valid privacy manifest at all.

Figure 2. Most frequently observed mislabeling cases for iOS VPN apps.

For applications that promise anonymity and confidentiality, such opacity is itself a material risk. This lack of transparency prevents informed user consent, obstructs meaningful vendor due diligence, and can mask data flows that could enable profiling, re-identification, or monetization. In practical terms, a “privacy” app with inaccurate or missing labels can silently gather telemetry, crash logs, device identifiers, or content-adjacent metadata and tie them to user behavior —exactly the opposite of a VPN’s stated purpose.

Permission Abuse

A troubling trend observed across the mobile ecosystem is the practice of requesting permissions that extend far beyond an application's core functionality. This behavior, often driven by a desire to collect data for monetization or enable future features, creates an unnecessarily large attack surface. Many of these permissions are even considered dangerous by Google and Apple, precisely because they grant access to sensitive data or excessive control over the device. 

The danger posed by this practice is significant, regardless of the developer's intent. A malicious VPN app, for instance, could abuse granted microphone access to record and exfiltrate ambient audio.  Even in a non-malicious scenario, a vulnerable app can be exploited by a threat actor; if that app was granted overly broad permissions to access media files for example, the attacker could then inherit those permissions to steal photos and other sensitive documents. 

The following sections will detail real-world examples of this type of risk.

Unusual Permission Requests

Another important consideration with this type of hazard is whether the permissions being requested are unexpected for a VPN app. In other words, is the app asking for access that is not essential to its core functionality? If so, the combination of permissions that are both dangerous and unexpected is a red flag on its own, as it could allow threat actors to exploit vulnerabilities in these permission-abusing apps and escalate privileges. The following examples highlight the most common cases we observed in our analysis.

Android
  • AUTHENTICATE_ACCOUNTS: allows an app to act as an account authenticator for the Android operating system. This is a powerful, system-level permission typically reserved for core apps from Google or a device manufacturer (like Samsung). Its intended use is to manage and authenticate user accounts for a service, for example, the Google Account Manager app, which authenticates your Google account for all Google services on your device. An app with this permission can:
    • Add/remove/manage accounts on a device. 
    • Change the passwords of existing accounts.
    • Steal authentication tokens to gain access to other services without a password.

    In essence, it gives the app extensive control over a user's digital identity on the device, which constitutes a major security risk for several reasons:
    • Violation of Principle of Least Privilege: A VPN's core function is to create a secure tunnel between a device and a network. It should only need permissions related to network access. The ability to manage accounts is completely outside its necessary scope.
    • High Potential for Malicious Use: An attacker could use this permission to steal credentials and authentication tokens for other apps, including banking apps, email clients, or social media platforms. The app could then exfiltrate this data or use it for impersonation.
    • Evading User Scrutiny: Many users will grant permissions without fully understanding their implications. An attacker could justify this permission by claiming it's needed for "pro" features or "premium" authentication, tricking the user into granting a dangerous level of access.
    • Credential Theft and Impersonation: An app with this permission could intercept credentials, bypass multi-factor authentication, and effectively take over a user's online identity.
  • READ_LOGS: allows an application to read all of the system logs on an Android device. These logs contain a huge amount of information about the system's activities, including:
    • Application activity: Which apps are being launched, what they are doing, and what errors they're producing.
    • User actions: Information about key presses, gestures, and other interactions.
    • System events: Device state changes, network connections, and hardware activity.
    • Potentially sensitive data: In some cases, logs can contain fragments of user data, such as usernames, passwords, or personal messages, especially if another app or service has an error.

A normal, legitimate application has no justifiable need to read system-wide logs. Its presence should be considered a strong indicator of malicious intent because of the following risks:
    • Massive Privacy Invasion: An app with READ_LOGS can build a comprehensive profile of a user's behavior. It can track which apps are used, when they're used, and potentially harvest sensitive information that passes through the system.
    • Spyware and Keylogger Functionality: This permission can enable an app to function as a sophisticated keylogger. By monitoring log entries related to text input and other app interactions, it can reconstruct what a user is typing in other applications.
    • Detecting Other Security Tools: Malicious apps use this permission to identify and evade security products, including mobile threat defense (MTD) apps. By reading the logs, an attacker can see if their malware has been detected and take steps to hide its presence.
iOS
  • LOCATION_ALWAYS: This permission allows an application to access the device’s location at all times, even when the app is not in use or running in the background. While this could make sense for mapping apps, ride-hailing apps or weather services, a VPN App should never need this because it allows for:
    • Unnecessary Access: A VPN’s role is to secure traffic, not to know where the user physically is.
    • Continuous Tracking: With “always” access, a malicious VPN could maintain a complete history of a user’s movements — a rich source of surveillance and monetization.
    • Cross-Correlation with VPN Data: Combined with knowledge of network traffic, constant location tracking provides adversaries with an exceptionally invasive picture of a user’s online and offline life.
    • User Deception: Some VPNs may claim this is needed for “smart server selection” (choosing the nearest VPN node), but that can be accomplished with coarse location or IP geolocation — not 24/7 GPS access.
  • USE_LOCAL_NETWORK: this permission allows an application to discover and communicate with other devices on the same Wi-Fi or local subnet. For example, a streaming app might need this to detect a smart TV.

    For a VPN, however, this is problematic:
     
    • Out of Scope: The VPN’s mission is to encrypt outbound traffic. It should not need to enumerate other devices on the user’s home or office network.
    • Network Reconnaissance: With this access, a malicious VPN could silently map local assets (laptops, printers, NAS, IoT devices), collecting details about open services, device types, and vulnerabilities.
    • Pivot Point for Lateral Attacks: Once local devices are discovered, an attacker could attempt exploitation or data theft, using the VPN as the initial entry point.
    • Deceptive Justifications: A VPN developer might suggest this is required for “connection troubleshooting” or “Wi-Fi security checks.” In practice, it grants the app scanning capabilities better suited for malware or surveillance tools.
 
Excess of privileges being requested

One of the most notable findings in our analysis was that, on iOS, over 6% of VPN apps (30 in total) were found requesting for private entitlements. This type of permission is a significant red flag because, once granted, it gives the app extensive control over the device—enabling actions such as executing system calls or accessing memory space containing sensitive information. These capabilities can easily be misused for malicious purposes.

In short, private entitlements can allow an app to:

  • Access to Private APIs: This entitlement allows a VPN app to access a variety of private APIs that are typically restricted from third-party developers. These APIs provide deep access to the device's operating system, allowing an app to perform actions that are not possible with public APIs.
  • Malicious Functionality: An app with this entitlement can perform a number of dangerous actions on a user's device, including:
    • Code Execution: The app can execute system-level commands, allowing it to bypass security protections and perform unauthorized actions on the device.
    • Data Exfiltration: The app can access and exfiltrate sensitive data from other applications, including private files and credentials.
    • Privilege Escalation: The app can use the private APIs to escalate its privileges, giving an attacker a high level of control over the device.
  • Jailbreak Detection: A VPN app might use this entitlement for legitimate purposes, such as checking if a device has been jailbroken or for detecting malicious activity. However, the same functionality can be abused by a malicious actor.

Requesting this entitlement is a strong indicator of potential security and privacy risks. It suggests that the app may either be attempting to perform malicious actions or is failing to adhere to Apple’s security guidelines. Importantly, our findings do not confirm that any of the analyzed apps were granted the entitlement—only that they requested it.

Risky Behaviors and APIs

This indicator highlights the exposure of application components and the use of dangerous APIs that can increase the attack surface of a VPN app. For instance, exported activities or content providers without proper safeguards may allow other apps on the device to launch them or query their data. Similarly, system-level calls such as Runtime.exec() can be abused to execute arbitrary commands or bypass platform security features. These weaknesses open the door to unauthorized data access, privilege escalation, or, in the worst case, remote code execution. In practical terms, a VPN app with such flaws could unintentionally give malicious apps access to sensitive data or allow attackers to exploit the app as a proxy for privileged operations.

Our analysis also uncovered additional concerns, illustrated in Figure 3. One striking example is the ability of some VPN apps to capture screenshots of the user interface. This is particularly troubling because the core purpose of a VPN is to safeguard privacy—yet unrestricted UI capture undermines that trust model. If a VPN app can silently record the entire device screen, the provider effectively gains a surveillance vector that extends far beyond network traffic.

Malicious apps can also target the VPN’s UI directly—for example, capturing server lists, subscription details, or error messages that could support fingerprinting or facilitate attacks.

Figure 3. Risky behaviors observed in VPN apps.

Insecure Activity Launch

An insecure activity launch is a vulnerability that allows attackers to bypass the operating system’s security checks and exploit a VPN app component to perform actions that were never intended to be publicly accessible. On Android, activities can be launched by other apps through Intents. If a VPN app does not properly protect its activities with permissions or by setting exported=false, any app on the device could trigger them.

So why is this a threat for VPN users? Consider the following scenarios:

  • Phishing UI injection: A malicious app could launch the VPN’s login or settings screen outside of the normal app flow, tricking users into entering credentials.
  • State manipulation: Attackers could force the VPN into insecure states (e.g., disabling encryption, altering settings, or disconnecting the VPN)
  • Bypassing user intent: An attacker could make the VPN appear active when it’s not, misleading users into believing they are protected when they are actually exposed.

Since VPN apps handle all device traffic, malicious manipulation at this level could mean users believe they are safe, when in reality their data is left unprotected.

Exported Content Providers

An exported content provider is an Android app component that can be used to manage and share data between different apps. If a VPN app marks a content provider as exported without proper permission checks, any app on the device could interact with it—querying or even inserting data. “How is this a threat??!!”... Let's take a look up next:

  • Data leakage: A malicious app could query VPN logs, connection details, user accounts, or tokens stored in the provider to look for server IPs and authentication credentials.

  • Data injection: Attackers could insert or modify configuration data (like proxy settings or VPN profiles) and reroute traffic through malicious infrastructure, undermining the entire purpose of the VPN.

Both of the aforementioned vulnerabilities can lead to privilege escalation, where an attacker can gain unauthorized privileges by abusing the vulnerabilities within the VPN app. This is the ultimate threat a user can be exposed to, as their device would no longer belong to them but to a vicious threat actor. 

How Zimperium Can Help

Our research makes one thing clear: not all VPN apps can be trusted. Many suffer from weak encryption, data leakage, or dangerous permission requests—problems that are invisible to most end users.

Zimperium Mobile App Vetting gives enterprises the ability to uncover these risks before they impact the organization. By combining advanced static and dynamic analysis, our technology:

  • Identifies hidden vulnerabilities – from weak cryptography and insecure SDKs to missing jailbreak/root detection.
  • Flags excessive permissions – highlighting apps that ask for access beyond what their functionality requires.
  • Detects privacy leaks at scale – including insecure communications, world-readable storage, and data sent to untrusted servers.

With this visibility, CISOs and security leaders can make informed decisions about which apps to allow in their environment, enforce security policies with confidence, and protect sensitive enterprise data from exposure.

And if you’re an app developer, Zimperium’s zScan helps you proactively assess your own apps for unknown vulnerabilities and privacy issues—before they reach the app store or your customers’ devices.

In a world where “privacy apps” themselves can be a source of compromise, Zimperium provides the intelligence and tools needed to separate safe tools from dangerous risks, while empowering developers to build secure mobile apps from the start.