PayRange: The App Exposing Credit Card Details Through an Illegal Backdoor

Published August 20, 2026

Last updated August 20, 2026

Overview

The PayRange Android application is currently unsafe to use, due to a backdoor deliberately placed in its SSL (TLS) validation logic for WebViews. This backdoor allows a man-in-the-middle attacker to gain remote, unauthenticated control over any application WebView, including a form used for entering payment card details. An attacker can also escape the WebView sandbox to execute dangerous API functions on a user’s device, and issue privileged commands to connected PayRange hardware.

The backdoor was abruptly introduced into the app in 2021, and has remained present in the five years since, covering version 6.5.2 through to the current release of 7.0.7. It bypasses core security protections in Android and whitelists a domain connected to an adult site. For these reasons, it is suspected that it was inserted with malicious intent. To track this security incident, the CERT Coordination Center has published Vulnerability Note VU#152953, as well as two CVE IDs: CVE-2026-13461 (WebView hijacking, rated 9.6 CRITICAL) and CVE-2026-13462 (sandbox escape, rated 7.5 HIGH).

CVE-2026-13461: WebView Hijacking

The backdoor takes advantage of a “feature” in the Android operating system, which allows apps to disable Android’s SSL trust chain when loading content into WebViews. Normally, when a secure website loads inside of a WebView, the site must cryptographically prove that it is who it claims to be. If any error is detected, Android automatically rejects the connection.

However, the SslErrorHandler API in Android allows you to ignore validation failures and invent your own criteria for accepting connections. Google warns you to never do this, adding that your app can be classified as a “dangerous product” that violates Google Play policies if you try. In the case of the PayRange app, Google’s security protections failed on two fronts: the automated Play Protect system could not detect the backdoor, and the company has still not addressed the reports I sent them months ago. The app remains available on the Play Store to this day.

The backdoor defines extremely insecure rules for trusting sites, which can be described in plain English as, “I don’t care who signed this certificate. As long as somebody wrote ‘TRUST ME’ on it, I’ll accept it.” In more technical terms, signatures are never cryptographically verified, so anyone can create a self-signed certificate and masquerade as a server for PayRange or Stripe. Even if signatures were verified, the logic uses insecure checks, such as “Common Name contains stripe.com” and “Common Name ends with payrange.com”. These can be trivially bypassed with trusted certificates for attacker-controlled sites like evilpayrange.com or stripe.com.evilsite.com.

The full validation logic can be seen in Figure 2. Without reading a signature, the code accepts a certificate that matches any of the following rules:

  • Common Name ends with payrange.com
  • Common Name contains stripe.com
  • Common Name contains [adult site] AND any of these conditions are true:
    • Issuer Common Name is R10
    • Issuer Common Name is R3
    • Issuer Common Name contains Network Solutions

I can think of just one reasonable explanation for the sudden reference to an adult site: malware.

public static boolean shouldProceedWithSslError(SslError sslError) {
    SslCertificate certificate;

    if (
      sslError == null
      || sslError.getPrimaryError() != 3
      || (certificate = sslError.getCertificate()) == null
    ) {
        return false;
    }

    SslCertificate.DName issuedTo = certificate.getIssuedTo();
    SslCertificate.DName issuedBy = certificate.getIssuedBy();

    return
        issuedTo.getCName().endsWith("payrange.com")
        || (
            issuedTo.getCName().indexOf("fetlifestatus.com") > -1
            && (
                issuedBy.getCName().equals("R10")
                || issuedBy.getCName().equals("R3")
                || issuedBy.getCName().indexOf("Network Solutions") > -1
            )
        )
        || issuedTo.getCName().indexOf("stripe.com") > -1
        ;
}

CVE-2026-13462: Sandbox Escape

On its own, granting attackers the ability to hijack application WebViews is already bad enough. I soon made a discovery which revealed the situation was even worse than I had imagined.

By default, Android WebViews are designed to confine their contents to a sandbox. If an attacker gains control over the sandbox, they can inject whatever they want, but only inside of the sandbox. External functionality remains inaccessible by design.

Yet once again, as with WebView SSL validation, Android allows you to partially disable the sandbox. This is exactly what PayRange does, by enabling a set of native functions to be called from JavaScript code. This also allows a remote, unauthenticated attacker to call them using the previously mentioned WebView hijacking vulnerability, CVE-2026-13461. The functionality enabled through this sandbox escape includes, but is not limited to, prompting to send money to an attacker via Google Pay, opening an arbitrary URL in the user’s web browser, and issuing commands to a connected PayRange device with the full permissions of the operator.

function executeNativeMethod(methodName, methodParams) {
    var msg = {'method': methodName, 'params': methodParams};
    if (window.PRAndroidInterface) {
        PRAndroidInterface.postMessage(JSON.stringify(msg));
    }
}
function getLocationPermission() {
    executeNativeMethod('requestLocationPermissions', '');
}

The 24/7 Priority Security Team That Never Was

I discovered the backdoor in the PayRange Android app back in April, while conducting routine security research. As soon as I had confirmed my findings, I found a page on PayRange’s website which listed an email address specifically for vulnerability disclosure. As the company requested, I sent them my comprehensive report via an encrypted message. The website made a simple promise:

