Official Statement from X-VPN regarding Blind In/On-Path Attacks

Recently, an academic study mentioned that X-VPN for Android may be exposed to Blind In/On-Path attacks, which has attracted attention and led to some misinterpretations in certain media outlets. 

We take this matter very seriously and have immediately initiated an internal investigation and reproduction tests. In the spirit of transparency and accountability, we will share the core facts, scope of impact, and the actions we are taking next.

Our Key Findings

While investigating the observed phenomenon, we followed the three-stage attack model described in public literature, Blind In/On-Path Attacks and Applications to VPNs, and validated the security claims against X-VPN in a controlled test environment. 

Based on a compliance-focused verification, we reached the following conclusions:

• We have determined that this security concern stems from network configuration/behavior at the Android platform layer, representing a platform-level risk rather than an inherent security flaw in any single VPN product. 

• As this issue relates to system configuration, it cannot be fundamentally resolved solely at the application layer; nor do we have the permissions to modify or patch Android kernel-level settings directly.

• To explore potential mitigations with a learning mindset, we ran the same experiments on several other mainstream VPN providers. Still, we observed the same risk, including ExpressVPN, NordVPN, Surfshark, Norton VPN, and Proton VPN.

• During verification, we observed slight variations in reproduction details, which may be related to functional changes in the system.

Due to security and ethical considerations, we will not publicly disclose any technical details that could be used to replicate, exploit, or amplify risks. All necessary reproduction information and observations have been submitted to Google through responsible disclosure procedures for the platform to assess and address the issue.

What are Blind In/On-Path Attacks?

Blind In/On-Path Attacks are a type of attack: when an attacker, capable of observing or partially controlling the network segment you’re connected to, can identify an active connection by probing and observing the device’s responses—and, when conditions allow, to disrupt it or try to inject spoofed packets. 

The term “blind” here does not refer to physical disability—it means the attacker cannot see or decrypt the communication content, but can infer useful facts by measuring differences in network behavior.

How Do Blind In/On-Path Attacks Work During a VPN Session?

When you connect to a VPN service, an encrypted tunnel is established between your device and the VPN server to enable secure data transmission. This tunnel acts like a pitch-black, impenetrable cloak enveloping your data, effectively shielding the original content from being read or tampered with. People won’t know who you are, see what message you send, or directly access the form data you submit.

However, even though the content is encrypted, certain probe traffic can elicit observable responses from your device. These responses themselves do not reveal the encrypted data, but they can be observed by the owner of a malicious network access point (like a malicious Wi-Fi) and used to infer additional information, such as whether you are using a VPN or which website you are visiting.

Building on the above, we can now outline the mechanics of Blind In/On-Path Attacks. Imagine you’re working on your phone in a café, with your VPN enabled and connected to what appears to be the café’s free Wi-Fi (which is actually set up by an attacker). 

After that, a Blind In/On-Path Attack can be performed through the following two steps:

In summary, the essence of Blind In/On-Path Attacks lies in their reliance on external observation rather than direct decryption. Consequently, this class of attack is not necessarily caused by the VPN provider that handles data encryption. Blind In/On-Path attacks often depend on some system- or platform-level weakness that makes identification significantly easier. This is also the focus of the next section.

Affected Platforms & Scope

Upon receiving reports that X-VPN may be vulnerable to Blind In/On-Path attacks, we promptly initiated security investigations across all platforms. Through practical testing, we discovered the following results:

For Android：

Vulnerability Mechanism

Android is more susceptible to Blind In/On-Path attacks due to a platform-level vulnerability.

The underlying cause is that Android does not enable strict Reverse Path Filtering (i.e., the system parameter net.ipv4.conf.all.rp_filter is not set to 1). Under this configuration, Android does not verify the source path of incoming packets; traffic arriving on any network interface may be forwarded to the target interface and elicit a response.  

On Android, when connecting to a VPN service, apps use the VpnService API to request the OS to create a virtual network interface named Tun. Subsequently, traffic from the device traverses this Tun interface into the VPN client, then routes through an encrypted tunnel to the VPN server. This constitutes the fundamental mechanism by which VPNs protect user data on Android.

Now suppose you’re connected to a fake Wi-Fi network set up by an attacker. The attacker can create spoofed packets whose destination IP equals the Tun interface’s address. 

When processing such packets, the system has two options: drop them or forward them and respond. Because the rp_filter is not strictly enabled, Android chooses the latter—it forwards these spoofed packets from the WLAN interface to the Tun interface and triggers a response. Consequently, the attacker can infer the communication status of the victim’s network interface through these responses and, under certain conditions, disrupt connections or inject/tamper with communication content.

Baseline (strict rp_filter=1) vs. Vulnerable (loose/disabled RPF)

Vulnerability Origin

We observed that this vulnerability originated from the paper Blind In/On-Path Attacks and Applications to VPNs and was assigned the CVE number CVE-2019-14899. 

The authors report a vulnerability observed across Linux, FreeBSD, OpenBSD, macOS, iOS, and Android that allows a malicious access point or adjacent user to determine whether a target is using a VPN, make active inferences about the websites being visited, and identify the correct TCP sequence and acknowledgment numbers. This, in turn, can enable an attacker to inject data into the TCP stream, providing the necessary conditions to hijack active connections inside a VPN tunnel.