For urgent security concerns or requests such as an incident, or suspected misuse of your account, please email our 24/7 priority security team at security@payrange.com.

Urgent requests will be addressed in 24 hours or less.

I waited weeks for a response. I sent them a reminder. To this day, I have never heard back from that address. Eventually I decided to seek assistance from a customer support agent, who proved to be even less helpful.

When asked about the lack of a response from the 24/7 priority security team, a PayRange support employee reported, “we do not have a security@payrange.com email box.” When presented with the contradictory information from the PayRange website, the employee did not address the inconsistency. I then asked to connect with someone responsible for software security, and the employee chose to block me. I never heard from customer support again.

Over the months following the discovery of the backdoor, PayRange was contacted through several email addresses, a physical letter sent to their mailing address, and a fax message. None of these means of communication elicited any acknowledgement of the problem. Eventually I reported the backdoor to the CERT Coordination Center, who were likewise unable to reach PayRange within the window of more than 45 days before public vulnerability disclosure. Even the Cybersecurity and Infrastructure Security Agency has thus far been unable to obtain a response from the company.

PayRange Violates the PCI Data Security Standards

Companies that handle payment card data, such as credit card numbers, are required to abide by a set of rules known as the Payment Card Industry Data Security Standards. PayRange processes payment transactions through Stripe, and is designed to be PCI-compliant by virtue of Stripe’s PCI compliance. This is reflected in this quote from their website:

PayRange’s systems and processes are designed to comply with the Payment Card Industry (PCI) Data Security Standards. Further, the service provider(s) of PayRange have been audited by a PCI-certified auditor, and is certified to PCI Service Provider Level 1, the most stringent level of certification available.

By disabling security protections in Android, the PayRange app compromised user safety, and violated Google Play’s terms of service. Likewise, by disabling security protections in Stripe, the PayRange app jeopardized the integrity of the Stripe platform, and violated that company’s terms of service. To make matters much worse, by disabling security protections in Stripe, the PayRange app also caused the company to cease being compliant with the PCI Data Security Standards. This means that PayRange has not been PCI-compliant since 2021, and continues to violate the standards to this day.

Whether PayRange deliberately introduced the backdoor or failed to respond to an ongoing security incident, it is indisputable that they were not compliant with the standards. By exposing payment credentials to a risk of malicious compromise, they could face financial and regulatory penalties from payment card providers like Visa and Mastercard. In some jurisdictions where PayRange operates, these standards are also codified in law, and violations can lead to legal consequences.

PayRange Commits Copyright Infringement

In a matter altogether unrelated to the backdoor, my research also revealed that PayRange committed copyright infringement by violating the license terms of at least 13 third-party software projects. Copyrighted code from Meta, Airbnb, Stripe, Block, and individual developers was distributed in the PayRange app without copyright notices, which were mandated by the licenses governing the code. Because they failed to obey the license terms, PayRange had no permission to distribute the third-party code, and infringed on the copyright.

Additionally, PayRange created an illegal license incompatibility by linking to GPLv3 code from the AVR-Crypto-Lib. This requires them to make their complete app source code available to users under the GPLv3, and inform those users of their rights under the license. However, restrictive license terms in the Facebook SDK for Android, which PayRange integrated into their app, are fundamentally incompatible with the GPLv3. Even if PayRange published the complete source code of their app and all applicable copyright notices today, they would still be actively infringing upon the copyright of the AVR-Crypto-Lib, because the Facebook SDK for Android cannot be made GPLv3-compatible.

Libraries that PayRange distributed without permission include:

Conclusion

If you are a user of the PayRange Android app, you should know that interacting with the app currently puts you in danger of a malicious compromise. Because PayRange has been unresponsive, there is currently no patch available to remove the backdoor. For your safety, please continue to keep your software up to date, so that any security fixes can be delivered as quickly as possible.

If you are PayRange, please address this immediately. Your customers’ data is at risk.

Timeline

  • April 21st, 2026: Reported backdoor to security@payrange.com
  • April 28th: Sent a reminder email to security@payrange.com, contacted support@payrange.com and asked why my report was ignored
  • April 29th: PayRange support employee denies the existence of a security@payrange.com address
  • April 30th: Presented support employee with conflicting information from website, asked to speak to software security personnel
  • After April 30th: Support employee blocks my emails, refuses to respond
  • May 15th: Reported backdoor to CERT Coordination Center
  • May 18th: CERT Coordination Center creates Case VU#152953, invites PayRange to participate, and sets disclosure date in 45 days’ time
  • May 28th: Sent physical letter to PayRange mailing address
  • June 11th: Sent fax message to PayRange
  • July 9th: CERT Coordination Center publishes Vulnerability Note VU#152953 and CVE IDs CVE-2026-13461 and CVE-2026-13462
  • July 10th: Cybersecurity and Infrastructure Security Agency rates CVE-2026-13461 as 9.6 CRITICAL and CVE-2026-13462 as 7.5 HIGH
  • July 15th: This article is published on LinkedIn, along with a corresponding post
  • August 20th: This article is published here