Vulnerability Fix

After identifying the vulnerability, we attempted to implement a fix. However, on Android systems, our app lacks root privileges, making it impossible to resolve the issue entirely.

In fact, as early as 2019, Proton issued an official statement regarding CVE-2019-14899, similarly stating that the root cause of such issues stems from platform/system-level processing methods or configuration flaws. These require fixes from platform vendors, not design errors within a specific VPN app. In other words, remediation requires vendor-side patches or system-level configuration changes; app-level workarounds alone are unlikely to fully resolve the issue.

However, based on our current test results, this vulnerability does not appear to be fully remediated on Android devices. We were still able to partially reproduce the issue; moreover, after adjusting certain attack details, we were able to fully replicate the vulnerability—i.e., achieving the three-stage attack goals described in Blind In/On-Path Attacks and Applications to VPNs.

For Linux：

During testing on the Linux platform, we also detected system-level behaviors similar to those observed on Android. However, Linux allows users to possess root privileges, enabling us to mitigate such vulnerabilities by adjusting kernel network parameters or deploying system-level protections at entry points to filter or drop spoofed traffic that should not reach virtual network interfaces.

For macOS & iOS & Windows： 

Within the bounds of public documentation and our compliance-scoped testing, macOS and iOS have not exhibited exploitable response patterns identical to those observed in certain Android implementations. Similarly, Windows did not display equivalent problematic behavior in our public testing and literature review. In other words, macOS, iOS, and Windows are currently unaffected by this vulnerability.

What We Have Done So Far

Despite our investigation findings indicating the vulnerability originated at the system/platform layer rather than from an X-VPN software defect, we remain committed to prioritizing user security and have taken the following actions in response to this security risk:

1. Reported to Google: We followed a responsible disclosure process via Google’s official vulnerability intake, submitting clear reproduction data, observation notes, impact scope, and all relevant artifacts. We are actively cooperating with the platform’s assessment process.

2. Linux Mitigation Completed: We have implemented protective measures on Linux platforms by configuring iptables to drop all third-party traffic directed to our tun0 interface IP.

3. Exploring App-layer Mitigations on Android: Drawing from public research and documentation, we are exploring non-root-based mitigation strategies on Android, such as monitoring and protecting against abnormal detection behaviors. While such approaches may mitigate risks in certain scenarios, they do not constitute a fundamental fix. They may also introduce connection instability and potential denial-of-service vulnerabilities. For now, research is ongoing.

4. Clarifying External Communications and Addressing Media Misunderstandings: We are clarifying facts through the official channel to users, partners, and media outlets. We will continue to share updates transparently and responsibly to avoid unnecessary alarm or misleading conclusions.

In parallel, X-VPN continues to harden privacy and security at the engineering and community levels:

1. Code Audits and Regular Vulnerability Scans: We routinely conduct code audits and periodic vulnerability scans to ensure our client achieves a solid balance between functionality and security.

2. Bug Bounty Program: X-VPN actively collaborates with users, welcoming and incentivizing security researchers to submit responsible security reports through our official channel. We reward valid and reproducible issues with a bug bounty to enhance the overall security of our ecosystem.

Recommendations for Users

Of course, until Google releases a system-level fix or we develop a stable, non-root-based mitigation solution, Android users must take effective self-protection measures to reduce privacy and security risks. Here are some simple, actionable recommendations:

• Avoid untrusted public Wi-Fi networks on Android; prioritize trusted networks or mobile data in unfamiliar environments.
• Prioritize HTTPS/TLS-encrypted sites and apps; avoid transmitting sensitive information—including usernames/passwords, real names, addresses, and bank card numbers—over plaintext HTTP.
• Enable multi-factor authentication (MFA) for privacy-sensitive or critical account operations to add an extra layer of protection.
• Keep your system and apps updated to benefit from platform-level security enhancements (i.e., official Android bug-fix updates).
• If you encounter abnormal network behavior while browsing—such as frequent disconnections or redirection to suspicious pages, just avoid any sensitive operations on that network and disconnect immediately.

Additionally, X-VPN for Android provides a Kill Switch feature for all users. We recommend enabling this feature in public or untrusted network environments—even free users can utilize it to immediately disconnect from the network if the VPN unexpectedly drops, minimizing potential data exposure risks.

Next Steps & Contact

In the future, we will closely track Google and other relevant platform vendors’ assessments and remediation progress, keeping user awareness and safety as our top priority. 

Provided that external disclosure does not pose security risks, we will promptly release any publicly available information or actionable user guidance as soon as it becomes available. If Google releases system patches, X-VPN will simultaneously prepare and push necessary client updates and operational instructions to help our users obtain full protection as soon as possible.

Concurrently, we are advancing a third-party independent security audit to enhance transparency and validate our commitments to privacy protection and the No-log Policy. Upon completion, we will publicly share the audit findings with all users. 

This statement is based on our replication and analysis across various platforms and devices. However, due to platform differences and the uncertainty of future updates, some scenarios may remain uncovered or interpretations may vary. Should you identify any errors, additional information, or feasible corrective suggestions, please contact us at: security@xvpn.io.

Sincere thanks to all users for your support,

The X-VPN Team

FAQs